I’ve recently been working in a training role, with people who have never been exposed to the software engineering lifecycle before. I was drawn to considering analogies to try and explain to them what we were trying to do. It occurred to me that a bad analogy can be as destructive as a good analogy can be helpful, and with software engineering a lot of the analogies that immediately spring to mind are not necessarily conducive to understanding how a software development project should work.
Other engineering disciplines (mechanical engineering, building construction) often require a waterfall construction method - it’s rare to be able to deliver subcomponents before the whole build is complete. You can’t address the riskiest area of a tower block construction project first if the riskiest area happens to be the roof or the windows. Change is harder and more costly - if you want to move a door, or (heaven forbid) the whole building, you’re looking at huge deconstruction/replan/reconstruction costs. The design documents are not fluid. When would you ever start construction without a detailed, low level plan covering the position of every door and window? It’s just not done.
So, if not the other engineering disciplines, where do we look for a suitable analogy? How about the world of television and film production? Even the end product itself fits better to this analogy. Yes you have a finished product, but it’s ethereal. It can be expanded upon, there can be another “series”, it can be cloned or reworked for different scenarios. Let’s consider the methodology now.
How would the analogy of creating a TV series fit with an agile way of working? Well, you can focus on risk first. Get those scenes with the old bloke / pregnant woman under wraps! You can build a disposable prototype and trial it on a user group; then you can adapt your requirements based on their feedback. You can work iteratively and deliver production-ready output in each iteration; you can go live with a subset of the total (think, for example, of a pilot episode from a series which airs before the entire series has been made). As for documentation, a TV script is a fluid document. We don’t write that we are writing the script, we just write it. You can think of code, or the Software Architecture document, in this way. I think that the analogy of the product owner as the director can also assist in explaining to a non-techy client what will be expected of them in this role. It’s not project management, it’s not technical details (the director doesn’t need to know about lighting rigs).
In my opinion, this explanation would put naive or new-to-software clients in just the right frame of mind to begin an agile project. Do we have a timeline? Well, yes, we know when we’re wanting to go live but we don’t yet know for certain how many “scenes” (think how many user stories) we are going to be able to build by then. Do we have a requirements document? We have our overall outline; we will drill into the detail of each one during its iteration. That way, we can easily incorporate a little change as we understand our product better. Let’s go!
There are certainly a few places where the analogy breaks down. A television programme is seldom interactive or reactive, yet a computer system will be. And a computer system doesn’t often have the requirement for historical consistency - if you kill off a character in a TV series it’s tough to bring them back in later, whereas with programs the whole thing is disposable and can be replaced with version 2.0. But let’s not get carried away with the details, that’s not the point of this exercise.
In summary, if you have a new client who is struggling with the concepts of agile software development, give this analogy a spin and see if it helps with clarity and understanding.
