A Lean View of Scrum
In our last post we discussed the basic framework of Scrum. We continue looking at Scrum from a philosophical perspective in this post. In his book, Ken discussed the influence of seminal paper by Takeuchi and Nonaka, in 1986 which linked product development to Rugby. In fact Jeff Sutherland, the co-founder of Scrum, calls them the Godfather of Scrum. The term Scrum [in Rugby] refers to the strategy used for getting an out-of-play ball back into play. As in a rugby match, development teams in Scrum are organized to have holistic movement, have continuous interaction among team members, and have intactingcore team members. Among the team members, Scrum Master (SM) is the person who does administrative work, such as arranging the daily Scrum meeting and location, and removing any production impediments.
Scrum was getting popular almost at the same time as Mary Poppendieck was theoreticizing the various aspects of Lean. In a way both Scrum and Lean have their origin in complex adaptive systems theory. The origins of Scrum are best explained by Jeff Sutherland in his blog post. The conclusion in this post point to the fact that although Scrum can be in some ways viewed as a partial Lean Process, it is not a descendent of Lean. Also, if the concepts of Lean are applied within the Scrum framework, the results would be akin to what companies like Toyota have been able to achieve in product development. A more detailed look at Lean would be coming a bit later, but for now, lets look at the 7 principles of Lean and how these are achieved/ mapped to Scrum:
- Eliminate Waste : The work in progress is just that : work in progress. It is absolutely useless till it reaches the customer. Anything that does not add value is a waste. The biggest waste in software are unused features and features which do not provide value. In fact, the features which do not provide value are not only a waste but also a drain. Typically, this happens when the longer a product takes to reach the customer. This means that there are chances of product being either developed with a process that generates waste or you are building something wrong. A process where bugs are found after coding, would require you to go back to redo the coding. This would again be a waste. Scrum mandates work to be performed in a series of sprints, each sprint being of a very short duration. At the end of a sprint, the team should demonstrate potentially shippable code to the customer. Hence, the basic framework of Scrum would ideally guide you from incurring waste. However, an important component to minimize waste is to see and recognize it. Scrum does this by asking the team to identify obstacles. If the team is not capable or empowered enough to raise these obstacles, Scrum would probably not work as won’t Lean.
- Build Quality In : The focus of a Lean Process and Enterprise is not to have defects occur in the first place, rather than enter them in defect tracking queues. If you really want quality, you don’t inspect after the fact, you control conditions so as not to allow defects in the first place. If this is not possible, then you inspect the product after each small step, so that defects are caught immediately after they occur. In Scrum, the focus is more on latter. The fact that you demonstrate potentially shippable code at the end of each sprint, the team is subjected to rigorous test of what they are developing. As we have seen the sprint review also works as test for product owner in addition to the team. In addition, the team can raise obstacles which affect their productivity. When Scrum is coupled with XP, the team tries new development concepts like pair programming, refactoring and test driven development. These concepts help build quality in the processes. Hence, Scrum and Lean seem to be aligned here as long as the team picks up the right development practices. However, Lean takes an even more radical approach which you do not find in other frameworks. Lean says that When a defect is found, you stop-the-line, find its cause, and fix it immediately. The concept is drastic and at least initially can lead to the team stopping work all the time. The Scrum approach of identifying obstacles at the daily stand up and then Scrum Master either resolving them right away or wait to discuss these during sprint retrospectives, is a good alternative as well, at least initially. In Scrum, you regularly inspect and adapt and there are other drastic measures like sprint cancellation available with product owner.
- Create Knowledge : One way of gathering knowledge about your product is to get experts, pay them enormous salaries and create a 1000 page requirement specification. The other is to understand what customers really want by focussing on minimum, releasing that to actual users, getting feedback and developing from there. The latter approach has been there in various aspects like JAD, RAD, Prototying etc. However, the approach Lean [and in an implicit fashion, Scrum] take is that real knowledge about product starts coming in only when product hits the market. The sooner this is in its life cycle, the better, the knowledge would be. Another aspect of knowledge that Scrum and Lean share is that best knowledge is tacit knowledge. Through a self organizing team which learns, works and shares information, together, both aim to have a “information workspace”. The knowledge about the process, obstacles and product are gathered by the “whole team” at the end of sprint through sprint reviews and retrospectives.
- Defer Committment : Scrum is silent on “implementation” aspects of this value of Lean. However, the product owner is expected to write a good product backlog keeping in mind various aspects like priorities, risk, YAGNI and set based concurrent engineering approach.
- Deliver Fast : According to Lean, there is only one way to achieve high quality. You must develop people who continually improve their processes, build quality into their product, and develop the capability to repeatedly and reliably respond to their customers many times faster than their competitors. Scrum is a framework which provides for faster delivery of products - almost every sprint. However, there is nothing in Scrum that stops the teams from delivering poor quality, same mistakes driven and late software. Scrum would only make it visible. It is for the organization to create a culture where the team members can continually work to improve processes so that they can continually work at an even faster pace.
- Respect People : There is no one best way to do something. There are many ways. What is a good way to do for you might not be a good way to do for others. If you give respect to people, you get that in return. You must respect people and this should be demonstrated by your single minded dediction in helping them succeed. When this is done, the people align themselves with your vision and produce astounding results. Scrum and Lean encourage self organizing teams. The framework respects teams judgement, responsibility and ability to organize and plan work. Hence, this value of Lean closely aligns with Scrum philosophy.
- Optimize the Whole : A lean organization optimizes the whole value stream, from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on optimizing something less than the entire value stream, the overall value stream will suffer. Scrum is a simple framework. It optimizes the three parts of leadership : processes, marketing and technical. Of course, the system would be as good as the people in it.
As we can see, whether or not Scrum tends towards Lean is driven by what the team and stakeholders value while implementing Scrum. In fact, there’s really nothing to stop you from using Scrum to schedule a more rigorous workflow like the SEI Process.
Popularity: 64%
Posted on April 6th, 2008 by admin
Filed under: Introduction, Values | No Comments »
