Loading...
 

Tom Gilb and Kai Gilb's blog

7 truths about Agile and Scrum that people don't want to hear. Part 1 of 7 Wrong Focus!

Published by Kai Thomas Gilb323 points  on Mon 02 of Nov., 2009 kaiGilb

Project-Requirements.png (4.34 Kb)
Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)

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(external link)

Manifesto for Agile Software Development


We are uncovering better ways of developing software by doing it and helping others do it. Through this Work we have come to value:

Individuals and interactions over Processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation

Responding to change over following a plan


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(external link)
Scrum_proces-500px.gif (6.82 Kb)

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;

  1. Does the software deliver improved value of any kind to my Stakeholders?)

  2. If yes. How much value of what kind?)

  3. 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.

Wait, you might say defensively, what about the Principles behind the Agile Manifesto http://agilemanifesto.org/principles.html(external link)
The first Principle on their list is:

“Our highest Priority is to satisfy the customer through early and continuous delivery of valuable software.”

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

“Working software is the primary Measure of progress.”

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.

This is a message, as loud and clear as I can be, to all fans of Agile.
It is not about working software. It is not about your preferred working Process. It is not about user stories. It is not only about your customer or user.




It is all about delivering, to your set of Stakeholders, value improvements, which they care about, which makes their world better, within agreeable, minimum or pre-determined costs.


If that is not the main focus, if that is not clear to everyone on the team, you will eventually lose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad.


What do you do? Develop sw? No, you (should say) deliver value to Stakeholders!

Your truly
Kai Gilb

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.

Part 0 of 7 Introduction(external link)
Part 1 of 7 Wrong Focus(external link)
Part 2 of 7 Developer Creativity(external link)
Part 3 of 7 Stakeout Stakeholders(external link)