Last week I asked on twitter how we could describe difference between Agile vs. Waterfall in one word. As I’m recently doing some research work and find myself often needing to summarise and extract essence of ideas I though this could be an interesting exercise.
I was really impressed with the thoughts that came:
- Sean suggested learning
- Kurt – batch size (OK, not one word, unless you’re German)
- Radu – defaults
- Karen – flow
- Chris – stress
- Gitte – choice
- Simon – mindset
- and for my own part, I’m putting forward feedback
Now I’ll try to reverse the process and unpick these single words into the ideas that I think might stand behind them. Use comments generously if you think I missed something or disagree with my thinking.
Batch, a manufacturing term, indicates a package of work (a set of inputs) which is being processed or worked upon in a processes in a single cycle. In software development we’re not dealing with tangible objects but we are still doing processing. The subject of our processing are ideas. We take ideas as the input and transform them into value mostly by creating some working software.
Waterfall’s approach to batches is to take what we may call a 100% batch. All the ideas that we have for a project are being lumped and processed together, step by step, through analysis, development, testing and eventually deployed in one big release.
Agile methods take a different stance and strongly advocate making the batch size as small as possible. In Scrum, for example, we’re typically going though a batch every two weeks and this time limit (the sprint time-box) automatically limits the number of ideas (expressed as features or requirements) that we work upon. If we apply Kanban to our process we’re told to create explicit Work-In-Progress limits thus usually making the batch size even smaller.
The size of a batch directly influences the flow of work. We can think of flow as the progress of ideas through the entire development pipeline from inception to realisation. Many Waterfall projects flush a product out after two years. That’s two years of drought followed by a downpour. Switching to an agile way of working means potentially a sizeable drip every two weeks or even a steady trickle.
Smaller batch size and smooth flow provide way more opportunities for feedback. With a Waterfall project we may only find out that a design created in the analysis phase fails to meet the performance expectations two years later and we only find out once all the work has been completed. Agile projects provide an opportunity to validate ideas and functionality frequently and thus create ample touch points where we can change direction.
It’s the abundance of feedback that creates the necessary loops to feed our learning. Without feedback there can be no learning and the more feedback we can absorb the more quickly we can learn (but be careful not to be inundated with it). Agile methods place strong emphasis on learning as it’s focused not only on what we produce but also on how we produce it. We’re encouraged to adapt our approach constantly to optimise the value we’re creating.
More information through feedback and constant learning means we are more aware of how the work works. This awareness creates options which we can exercise and having options mean we have a choice. In Waterfall project we also have some choices to make – what tools we use, what design we pick, how we implement the UI and so on; it’s the project plan however, that dictates how we should progress with our work. Agile encourages us to choose how we work and re-evaluate those choices regularly.
Feedback helps create visibility and having a choice means we can correct if we stray. This provides the teams working in an Agile way with greater sense of control of their own destiny. If we feel in control we can typically cope with stress better and there is less of it. But visibility and transparency also mean a certain level of pressure, which can be stressful. On the other hand long cycle time of Waterfall projects mean that people can “hide” from the consequences of their actions or inactions for much longer. Eventually though, the reality catches up and the stress levels go through the roof.
I asked Radu for some clarification here and he explained this to mean the default position that we start from or our reference. I’m reading it as a set of assumptions, which are certainly very different in Waterfall and Agile. The former assumes we can know everything up-front and careful planning and through analysis are the key to success; the latter accepts the uncertainty inherently present is a highly variable process and provides measures to deal with it. Which nicely leads on to our last concept.
Now that we have gone through our list I hope a more complete picture emerges. A picture of the how-s and why-s. As Simon pointed out, we can indeed boil it down to one single concept – mindset with which we approach our work.
How we view the world, the world of software development, is dramatically different between Waterfall vs. Agile.