Kai makes the observation that, “The Manifesto is overgeneralized, and should instead instruct us better on how to make intelligent decisions for our stakeholders.” He then moves on to discuss the Scrum backlog process, asking, “Where, in the Scrum process diagram, is 'delivering value to stakeholders'?”
This highlights a major misunderstanding about Scrum, one that I noted in my post, Are There Fundamental Problems with Agile/Scrum? Scrum is a framework for team interaction, and not a paint-by-numbers approach with everything explicitly defined.
When it comes to Scrum, the business is responsible for defining and prioritizing items that will provide value, not the developers. Scrum is a process that involves the business to deliver value to the business; how the business defines that value is completely up to the business and the stakeholders.
As far as the developers are concerned, Scrum dictates that the highest-priority items from the backlog are those that must be worked first. The business and the stakeholders will get what they value the most first, within the limits of what they were willing to invest (staffing being a key investment, given the people-intensive nature of software development.)
The key point is that the Agile Manifesto does not instruct you on how to define business value, nor is it an instruction manual for software development.
The Agile Manifesto is an instrument to succinctly state the mission of Agile development. It provides a statement of Agile’s core values and some guiding principles. If you want a deeper understanding, entire books have been written about Agile, adhering to mission and principles of the Agile Manifesto.
Kai objects to some wording from the Agile Manifesto showing up on page two, like the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Okay, perhaps one of the values should have been something about delivering software that was of the highest possible value to the customer. However, I’ll defer back to what I feel is the stated purpose of the Agile Manifesto, which is to uncover better ways of developing software. And you can't have everything on page one.
Another issue that Kai points out is with the principle that states, “Working software is the primary Measure of progress.” Kai explains, “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.”
I'm puzzled by this comment. Kai appears to be taking one sentence in isolation, removing it from the intended context. Agile is all about defining value and prioritizing the work so that the highest-valued features will completed first. And that value is realized when the prioritized business features are captured in working software.
What is the issue with measuring yourself against delivering complete, quality working software that contains the highest-valued features – as determined by the business?
Kai closes with the following:
"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."
Agreed, software development is all about meeting the needs of your customer(s) as well as your stakeholders who have a vested interest in achieving a solid return on their investment.
In the final analysis, this requires a cross-functional, multi-disciplinary team working effectively and efficiently to produce results.
Kai’s blog is an excellent opportunity to play point/counterpoint with respect to Agile and Scrum. Kai will make his points, and I will make mine. I’ll leave it to you, the reader, to determine what is right for you.