Site Overview 
By Kai Thomas Gilb
on Mon 22 of Feb., 2010 10:59 GMT+01:00
7 truths about Agile and Scrum that people don't want to hear. Part 2 of 7: Developer Creativity
Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
Part 2 of 7: Agile “Baby Talk” Kills Developer Creativity
Conclusions up front
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. When developers are given the challenge to improve a system (Product-Quality) they not only rise to the challenge, but excel at it. This is also observed in Scrum teams where they are given the challenge.
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.
The Agilists sell Agile as an answer to increasing market pressure, as a way to be more competitive. But Agile falls short of giving its applicants a competitive advantage, because it doesn't say anything about requirements.
The popular Agile practices, teach and practice Use Cases or User Stories and other Function and feature centric ways to describe the most critical input and outcome of development. There is little or no specification to help us differentiate between a Function “the what”, a value “how well”, and a Solution “how”. Most Agilists teach and practice 'mixing the required Function with the optional solutions'. They don’t seem to teach anything useful when it comes to the most critical type of Requirements, the “how well”. In practice, by teaching User Stories, they teach not to use the critical “how well” types of Requirements, at least not in a way that can be used to guide decisions in the solutions.
The real value and cost of a system comes from creating the "how well" attributes.
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.
that is it, the rest of this blog is fill :-) to better explain the conclusions above.
Claims:
1. 90%-99% of all Agile, XP & Scrum practitioners and teachers are describing product Requirements using the incomplete and uncompetitive aspects of what describes products, the functions, features, user stories and the like. They are failing to incorporate the Requirement parts that make a product competitive, that make it valuable, and that is costly to develop.
2. 90%-99% of all Agile, XP & Scrum practitioners and teachers have not learned the fundamental skill which is critical for the success of a product: separating functions, from solutions, and also from the “how well” attributes (aka qualities). This is not unique to Agile, but without this, Agile is not healthy.
3. 90%-99% of all Agile, XP & Scrum practitioners and teachers teach 'Solutions' as if they were the Requirements, thereby killing opportunity for creativity among the Developers to come up with better solutions. This also tends to kill the fun of being a Developer.
I don't know the actual %, but from my broad international exposure, it is closer to 99% than 90%.
Introduction
At its purest description, Scrum is an empirical process control method. That means that Scrum is specifically designed to NOT tell you how to do any particular sw engineering discipline, like testing or requirements.
It 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.
Using Scrum, through early continuous feedback, your organizational disfunction, like lack of understanding of the real Requirements, should be revealed.
Agilists also like to emphasize that Agile is a good answer to increasing market pressure; that it is a method that gives an advantage over other methodologies in terms of competitiveness.
Also central to Scrum is the idea of cross-functional teams. I might comment about that in a later post, or not.
Credits: thanks to Craig Larman and Jeff Sutherland for teaching me about Scrum's origin, and what it should be.
What a great starting point! There is much to like about the above description.
In this blog post, I will use the word Developer to include; engineers, architects, usability experts, coders, softcrafters etc. and in most cases product owner)
Reality?
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.
In the field, what Requirement practices are taught and used? Simplified Answer: User Stories! (Functions and Features based, also TDD and BDD are of this nature).
And you might think that is ok, what is wrong with User Stories? Everything is wrong with that focus, it is not ok. It means you make your favorite Agile practice as weak as most of the Past fads ;-) Read on...
By talking to Scrum and XP gurus and teachers, I have found that they teach user stories and the like. They say this is for two reasons.
1. That is all the Agile market is ready to digest. (If this is true, my efforts are of no use ;-)
2. Most (but not all) of them don’t know how to do it much better.
Some references that point to examples for User Stories. But you can look at your own practice and thinking.
http://www.scrumalliance.org/pages/what_is_scrum
http://en.wikipedia.org/wiki/Scrum_(development)
http://scrumtraininginstitute.com/home/stream_download/scrumpapers
I don't find interesting practical alternative methods of Requirements, as described below, from within the Agile community, let's say 'in use' to drive the Product Backlog. I have searched the web and asked the experts. But I’m sure these interesting alternatives are there, especially when Agile is used to create systems that have a heavy engineering background. Please point them out to me, as I'd love to learn about them and how their users do it.
User stories have the same philosophy and faults as valuing “working software”. User stories are not values to most real stakeholders. Functions are fundamental, but they are not the increased value people want. User stories or derived Function Requirements describe what the user does, or wants to do. They will guide the Developers to create the functions needed for the sw to be able to “do” that.
The Real Point is - Value Increases
The point is not sw functions, the point is to enable some Stakeholders to improve something, to do things better than before. The main focus has to be on the “better” part. If you are in the business of creating working sw, user stores might do the trick for you, but if you have any kind of competition, even from your own old system, user stories don't cut it. If your Stakeholders are at all demanding, you need to focus on how well the system you are developing does a Function for the Stakeholders.
Example
Let me give you an example from a authoritative text on Scrum. http://scrumtraininginstitute.com/home/stream_download/scrumprimer
page 8 figure 2 The Product Backlog.Item 1. As a buyer, I want to place a book in the shopping cart (see UI sketches on wiki page).
What is wrong? Everything is wrong! Let me give a quick breakdown.
First, the Function it describes, “to place a book in the shopping cart“ is already a solution. 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.
Second, the central part of competitiveness, the idea about “better”, is missing completely.
The “how well” attribute of the Function (aka 'quality') is the critical aspect that allows the Developers to know, find, and prioritize the solutions that are;
1. better than the competitors (also information that’s missing, how good will competitors be?),
2. better than the sw product it is replacing (missing),
3. better than the solutions specified in the “UI sketches” (aka solutions),
4. helping you know when you are over or under-designing, compared to the values needed and their worth.
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.
Summary of what is wrong with this User Story.
The Product Backlog Item is mixing up 'required function' and (optional) 'solutions', without feeling any guilt. The critical “how well” attributes are totally absent.
Here is a hint to an alternative way of expressing it (simplified Requirements, I would normally define some of the words etc., but found not needed for the points expressed):
Book-Order.Through
Scale: average % of books, that a user intends to buy, that they actually end up buying.
Past [System being replaced, last month] 75%
Past [Competitor x, last month] 85%
Status [new system, last delivery cycle] 80%
Tolerable [new system, May.] 85%
Goal [new system, May.] 95%
Book-Order.Speed
Scale: Average time, to complete a book order, of three books, that are known to the buyer, from: she has the intention of buying the first book, she is on a page where the book is displayed, until: she has completed the order of the three books, and gotten her confirmation of order and of payment.
Past [System being replaced, last month] 10 min.
Past [Competitor x, last month] 7 min.
Status [new system, last delivery cycle] 6 min.
Tolerable [new system, next May.] 6 min.
Goal [new system, next May.] 1 min.
In plain english, and shortened, Book-Order.Speed reads:
It is required that a buyer, by next Feb, can complete a book order of three books, in 1 min.
If by next Feb. it takes more than 6 min., this project is a complete disaster.
On the website it is replacing, it takes 10 min.
Our main competitor has a system where it takes 7 min.
And after last sprint (if Scrum) we measured our latest version to 6 min.
State the challenge without the Solution
In the Book-Order.Thrugh & Book-Order.Speed examples, the solution is not given, just the challenge. The challenge is to find the best solutions to reach the Goal levels. A challenge put forward in such a way focuses on delivering the desired value improvement to the Stakeholders. It leaves the creative and engineering aspect of how to best solve the challenge to the people best suited for that, the Developers.
From Customer to Developers
Needs as uttered from the customer and users are uttered from their perspective, from their background, with their engineering knowledge. They speak “baby talk” when it comes to development and engineering. They will say they need ‘password’, when they need ‘security’, they will come up with solutions that they think will solve their needs, but will not have the insight of all the Stakeholders needs required to make the best solution required for all Stakeholders.
Developers do have the potential to have the overview over all the Stakeholders needs and an overview of the technical possibilities.
Don't state the "how", Don't worry about the "what", Focus on the "How well"
Every bookseller has to have a system for ordering books. The Product Backlog item: “As a buyer, I want to place a book in the shopping cart (see UI sketches on wiki page)“ pins down the solution, states the obvious that is common among all competitors (the Function, the what) and omits the real Requirements which is essential for creating a competitive product (doing the Function better).
Documentation Reduction
If you are not accustomed to the power of focusing on the "How well", you might think I am introducing more paperwork. The opposite is true. By learning the art of specifying the critical ends, as "what it will do" and "how well it will do it", one can eliminate the solutions (from the Requirements specs).
Requirement documentation can be reduced drastically, like down to one page for huge projects. I just got a status report from a client of mine. He was a little shy when he told me that the Requirement documentation for his project consisted of only one requirement. His Requirement looks something like this:
DB-Clean.Time
Scale: the average time, from a customer delivers a contact db to them, until it is given back to the customer, cleaned to the same quality as it is with the current system.
Past 5 hours
Status 1 hours
Goal 30 min.
That's it! He told me he did not have any other documented plan. He trusted
they would find ways to reduce the time as they went along. And he (his development team that was free to find the most suitable solutions) had now brought the time down from 5 hours to 1 hour. He is as Agile as can be, AND he is creating a very competitive system. Note that the competitiveness didn't result from 'Agile' alone, but mainly from the Requirements practice used.No creativity needed?
There is not much happening with the “function”, all book sellers have to have the same Function, it is either present or absent. If absent, you are not in that business.
What needs to be created is the “better attributes” of the functions. Better than the competitor/old system.
How do you create “better”? By coming up with solutions that together carry/create those “better attributes”. That means, if Solutions are called Requirements, as in 'required', as they are in User Stories, those 'required solutions' will directly deny the Developers the possibility to create better solutions, that could have resulted in a competitive product.
Skilled Developers need not apply!
When the Requirements of a project are focused on the functions and solutions, as is normally the case with User Stories, good craftsmanship, doing coding well, will not be appreciated. If your job is to code "put the book in the shopping cart", well that is what you will produce. This is likely to lead to yet another terrible system, do it and update your burn down chart. But if your real Requirement is something like Book-Order.Through & Book-Order.Speed (see above) thinking and knowledge is required. Then add your simultaneous Requirements for Maintainability, Security, Usability, and Upgradability to the challenge, and we need skillful people to specify Requirements and to suggest suitable architectures.
Where the Value and Cost is
Creating functions, of no particular quality, is just about free to do, but without the "how well" attributes, they are useless and value-less. What drives development cost is "how well" the Function does what it does. What is valuable to Stakeholders is also "how well" the Function does what it does.
To better understand this, lets first look at extremes. Lets use Book-Order.Speed as an example. If it took about 7 weeks to complete the order of books, it would not matter if it could be done, no matter how good other aspects of the system are. People would not order books. At the other extreme, pushing the time down to 1 sec. to complete the order, would be technically very challenging, and probably expensive, but it could do wonders for sales.
Now, what is happening if you (I'm potentially talking about you :-) are using User Stories or the like, without a main focus on the "how well" attributes.
What is happening is that you are developing "good enough" functions. Obviously 7 weeks for Book-Order.Speed would not be accepted, so you develop it until it is ok; you find some solution that you like, and go with it. But is the system created better than the competitors? Who knows! Is the system better than the old system it is replacing? Sometimes yes, sometimes no. If they have a serious competitor, one who is targeting "ease of completing the sales" with vigor (think iTunes store's one-click sales machine!), 'good luck' competing with your User Stories.
A challenge to you!
I like to pass on a challenge one of my customers had. He was given a project from Microsoft, to implement a Microsoft built Customer Relationship Management (CRM) system at a telephone operator company. He was the Product Owner. He had about 6 months to roll out the system to all the employees there using CRM systems.
Your challenge: By using Scrum, XP or any other Agile framework or method, how would you write the product backlog items or the requirements? I understand if you think I have given you too little information, but give it a go anyway. Just give me some examples of how you would specify the Product Backlog Items in our Blog comment section, or at least think about it for yourself, later I will tell you what he actually did, and then you can compare.
Hope!
There is hope. Being an empirical process control method, Scrum is not the direct cause of this illness, neither is Agile. With Scrum you are free to dump User Stories, and iteratively start using meaningful ways to describe the requirements! Where we have given Scrum Developers back the responsibility to use their skills and to be creative in the solution space, we see the Developers shine.
Your truly
Kai Gilb
Part 0 of 7 Introduction
Part 1 of 7 Wrong Focus
Part 2 of 7 Developer Creativity
To comment, you need to register (instant) and log in (top right).
