Jon used the session to illustrate the effectiveness of agile delivery methods against up-front, lengthy specification documents when creating complex solutions (like software)... and what better metaphor for software than Lego.
As a digital agency, Orange Bus has no set delivery methodology. We have a core delivery model and tailor the nuances that wrap around this to best suit the client and project in question. Many projects are delivered in a definitively agile way and others using a more waterfall approach, but it was great to get together with a diverse cross-section of staff and recap on the essentials of delivery models with Jon.
Our first task...
Assemble a Lego character from a traditional requirements spec document in pairs.
Having spent my early career writing documents like these (although sadly, not for Lego) it was interesting to sit on the other side of the table.
...and I would like to take this opportunity to apologise to all my previous colleagues who encountered any of my specs.
The task was painful and after 15 minutes of trying to decipher the document all we ended up with was Lego mess.
Here's what the group reflected on upon completion:
- Exclusively communicating through writing and documentation is a terrible idea
- When interpreting specifications, making assumptions will likely mean you'll get things (very) wrong
- Great specifications are difficult to write and are abstractions that are far removed from the end result
- Mediocre specifications are easy to misinterpret, often ambiguous and laborious to read (important information was easily overlooked in the workshop by all teams)
So, traditional specifications don't always work so well, particularly when the end result of your work isn't clear to you from the outset.
Our second task...
Attack the Lego build project in a more agile and collaborative way.
Continuing in pairs, from a loosely defined guide, one person was the 'Builder' (Developer) and second person the 'Instructor' (Scrum Master).
Lego Through AgileThe process was much smoother and more enjoyable second time around and we ended up completing the model as Lego intended (let's just agree to ignore those two extra pieces in the photo... even agile software has bugs!)
Here's the team's reflection on the task this time around -
- The focus was shifted from a hefty (and somewhat daunting document) to one of collaboration
- Pairs developed a shared understanding of the build
- Product context emerged as we built and discussed the end result
- Pairs talked more, continuously changed direction and adapted approach throughout the process
- Sometimes you have to build stuff before you know exactly what you want and you can "course correct" along the way.
Jon hammered home the point of the exercise with the Stacey Diagram as a model of complexity -
The diagram brilliantly maps complexity on to two axes - Agreement vs Certainty.
With definitive requirements, fully agreed and understood by the stakeholder group (more rare than you'd think!) an effectively presented specification can simply communicate a project.
When requirements are not as well understood (maybe you're building something that hasn't been done before) and all your stakeholders aren't fully bought into what you're building, then trying to communicate with lengthy specification documents is a path to failure (and Lego rage). In these instances, agile methodologies shine, shifting focus to communication, collaboration and iteratively building your way to an effective end solution.
Thanks again to Jon for taking the time out for our Beers with Ideas for a really enjoyable session.