I hear a lot of people talking about Lean as if it were just a set of tools. I also hear a lot of people saying it doesn't make any sense to try to contrast Scrum and Lean. If you believe the first, you will likely believe the second. This blog is an attempt to show how Lean has a set of tools, but isn't just a set of tools. By tools, in our case, I mean the practices with which to solve problems we encounter.
Before I talk about Lean, however, let me talk about real tools - since that is the analogy I am most often given. Let's say you are a carpenter and have a tool box. It doesn't make sense to talk about one tool being better than another. The question is, which tool works best in this situation. As a carpenter, I can learn how to use the tools in different situations. Let's say I mostly make furniture. Then I can learn how to build dressers, how to build cabinets, how to build tables, ... I can learn which tools to use in which certain situations. There are quite a few number of these, but I can become fairly proficient at it in my domain.
What, however, happens if I become a journeyman? Now, I am in a new situation. I have experience using tools, however, so I am not lost. I try the tools in the new situations. I see what I did, contrast it to what I wanted, and adjust my methods accordingly. This is the "inspect and adapt" approach many agilists are so fond of. There is some waste in the process, but results will eventually be achieved.
Now, what happens if one knows more than how the tools work, but also understands why they work. For example, a basic carpenter knows that nails work in certain situations better than screws. However, many carpenters don't actually know the mechanical laws on which nails hold together two boards vs the mechanics of how screws do it. While it might be generally true that screws will provide more strength at a higher cost of implementation - it is only generally true. Bigger nails in some situations will work better than small screws. But too big of a nail and you might split the wood. A carpenter will learn from experience what to use. And in a new situation will make mistakes and correct. But if he knew the principles behind the mechanics of screws and nails, he might be able to make better decisions, more quickly, in a new situation.
In the physical world, this extra knowledge is often held in the role of an architect. Someone who understands the forces of construction better and will figure out what is needed - letting those more proficient in practices, but less proficient in principles do the work. In my mind this illuminates the distinction between knowledge that assists operations (practices the carpenter uses) and knowledge that assists decisions (principles being used by the architect).
This, of course, requires the belief that there is a set of laws here. This is one of the fundamental differences in different "camps", so to speak, in the Agile community. Many agilists don't believe there is such a set, and that what we do is more art than science. We are in an empirical situation, to them, and we can only inspect and adapt our way through it. On the other hand, many other agilists do believe there is such a set. In my mind, this is one of the foundational beliefs of Lean-thinking - that there is a set of rules out there. Plan-Do-Check-Act is based on the notion that we can plan our work based on our current understanding of how things work. We check our results against this plan. Part of our acting is then to redefine our understanding of the way things work.
So Lean provides practices to our Agile toolbox. Things like limit work-in-process (WIP) to capacity, don't do things until they are ready to be used (Just-In-Time), do value stream mapping, ... This is the Lean toolset. If one believes Lean is just this set, then picking the right tools to use is the best approach you can do. Use Scrum practices (daily standups, sprint planning, ...) where they apply and use Lean practices when they apply.
If you understand the Lean principles underneath the Lean practices, however, much more is available to you. First of all, all practices in software development are most likely better understood with the Lean principles. Using Lean principles, one can see how to better apply Scrum practices. So Lean becomes a combination of Lean practices, which apply only within certain contexts, and the principles on which they are based - which can provide insights into any practice in any context.
Unfortunately, this approach does not match most people's learning or working style. People like concrete practices to use. One of the value of coaches is that they can relate to people in very concrete terms. Very experienced coaches may not understand the principles on which their work is accomplished, but they have so much experience they can intuit good results. People working with them will become more proficient. At this level, both coach and disciple will view what is happening as following practices within particular contexts.
My view is that Lean is several layers deep. The most visible layer is its set of practices:
limit work to capacity
use value stream mapping
have the people close to the work make the decisions on how to do the work
avoid large batches
continuously re-plan
avoid delays when possible
focus on getting value delivered to customers quickly more than focusing on having people always be productive
and there are many more. But this is not Lean. This is merely a set of practices based on Lean-Thinking - or Lean Science as I sometimes call it.
Some of the Lean principles on which these practices are based are:
- delays between when an error occurs and when it is detected causes waste
- removing such delays can both achieve higher quality and lower cost
- quick feedback results in lower waste
- deferring commitments can reduce waste
- optimizing a segment of the value stream often results in increasing costs, increasing time to delivery and lowering quality
and again, this is only a partial list.
The opportunity is for people to use Lean practices while getting deeper insights into Lean principles. This will allow them to adjust their practices when they find themselves in different situations than they have found themselves previously. In the world of software development, we are all journeymen. That is, we are always working on new things than the things we worked on before. Experience is invaluable here. But an understanding of why we have achieved the results we have can be just as valuable.
If one is interested in learning more about these concepts, I highly recommend looking at our upcoming book Lean-Agile Software Development: Achieving Enterprise Agility. Several chapters are currently online.
Alan Shalloway
From http://www.netobjectives.com/blogs/Lean-Is-Not-Just-A-Set-Of-Tools
Messages
Aucun commentaire:
Publier un commentaire