7 truths about Agile and Scrum that people don't want to hear. Part 1 of 7 Wrong Focus!
Part 1 of 7: Completely wrong Focus: Agile & Scrum is not focused on delivering Values to Stakeholders for a minimum or a reasonable Cost.
As developers, project managers, Product owners etc. we earn our living by delivering Values to Stakeholders, by giving our Stakeholders improvements to whatever they do, at a Cost they are willing to pay. The systems we develop must therefore first and foremost deliver Value efficiently. Deliver agreed Value to Stakeholders, within agreed or reasonable Development Resources. The problem is … that is not what Agile is doing in practice, good intents to the contrary.
From the Agile Manifesto http://agilemanifesto.org
Individuals and interactions over Processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
The Agile manifesto, being the centerpiece of Agile, states its main Values, but does not mention a word about delivering specific and varied Values to Stakeholders. Agile is far too centered around the developer. The world is seen from the eyes of the developer, the world revolves around the developer. The earth was once considered the center of the universe? Yes there are some customers, and even though not mentioned, some managers, sales people, users etc. They are out there spinning around us developers. But that is not really important enough to analyze in detail, agile is what we Value as developers!? Make life easy for us - really delivering measurable Value is secondary.
All the ideas in the Agile manifesto are 'solutions' to what is seen as convenient for developers. They are not a set of solutions to solve the challenges of our project, nor for our Stakeholders. They don’t even know what these Stakeholders and their many Values might be. How can one declare in a manifesto, “this over that” without knowing the real ends. What if “that” would better satisfy my Stakeholder needs? The Manifesto is overgeneralized, and should instead instruct us better on how to make intelligent decisions for our Stakeholders.
Lets look at Scrum, the most popular Agile development practice in 2009. Here is the commonly used Process diagram. http://en.wikipedia.org/wiki/File:Scrum_process.svg
Where, in the Scrum Process diagram, is 'delivering Value to stakeholders'? Not there is it? It is assumed that someone up there is picking valuable stuff to develop. We develop it, and it is valuable??? In alignment with the Agile Values, Scrum has as an output, “working software”. Guess what, who cares if your software is working!
The interesting questions are;
If yes. How much Value of what kind?)
When and for how much Resources?)
I have experienced lots of “working software” over the years that has giving me negative Value. Hard to use, problem prone, slow, Feature overloaded software that is “working”. Give me sw that is faster, easier, more secure and that improves my ability to do what I want to do. That is what I want. That is the Type of thing that your Stakeholders want, and that they are paying us for.
So they put this up together with some other principles. That is swell, but it is on the second page. It needs to be on the first page, probably alone, and more sharply formulated, not mixing the Goal and the solution: hint "through" - there could be other better Means - sometimes!.
And reading further down this list of principles, this Principle has to compete with a long list of other principles, like
Guess what, have you heard the expression, “what gets measured gets done”. So if you Measure progress as working sw, lets say through a burn-down chart, then what gets done? “Working sw” gets done. Not “Our highest priority” not Value to Stakeholders.
It needs to say: we Measure progress through the amount of Value we have delivered to our Stakeholders.
I recently worked on a project that was very successful in the eyes of the Scrum team that developed it, a very competent team. The Product had all the Functions and user stories it needed, it looked nice and professional, was developed within costs, working sw etc., but the business owners where screaming loudly, since the 'working' Product resulted in less sales, than the Product it replaced. We re-did part of the Product with 100% focus on delivering Value improvements to the Stakeholders. We did this with the same Scrum team, we just gave them a very different focus.
I don't really need to write part 2 to 7 do I? This one is in-itself such a huge issue. But I will, stay tuned.
- Quantify the un-quantifiable: Tom Gilb at TEDxTrondheim
- Project Engineering Concept Glossary going online for your convenience
- Tiny update
- 2012 Gilb Fest - PRINCIPLES: Principles, Proverbs, Practices, Paradigms and Patterns: Heuristics for Pleasing People
- Tom Gilb awarded Honorary Fellow at the British Computer Society
- Value Project Management - Lean QA Classes and awards.
- New Value Management and Lean Inspection Certificate Holders
- Review of Lean Startup book by Eric Ries
- Nice Value Requirements Workshop
- Kick-Ass Project - a new online video based training class.