In a previous post*: http://nayrb.org/~blog/2015/12/31/agile-basics/
I talked a little bit about Agile and what I thought it meant.
Today, I want to talk a little about how decision-making power is different in an Agile world.
Fundamentally, for me**, ‘Agile’ is all about codifying some of the hard-won lessons from the first 55*** years of computer programming.
There are a number of interlocking ideas in the manifesto, and I keep finding new wrinkles to them when new situations arise, so I’m going to focus on power dynamics.
For this, I will need the strawman of ‘Waterfall’, the ‘development method’ most often contrasted with Agile. Most people represent ‘Waterfall’ as a number of time-sequential silos, with varying amounts of feedback between the silos:
What is not generally mentioned about ‘Waterfall’ is that estimation is generally performed with minimal input from those implementing whatever solution is called for. This**** generally leads to time and feature estimates being imposed on those implementing the solution.
“You will be solving this problem, and it will take you 3 days to do it.”
It is probably not surprising then that large software projects are prone to cost overruns, as those doing the work are not generally involved in the planning process.
What Agile tries to do is to add and tighten feedback loops. Whereas in a ‘Waterfall’ process, you might release code every quarter, in an agile process, you might do so every two weeks, or multiple times a day.
Key concepts here are subdividing features into smaller and smaller bits, to make the smallest useful change each time, but do it very often.
Getting back to decision-making power, what Agile does is to separate Prioritization power from Estimation power.
Agile gives the Estimation power to the team that will be doing to work*****, while retaining prioritization power in Management. You say that it separates the ‘How’ from the ‘What’******.
This separation encourages more buy-in from staff, and can stop bad ideas earlier. Most importantly, it focuses each of staff and management on what they (theoretically) do best. Management is hired to make decisions about what should be done next, developers are hired because they know how to do things well[7*].
Next time, we’ll tease apart more of the manifesto.
*Same disclaimer applies: I currently work for a company. That company does Agile. From my limited experience, I think it does it well. I am not talking about that company in any way, shape, or form in this post.
**And many others
***I’m going from ENIAC, the first actual construction of a general purpose computer. Lest you think I’m forgetting about Ada Lovelace, you may want to read about the first six (all female) programmers of ENIAC: http://eniacprogrammers.org/
****There are also often issues of under-estimating the cost of things in order to obtain a contract/approvals, but this is outside the scope of this post. Suffice it to say that one who was singularly focused on landing a contract would have great incentives to ignore feasibility and estimation objections from those who might be implementing it.
*****Agile also tries to make sure that the team has someone skilled in every relevant part of the company, but that is outside the scope.
******The ‘Why’ is outside scope of this article. 😀
*******You are confident that your hiring process is bringing in good developers, aren’t you?