Not quite the doom of Agile

Just in the nick of time I resolved my baby sitting dilemma and made it to Tom Gilb’s SPA London talk, only missing the first 10 minutes. Here are a few notes I took - I don’t think I missed anything radical in the first few minutes but if I did I’m sure someone will correct me.

Quantification
As always Tom was provocative and seeded a lively debate with the audience. As always Tom pushed for quantification and measurement of what software work is trying to achieve and how successful it is. And, as always, many in the audience pushed back on this.

Without going into too much detail: Tom says you can quantify just about anything, and for a software development you should. Many other people question whether you can quantify everything, whether it is necessary to quantify and if it is cost-effective to quantify.

I see both sides of the debate. I tend towards Tom’s point of view but I understand the reservations and share many of them. I also think there are some things it is extremely hard to quantify. Tom has this skill. Many others don’t and one of the results is a lot of bad quantification, bad metrics and consequently lots damage done.

Agile
Agile is not doomed the way the talk synopsis made out. Indeed the conclusion is much more that Tom’s methods - Evo and value management - are complementary t o Agile and specifically Scrum.

He didn’t address the “XP is already dead” quote until he was questioned at the end. This assertion seems to be based on the assumption that XP was mainly hype and now the hype has gone XP has gone.

Where Tom sees Agile methods going wrong is in the lack of understanding about what needs doing, for who it needs doing and a focus on “features” over “performance.” I agree with him here, I’ve blogged and written elsewhere about this problem myself (e.g. Requirements: the next challenge). I even gave a talk at the BBC a few years ago entitled “What’s wrong with Agile”.

Tom does believe teams need managing. Although he didn’t say as much that implicitly rejects one of the pillars of Scrum: the self organizing team. I don’t think Tom wants to see a return to command and control management - far from it - but he does see a need for active management. And that brings us to the next point.

Stakeholders and Product Owners
One of Tom’s key point is the role of stakeholders. That is, the need for all software development work to identify the stakeholders in the work and what they value from the work. Different stakeholders have different values and want different things, and these things change over time.

Tom asserted that stakeholder identification and management is not covered by Agile methods. Last night I thought “I’m sure it is in...” but now I look through my collection of Agile books I see its pretty thin on the ground. That said, there aren’t many references in Tom’s own Competitive Engineering book either.

As far as I am concerned, stakeholder identification, communication and management falls firmly within the Product Owner role. This is part of what Product Owners need to do when they are off the Agile stage and is part of the reason this role is so important.

At one point Tom stated that the Product Owner role dooms the project. I challenged him on this and it turns out we are in agreement. The doom occurs when the Product Owner is not managing the stakeholders.

Value over stories
Stakeholders have needs. Agile teams often interpret those needs as features. Tom suggests that User Stories feeds this assumption. I’ve blogged about this before: Requirements not functionality.

Tom proposes that by understand who the stakeholders are and what they value we can start to deliver value rather than features. Now I believe User Stories can be used to communicate this if they are written to communicate this. Tom’s own alternative to User Stories - Planguage - emphasizes the quantification, and thus value, more then User Stories. That said, Planguage is more difficult to pick up and use than User Stories.

Value driven planning
When Tom puts all this together you get Value Driven Planning. Here the idea is that critical stakeholders determine the value of software work.

Naturally there is conflict here as stakeholders argue about which work has the greatest value. The important thing is: conflict is natural. It is not resolving the conflict which is the problem. Once conflict is identified it can be resolved.

Potential v. Delivered value
Another key point to understand is the difference between potential value and delivered value. Too many projects have potential value which is not delivered because the software is not used, the users understand how to use it to the full or something else gets in the way.

It is not enough for the development team to measure the value they think they have delivered - e.g. functionality that can be used. They need to measure what value is created.

When there is a difference between these two numbers then it is time to act. If potential value is 1024 and actual delivered value is 500 then there is a lot of value being lost.

Scaling
For me a lot of this debate comes down to scaling. In small teams, with few stakeholders and small(ish) budgets doing a lot of stakeholder analysis, quantification and measurement may well be more expensive then just doing it. As was pointed out by someone, the trial-and-error approach of iteration works well, and cheaply.

When there is a big team, many stakeholders and this a big budget then not only is it worth making these investments it is necessary to ensure the team is doing the right thing, that everyone agrees on what is being done and understands why, and that the budget is justified.

Perhaps that my biggest “take away” lesson from last night.

In the end...
As you might tell, and is often the case with Tom, he hits you with hundreds of ideas many of which are left hanging there for you to follow up or thing about later.

The conclusion to my previous blog entries this week (The Doom of Agile, Thursday and Tuesday. ) is: Tom doesn’t really disagree with Agile, he is highlighting a issue others have seen and wants to shift the focus.

If you are interested Tom’s slides can be downloaded (be warned, this is a big presentation, 23Mb in PPTX format). Mark Stringer at AgileLab has some comments on the presentation too.