It’s a common trope that agile requires a leap of faith. It requires trust. Trust and faith that I’m guessing are absent in the cultures from which these comments arise.
But this statement makes it sound like trust and faith are exclusive to agile. And I don’t think that’s true.
To better explain this, let’s for a moment reflect on what I call the “Outcome Stack”
Outcome — the results
Output — what is produced
Activity — what is done
Agile, at least if it’s done properly, focuses primarily in the space of outcomes and outputs. Scrum in particular asks us to “allow the activities to look after themselves” in the guise of the “Self Organising Team”1
This is where the trust and faith part comes in, and, in many “Agile Transformations” falls down. Not only does “management” continue to feel a deep seated need to command, control and supervise, a surprising number of team members also feel more comfortable remaning in this paradigm. There appears to be a sense of comfort and safety gained from knowing that “if they (demonstrably) worked hard” they will therefore be entirely insulated from the outcome. (Or indeed lack of output, as long as “their bit is done”)
This sounds a lot like waterfall, the supposedly faithless process that requires no trust, because who needs trust when we have paperwork!
But is that true?
Well it depends on the part of the stack you’re looking at. Sure most Waterfall Style processes have a lot of processes, procedures and active governance in them to make sure that people are busy and doing the right thing. But there is still a leap of faith in there. If you care to look.
This leap of faith lies between the output and the outcome. A long time ago in a board room far far away, somebody, decided that “if we build it, they will come” — that if this particular software was built, then this result would happen. And not only that, but the cost of building that software could be predictable and contained.
“The Business” just put a lot of faith in that person or people. So it’s quite surprising that they usually remain nameless and blameless2 (and why none of them ever want to be the Product Owner3)
That’s trust with a capital T.
So maybe the difference between “Agile” and “Waterfall” is not so much that one requires trust and the other does not. Instead, it’s about who and where that trust is placed.
And that apparently makes all the difference.
- This does not of course prevent people from ignoring that maxim and micro managing their teams into the ground. But remember we were talking about doing this properly. ↩
- I remember a story from a friend about a senior manager who sold a project budget timeline up the chain to the execs — which was based on absolutely nothing at all but wishful thinking. Not even rough estimates. When the project ran “over” these expectations, the team was hauled over the coals, lost their bonuses and had all their leave cancelled whilst they were effectively forced to work nights and weekends to “make up” for their apparent shortcomings. The manager who provided the completely fictitious budget and timeline was not only completely unblamed, but collected their bonus and a modicum of sympathy from her peers for having such a “disappointing project team”. The worst part was that this story seemed to be not uncommon knowledge in the organisation, but people just accepted it. ↩
- I once had a client tell me that Scrum was the exact mirror image of their corporate culture. For them all decisions of business significance were completely anonymised and “laundered” through multiple committees (which also gave them the property of irreversibility) — but the more junior the employee got, the greater the resolution of scrutiny applied to how the person spent their time. ↩