My colleague Michael Brunton-Spall makes an interesting mistake in his latest blog post:
much of our time as developers is being completely wasted writing software that someone has told us is important. Agile Development is supposed to help with this, ensuring that we are more connected with the business owners and therefore only writing software that is important.
Most Agile methodologies actually don’t do what Michael says here. Every one I’ve encountered in the wild treats it as almost axiomatic that there exists someone who knows what the correct business decision is. That person is then given a title, “product owner” for example and then is usually assigned responsibility for three things: deciding what order work is to be done, judging whether the work has been done correctly and clarifying requirements until they can be reduced to a programming exercise.
That’s why it was liberating to come across System Thinking which does try to take a holistic approach and say that any organisation is only really as good as its worst performing element. Doing that does not eliminate all the process improvements in development that Agile can provide but also illustrates that a great development team doing the wrong thing is a worse outcome than a poor development team doing the right thing.
The invention of the always correct product owner was a neat simplification of a complex problem that I think was probably designed to avoid having multiple people telling a development team different requirements. Essentially by assigning the right to direct the work of the development team to one person the issue of detail and analysis orientated developers getting blown off-course by differing opinions was replaced by squabbling outside the team to try and persuade the decision maker. Instead of developer versus business the problem was now business versus business.
Such a gross simplification has grave consequences as the “product owner” is now a massive point of failure and few software delivery teams can effectively isolate themselves from the effects of such a failure. I have heard the excuse “we’re working on the prioritised backlog” several times but I’ve never seen it protect a team from a collectivised failure to deliver what was really needed.
Most Agile methodologies essentially just punt and pray over the issue of business requirements and priorities, deferring the realities of the environment in the hoping of tackling an engineering issue. Success however means to doing what Michael suggests and trying to deal with the messy reality of a situation and providing an engineering solution that can cope with it.
3 thoughts on “Agile software development defers business issues”
“Such a gross simplification has grave consequences as the “product owner” is now a massive point of failure and few software delivery teams can effectively isolate themselves from the effects of such a failure.”
I agree that the product owner being wrong is a problem, but isn’t analysis failure *always* the worst issue you can have? Is Agile significantly worse than whatever it has usually replaced?
If you diffuse the responsibility for prioritisation, QA, and business awareness, over a number of individuals, it is more likely that at least one of them will know the right answer to any question. But is it any more likely that, as a group, they will deliver that right answer?
I think that when you have broader responsibility you have a natural damping effect. The group is less likely to make a catastrophically bad decision. When the team was talking to multiple people they had a more realistic perception of what was happening in the organisation as a whole.
In the traditional Agile form I think the team tends to get in a groupthink situation where they believe or choose to believe the situation is as the product owner describes it.
More sophisticated development teams should be capable of understanding a more nuanced picture of the situation their work exists within.
Reblogged this on Sutoprise Avenue, A SutoCom Source.