Agile Software Development Is Like Cooking a New Dish Together With the Customer

I'm reading now a very interesting book about Lean Software Development by Mary & Tom Poppendieck and I have found there an interesting discussion about the nature of software development and what actually software development is. The key concept is to get rid of thinking that the software development process is similar to the production process. I fully agree with that and I will return to this topic pretty sure in the upcoming posts.

But one theme I have to comment. The authors are trying to depict the difference between software development and production process using a comparison to the processes of creating a recipe (in case of software development) and creating a dish, based on this recipe (in case of a production process). The quality of creating a recipe is defined as the ability to change and in case if creating a dish the ability to follow the recipe. Variable results in case of recipe are good and in case of dish are bad. Finally iterations generate value in case of recipe (learning process) and waste in case of dish (rework).

In my opinion the process of software development in agile way is even more complex as creating a recipe. When you are creating a recipe you are the chef cook alone with your way of thinking about "good dish". Your taste is individual and the ingredients and kitchen equipment are based on your experience and preferences. But the future customer of your restaurant is not involved in the process of creating of your new recipe.

So creating a recipe is like creating a software framework, language, library etc. but has not much to do with the creating of real business software where the customer has to be involved into whole process to get reasonable results.

So what is actually software development in that "cooking" context?

I would say it is like cooking a new dish together with the customer based on well-known recipes using your and customer's experience, your ingredients and customer's kitchen.

Well-known recipes are software frameworks and other stuff you don't what to develop from scratch. Your ingredients are software artifacts collected by you to achieve a high conceptual integrity (see my post about quality and scope reduction) thus high internal quality. Customer's kitchen is simple customer's environment you have to take into consideration while cooking.

At the beginning the customer defines the requirements of the "cooking project" in case of specifying at the beginning something like this "I'd like to eat a fish soup". You can then decide, during the cooking iterations and based on experience you have collected, if the soup is ok or maybe it needs some salt or maybe you have to throw it completely away and start the process again. And the successful end is simply defined by the satisfied customer, saying "mmmhh, delicious".

You have simply cooked something new together. Agile.



Quality and Scope Reduction

I really like the definition of the software quality provided by Henrik Kniberg:

  • External quality
    is what is perceived by the users of the system. A slow and non-intuitive user interface is an example of poor external quality.

  • Internal quality
    refers to issues that usually aren't visible to the user, but which have a profound effect on the maintainability of the system. Things like system design consistency, test coverage, code readability, refactoring, etc.

I'm pretty sure this definition is based on the Lean Software Development by Mary & Tom Poppendieck (shortly LSD - I love this abbreviation ;) which outlines perceived and conceptual integrity:

  • Perceived integrity
    is affected by the customer's whole experience of a system: how it's advertised, delivered, installed, accessed; how intuitive it is to use; how well it deals with idiosyncrasies; how well it keeps up with changes in the domain; how much it cost; how timely it is; how well it solves the problem. Software with high marks for perceived integrity suits you so well that you think the designer must have been inside your head.

  • Conceptual integrity
    means that a system's central concepts work together as a smooth, cohesive whole. The components match and work well together; the architecture achieves an effective balance between flexibility, maintainability, efficiency, and responsiveness.

Both types are for me part of the scope of every software development project but it is important to keep in mind, that the quality is not negotiable (I fully agree with Henrik on that). In agile world the change is a normal and positive element of the process. So, for example, after some sprints you may discover that the velocity of your team is not enough to finish the project on time. If you are not able to raise your velocity using additional resources you have to think about scope reduction.

Scope reduction comes in my opinion in two flavors:

  • Official scope reduction
    done together with the product owner. It is a positive effect of an agile. You simply take out, together with your team, the functionalities with the lowest prio.

  • Stealth scope reduction
    or unofficial scope reduction causes by introduction of shortcuts, quick fixes, workarounds, and temporary solutions and so on done by the team (or even single developers) internally. This is clearly a negative one.
Where the official scope reduction often causes reduction of external quality (touching for example user experience), the stealth scope reduction aims internal quality (and in many cases the basement of the application), which could be very dangerous for the further development process of the application (it's like shooting in your own leg).

As I written before, both of them are parts of quality and therefore not negotiable. Try to reduce functional scope, review your estimates or priorities if you have to.

But don't touch the quality.

And by the way: It is simply a great motto for us, architects & developers:

"Software with high marks for perceived integrity suits you so well that you think the designer must have been inside your head."

I have some thoughts about this sentence and the role of empathy in software development. I'll touch this very interesting topic again soon.



FTS is Like a Swiss Watch

The FTS model with its bunch of processes is like a Swiss watch. If all parts of it are perfect the watch is perfect, is running and looking perfect. The perceived integrity and conceptual integrity is perfect. The internal and external quality is perfect. It is like the fifth element, if you know what I mean.

But if only one part of it is not working properly the whole watch is a trash.

And that is the biggest problem of FTS.