Counterpoint: Agile “Baby Talk” Kills Developer Creativity

April 23, 2010

Kai Gilb’s blog post Part 2 of 7: Agile “Baby Talk” Kills Developer Creativity takes issue with how Agile development practices handle requirements, stating that the Agile approach is simplified “baby talk” that fails in practice. Kai states, “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.”

Interestingly enough, Kai reveals that he understands Scrum more so that I was led to believe in his first post. He states that Scrum, “… is an “open development framework”. 'Open' meaning that you can use any Requirement method, testing method, prioritization method etc. that the Scrum team sees fit for purpose.”

He follows with that statement, “You cannot just do Scrum. To put the framework to practice you need to plug in methods for the various sw engineering domains, like testing and Requirements, and practices from XP.”

It sounds like Kai gets it! So what is the difficulty?

He doesn’t like User Stories. Kai feels that User Stories do not capture the values of the stakeholders. He feels that User Stories mislead development, and that “The point is not sw functions, the point is to enable some Stakeholders to improve something.”

The example Kai gives is from the Scrum Primer (© 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde):

"As a buyer, I want to place a book in the shopping cart (see UI sketches on wiki page)."

Kai goes on to talk about what is wrong with this User Story. I won’t go into all of the details here, but I urge you to read Kai’s post first. The following are the conclusions that he arrives at (which are incorrect, in my opinion):
  1. The User Story describes a solution, “to place a book in the shopping cart,” and not a pure function, like “to order a book.” Kai asserts that this automatically restricts the options and any potential for creativity. (Actually, Kai is correct that this does describe a solution, but this can be dealt with.)
  2. That the developers are reduced to “bricklayers,” that they are told what to do. 
Kai then proceeds in his post to describe how the real requirements should be expressed, but he deviates from the User Story format in doing so.

I my opinion, this is an example of a need to tighten up the approach to User Stories and Scrum.

In the first place, User Stories are not full requirements. One of the problems with software development is that users don’t understand computers as well as developers, and they aren’t used to communicating abstractly. Sometimes they need to express their requirements in concrete ways that they understand. User Stories help to express what the user wants, but they are not the end requirement. User Stories are a reminder to have a conversation.

Agile development is collaborative development. The conversation with the Scrum team, the customers and/or Product Owner are intended to provide the understanding about the real requirement. If you are developing to just the User Story, you have a problem! In addition, the conversation may yield additional User Stories, and there should be a conversation about the acceptance criteria – those elements that will help to determine if the User Story is “done.”

User Story creation can also be performed by professionals who are adept at expressing requirements. A properly constructed User Story can be more complete than the example used. Let’s refer back to Kai’s post and his example. There might be performance considerations, as Kai points out. There is also a missing component in the example. I’ve crafted a new User Story that addresses Kai’s concerns and adds the missing piece of the puzzle:

As a customer, I want to complete a purchase of up to 3 books in 1 min or less, so that my satisfaction with the speed and efficiency will make me a return customer in the future.

We’re still at one sentence, and I’ve added detail (3 books) and captured the need for speed as part of the goal. Did you catch the other add? It was the “so that” component. The full User Story template is:

AS A [type of user] I NEED (OR WANT) TO [perform some task] SO THAT [benefit]

Now, when the team has a conversation with the user/customer, they can explore the goals that the user has, they will understand the motivation, the real need, and the desired benefit. This will address another one of Kai’s concerns:

“Developers are essentially reduced to “bricklayers”. They 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.”

If the team is having a true conversation, then developers most certainly can and should talk about how to best represent the business in software. There can be brainstorming and white-board sessions to figure out how to best meet the true goals and objectives of the business. Developers can and should have the ability to be creative. In fact, that is what the business is counting on.




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.