In Learning

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
  • Kurtbatch size (OK, not one word, unless you’re German)
  • Radudefaults
  • Karenflow
  • Chrisstress
  • Gittechoice
  • Simonmindset
  • 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 size
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.

Sign up to receive our newsletter and new posts

Recommended Posts
Showing 12 comments
  • Bob Marshall

    I am delighted you have reached the conclusion that I have been arguing for many years now. Mindset is the single determining concept. 

    As I am wont to tweet: Effectiveness (of an organisation) = f(collective mindset).
    I would add only that it’s not just how we view the world of software development, but how we, collectively, view the world of work.For those who subscribe to this idea, the implications are far reaching and turn upside-down all aspects of organisation, management, and work.- Bob

    • Thad Scheer

      Caution. In the 1990s Object-Oriented Software Development was the hot thing and the community made the mistake of differentiating itself with “Object Thinking”. The idea was the same, that there is a distinctive new way of thinking, i.e. having the mindset meant you were in the club, not having it meant you were a dinosaur. Looking back on O-O, “mindset” was not the distinctive characteristic of Object-Orientation, in fact “object thinking” is one piece that did not survive mainstreaming. Nobody “thinks in objects” today but we still use O-O at a programming level.

      Agile imputes different strong centers depending on the direction you approach it. Scrum has a different strong center than Kanban which has a different strong center than TDD. Any blend of these things will have its own strong center.

      For example, “egalitarianism” is a central characteristic of Scrum that differentiates it from other iterative/incremental models (like RUP, Spiral, etc.). Kanban’s central differentiating characteristic is “continuous”, in that work is not divided into iterations – it happens continuously. The strong center of TDD is self-evident in its name.

  • Sven Kräuter | 5v3n

    Couldn’t boil it down to one word for a adequate description, but I can tell that the mindset is the single most crucial part to transform in an organization in order to establish a transparent iterative process.

    The process instances are the easy part – the mindset is what makes a process / product fail or adds the extra value.

  • Olaf Lewitz

    Thanks for starting this conversation, Marcin, I like it a lot. Missed your question on Twitter.
    To me the difference between wtf and agile is IMPACT.
    (and that’s in your metaphors, waterfall, drip, trickle, draught, …) 
    Given impact, we get feedback, and learn. To sustainably and regularly do that we need the right mindset, so I’d see that as a prerequisite.

    A few comments/remarks on what you’ve written to inspire future conversations:
    Agile methods don’t “batch” work, we batch outcome. Which batches the impact, and the feedback.
    We are not processing ideas, we are solving problems. Ideas don’t flow, I think.
    A Scrum sprint is not a batch. It’s a container limiting the risk of a safe-to-fail experiment to learn more about the problem and solution space.
    I love this phrase: “two years of drought followed by a downpour” 
    As it clearly shows why waterfall is the wrong metaphor:-)

    Bob made a very important point: it’s not about software development, not about product development, it’s about how we view the world in general and the world of work specifically.


    • Paul Dolman-Darrall

      The batching of work compared to outcome could be debated. Since IT is rarely by itself the outcome, thus really it batches by the IT work necessary to achieve an outcome in industries which are not software.

      • Olaf Lewitz

        That’s exactly why I think it’s about impact, not outcome:)

        • Paul Dolman-Darrall

          Indeed, we use the word consequential – very similar to impact.

  • Hass Chapman

    I’d vote for mindset too. Agile is not a group of methodologies; it’s a set of values and principles that form a mindset that guide us into making the right decisions on a daily basis. It’s all about the people. It always has been.

  • Kevin Austin

    Mindset gets my vote – our perception shapes our reality, which impacts our outcomes.

    Bob, Olaf and Hass encapsulate the essence of the Agile mindset.

    Very nice work for commencing this discussion Marcin.

  • Erik Weber

    I’ve had some success framing everything we do in agile in terms of “RISK.”  That would be my vote.  Yes it’s a different mindset and enables some of the things listed above like flow and [lower] stress and fast feedback.  Why do we want any of these things though?  Because we want to limit risk.  Waterfall project inherently accumulate risk over their lifetime, agile project reset that risk by having working inspectable software every few weeks.

  • Jim Keeney

    Dialogue VS Contract 

    Seems like you need two words to describe. The first to describe Agile which is a process that evolves the right solution through evolutionary understanding discovery and improvement and the second to describe waterfall which is a manufacturing process that requires setting contract terms at each step that become the basis of the relationship in the next step. 

    Agile is about growth and Waterfall is about definition. 

  • Craig Cockburn

    How about “efficiency”. i.e. the delivery of business value and project success in relation to the time, effort and money spent 

Leave a Comment