Lean tools: Making decisions

• should the application include a feature to block users?
• Does class A or class B better represent the domain concept of a trip between two cities?
• Should we use MySQL or MongoDB?
• Should we put presentation logic on the client or on the server?

A design and its implementation are a sequence of decisions that narrow the solution space (all possible programs) to the single master branch of your repository. So far so good.

There are two strategies for taking decisions described in Lean Software Development: breadth-first, which delays commitment and explores options, and depth-first, which takes early decisions to get something working as soon as possible.

Emergent behavior

However, the command&control approach to decision making is not the preferred way of dealing with the problem in Lean. Instead, everyone should take local decisions by following a set of simple rules agreed with the team. Mary Poppendieck cites several advantages of "swarm intelligence" (as a metaphor of how ant and bees work):

• flexibility: you do not have to delegate decisions to a central point that could be overloaded. Decisions can be taken very quickly at your computer, instead of waiting for a meeting.
• robustness: if the driver is drunk, the rest of the team can still work effectively.
• self-organization: supervision is not as much necessary as for other styles of command. Moreover, the person closer to a problem has already the best information for solving it, so the leader may have only the advantage of technical expertise (*may*, not *does*, as it may be a non-technical person).

Lean rules

The set of the 7 Lean principles is the one where each tool we have explored in this articles falls into. It is really famous:

• Eliminate waste: unnecessary features and code, or delays in communication are a waste to be eliminated from the process.
• Amplify learning: the best approach to improve is to raise your learning rate, having many iterations as a target and extracting as much information as possible from each of them.
• Decide as late as possible: delay final decisions or leave open the possibility to change them late in the process.
• Deliver as fast as possible: speed is value and feedback can only be received after an initial delivery.
• Empower the team: Hire good people and let them do their job in their own ways: one of the pillars of innovation at 3M, seldom followed in practice.
• Build integrity in: quality and consistency should be targeted every day, refactoring with the same frequency of clicking a save button.
• See the whole: what matters is the throughput of the entire team, not how fast a single member can crank out code.

Ideally, these simple rules should be just what you need to take a decision, without passing from a central point of command.

Example

There was a legacy system integrating with many similar external companies in the same domain, exposing a web service to each of them. Unfortunately, each company had its own protocol and so called a different instance of the web service with a particular syntax: POST and even GET requests, or SOAP calls in some format.
This legacy layer had to be tested, and the companies involved were so many that multiple people from different locations were involved. We prepared a library to simplify testing - able to create fake requests and collect the responses from this stateless layer without actually passing them to the rest of the system.

The documentation of this library contained samples and a guide for setting up the tests, some people in the team being in another country.

However, we missed the POST request case and the support for building this fake requests was buggy. The bug bounced back to the referer in my city, which bounced it back to me, and I fixed it after three days. By inserting less than ten characters in a single line of code (an optional method argument).

Now this is what I don't call self-organization: for some reason, several team members didn't want to change someone else's code, even after seeing a clear stack trace. In this scenario, it wasn't a loss as the actual testers wouldn't start their work for one week - but a very easy to fix bug bouncing around had the potential to halt the whole process.

What we learned from this experience? That decision making must be distributed as much as implementation is, and that developers should be encouraged to practice Collective Code Ownership. We want the team members to think of themselves as architects and designers, not of bricklayers.
Yet we still have to define some principles (at least at the project level) that we all share and that we could use for taking consistent decisions. We are transitioning to Scrum, but the set of Lean principles could be a more abstract concept to keep in mind.