Tom Gilb kicked-off the ACCU conference on Wednesday with a controversial keynote, for some,  arguing that Agile methods do not have enough focus on delivering value to the people who pay the wages.

Tom began by claiming that agile methods are too self-centred in process and methods. This makes them good for focussing on programming tasks but they need to be supplemented with other methods in order to manage value delivery.

Perhaps unsurprisingly Tom suggested his own EVO method as the ideal method for doing this (although he noted that you could also use DSDM or RUP – both of which look more closely at value than Agile methods). Tom cited several recent examples of work done by Ryan Shriver (of Dominion Digital) on wrapping SCRUM with an EVO envelope. Ryan’s findings provide evidence that this combined approach provides both a method for managing value delivery and a method for managing programmers.

A fundamental problem with XP and SCRUM (for example) is that they don’t provide guidance on the highest-value / lowest-cost work packets. They have no alignment with higher-level business goals, argued Tom, and consequently no measurement can be performed with respect to business goals. (This provoked some audience heckling but of course a full debate couldn’t be carried on in the keynote).

Tom proposed the following framework for making smart decisions:

• Measure progress towards goals – burn rate (stories) isn’t a good metric
• Get a better understanding of time, budget, people
  • Are we using these in smart ways?
  • How good are we at exploiting gathered information on the next iteration?
•  Analyse this frequent feedback and adapt processes to correct and improve

Agile methods are very feature-driven – but according to Tom this doesn’t help us work in terms of business goals – so there is a problem in deciding how to maximize the value to business. The key solution to this is to quantify (business, technical, organisational) values.

Tom suggested that the main take-away from his talk was the use of impact estimation tables to measure value delivery / costs. These give a clear understanding of options. (There’s more on these in his book “Competitive Engineering: A Handbook For Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage”).

Using Evo concepts – budgets, goals, design ideas, impact evaluation, requirements spec. with Planguage, estimation, planning & tracking estimation to wrap Scrum concepts gives a complete environment for delivering value to stakeholders – NB just not the customer. Agile methods are too-focussed on the customer. (Medium-sized projects have 40 stakeholders – 50% internal, 50% external). They are stakeholders because they have requirements and need value to be met. (Another take away point– are you identifying all important stakeholders in your projects?) Someone has to analyse values and needs of all stakeholders. If critical stakeholders are denied what they want they can probably destroy project.

Systems are all about building potential to realise stakeholder value – if a system isn’t used then no value can be generated.

[As an aside, Tom took a straw poll of use of agile methods in the audience - Scrum was much more popular than XP – suggesting that XP is on the way out?]

Tom described 10 principles to help get business value from projects.

1. Critical stakeholders determine the value.
2. Values can and must be quantified. (Useful to get to actual values e.g. robustness that can be agreed. Use as clear targets for architecture, design etc.)
3. Values are supported by Value Architecture. (Architecture design is an optimisation problem – most architectural decisions impact multiple values.)
4. Value levels are determined by timing, architecture effect and resources.
5. Required value levels can differ for different scopes (where, who). – (Different stakeholders have different needs, these also change over time.)
6. Value can be delivered early. (Intentionally target the highest priority stakeholders and their highest priority value area – deliver them value early and continuously.)
7. Value can be locked in incrementally. (Give the system to real users – they won’t give it back if they benefit.)
8. New values can be discovered. (Expect to discover new stakeholders and new stakeholder values. Developers must be in dialog with stakeholders / users. This partly arises because stakeholders will come to believe that you can help.)
9. Values can be evaluated as a function. (Tracking stories and burn rates is the only feedback you get in Agile methods. But productivity is defined as reaching goal levels of organisation.)
10. Value delivery will attract resources. (If you are good at delivering value you can expect more funding. Managers like to be credited with success.)

Higher adaptability in a system / organisation is an investment viewed as something that returns value over a longer-term period – Tom argued that this long-term view totally absent from agile. There are however some responsible corporations e.g. HP – in that in those environments you can do this sort of long-term thing without too much debate.

Often nobody has the responsibility that the value be realised – Tom proposes a Chief Value Officer to have this responsibility. But unfortunately didn’t have enough time to go into this in more detail…

The slides for Tom’s talk are available from his web site at:

http://www.gilb.com/community/tiki-download_file.php?fileId=169