Software development is known to be a creative process. The failure of traditional methods, where the dynamic environment of software development was ignored, made Agile methods fairly popular. There has been a growing adoption of Agile methodologies, particularly Scrum. However, is everything all right with Agile? Kai Gilb does not think so. He suggested that there are serious flaws with Agile.
Kai mentioned that inspite of all the glory of Agile there are some serious faults,
Most writings on Agile, talk about its glory, here I will write about the faults: faults that are so serious, that if not rectified will ensure that your favorite Agile method will become last year's fad.
Kai mentioned that the focus of Agile and Scrum is wrong. They are not focused towards delivering business value towards stakeholders. He suggested that all ideas in Agile manifesto are solutions to what is 'convenient to the developers'. The manifesto is heavily tilted towards developers. It does not talk about stakeholders. Kai took the standard Scrum process diagram and mentioned that, he could not find any place in the diagram where value was being added to the stakeholders.
Kai mentioned that Agile focuses a lot on working software which is deemed to be the highest priority but the adding business value to the stakeholders gets a place in the principles on the second page only.
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!.
Kai highlighted the following
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.
Commenting on Kai’s thoughts, pschwarz mentioned that XP adds business value through circle of life. According to him,
Business value depends on what you get, when you get it, and how much it costs. To decide what to do, and when, the customers need to know the cost of what they ask for. The programmers, based on experience, provide this information. Then the customers choose what they want, and the programmers build it. Now the picture looks like this
1. Customer: define value
2. Programmer: estimate cost
3. Customer: choose value
4. Programmer: build value
5. Repeat
Every time we go around the circle, we learn. Customers learn how valuable their proposed features really are, while programmers learn how difficult those features really are.
Kai responded back suggesting that even this does not add value to the stakeholders since it is clearly from the eyes of the programmer. He mentioned that unless the developers would focus on developing targeted quantified value, and not features, the circle of life would be just lip service for adding value.
Kai further mentioned that Agile “Baby Talk” Kills Developer Creativity. He mentioned that Agile does not give developers the space to be creative since it focuses on solutions and not functions. Further anyone doing Agile can not build a competitive product. He mentioned,
Scrum is practiced as a huge cooperative todo list. By not focusing on the critical "how well" attributes of the system, Scrum is reducing sw development to tasks, not needing skillful creative knowledgeable Developers. Developers are told what to code, not asked how to best satisfy a Product Quality need.There is little or no understanding for how to create a competitive product. Rather, the opposite is happening, by requiring 'solutions' (made by amateurs (users), not architects), more-competitive options are systematically censored.
This “baby talk” Requirements practice makes the popular Agile methods useless to anyone creating competitive systems, to anyone creating systems requiring high value, and to business.
Kai gives an example which many Agile projects would use as a user story. As a buyer, I want to place a book in the shopping cart. He mentioned that this user is completely wrong.
What is wrong? Everything is wrong! Let me give a quick breakdown.
According to Kai, the developer creativity and the zeal to build a competition worthy product is taken away from this user story since this does not propose a function but tells a solution to be implemented.
The pure Function is “to order a book”. Any specific way to make the order happen, like “shopping cart” will restrict the options/creativity space available for the Developer to find a solution, that will make the Function “order book” have better quality, as in perform better.
He mentioned that the user story also completely misses the “How Well” part for the developer. "How well" the function should be better than the competitor, "How well" should it be than the system that it is replacing, how can it be better than the suggested UI to be more user friendly. Kai suggested that with the current Agile and Scrum approaches, the developers are just bricklayers who are told what to do.
The mighty Scrum framework is reduced to a big cooperative To-Do list that tells the Developers what to do, and you the Developer should just do it.
Follow the series, where Kai proposes to uncover more serious flaws in the coming days. What are your thoughts about these specific flaws of Agile and Scrum?