Lean Software Development: An Agile Toolkit

According to the author, This concept, Eliminate waste, is first brought up by Taiichi Ohno, known as the father of the Toyota Production System, to deal with the conflict of market requirement and manufacture cost. In this concept, he gives waste a new definition "Anything that does not create value for a customer is waste. A part that is sitting around waiting to be used is waste. Making something that is not immediately needed is waste. Motion is waste. Transportation is waste. Waiting is waste. Any extra processing steps are waste. And of course defects are waste"[2]. The core of his ideal is that immediate production delivery is better than inventory. The history has proven the validity of his idea and this concept is becoming the most fundamental lean principles that all other principles should follow from.

Then the authors give us a guide on how to implement the principals by introducing two toolkits. The first toolkit, also should be the first step is learning to see waste. If a thing can't contribute to customer's perception or there is a way to go around it, it is waste. By this definition, Windston Royce had seen all steps besides coding and analysis are waste to development in 1970[3]. The authors metion this because it is a good start to re-evalue steps in development waterfall process. Then the authors translates the 7 wastes of manufacturing identified by Shigeo into 7 corresponding wastes in software development: partially done work[4], extra process[4], extra features[4], task switching[4], waiting[4], motion[4], defects[4]. Although items like management, project tracking would not directly contribute to the production process, they are still very important because wastes mentioned above can be minimized by these systems.

The second step(toolkit) of implementation introduced by the author is value stream mapping. The author bring up the comparison between traditional development process and agile development by value stream map. It is very obvious that where the delays and waste are in process. From this, we are well acknowledged of the power of the value stream map. It is very helpful for management level to take an overall view of the process and uncover all hidden waste which should be eliminated. A value stream map is also a effective tool that development team can acknowledge the biggest opportunities to deliver value and expediate the workflow. The author also give an simplified action model to create and apply the value stream map in the last part of this section.

From the first chapter, we have known some principle about lean thinking in production, but the lean principles cannot be transplanted directly from production mode to software development mode. “Many attempts to apply lean production practices to software development have been unsuccessful because generating good software is not a production process” The author noticed that, “it is a development process. ”[22] So from this chapter, the author began to show some thinking tool about how we can do the lean software development. In the author’s opinion, development is quite different from production. If we think production as making dishes, then development is making recipe. It is easy to understand that when a chef is trying to make a new recipe, he might fail several times before he can make out the best recipe. There are several aspects that need to be concerned before considering about development: Quality, Variability,way to face Failure and Design Cycles.

After this the author introduce 4 thinking toolkits. First thinking toolkit is called Feedback. By definition, feedback loop is a method that the developer get suggestions that based on earlier production, and then adjust the roduction.The feedback loop is a indispensable part in developing software, because there are lots of problem that may not be predicted at the beginning. It was pointed out by Winston Royce in 1970 that waiting until the end of to test the system is too late, “the feedback provided by testing was needed early in the development process.”[23] Although this principle have being established early, the traditional way of project management such as waterfall model of software development is still difficult to abandon. This might because that feedback loop is concerned as a threaten to the system, as it might change the predetermined plan. So when an organization has software development challenges, there is a tendency to impose a more disciplined process on the organization, which, as the control theory predicts, makes a bad situation worse. In most cases, increasing feedback, not decreasing it, is the single most effective way to deal with troubled software development projects and environments. The developer should run tests as soon as the code is finished, checking out ideas by writing code, etc.

The second tool is Iterations. By definition, iteration in software development includes all processes to gain a minimum completed production, from design to deliver.This production will be improved in further iterations.After a brief introduction about the reason why we need iterations, the author shows four steps that need to be done to achieve a good iteration: iteration planning, team commitment, convergence, negotiable scope. Iteration planning means that we need to make sure what should be done in a single iteration. The features that will be implement should be the most valuable part of the business, but the team need also keep it small enough to deliver fast. Team commitment means that the project team should choose a set of features that they can finish in a few weeks, in this way the team members will try their best to find out the way to get the features finished in the time-box. The convergence should be concerned because without doing that, the project will last forever as it don’t have a predefined stoping point. Negotiable scope is a strategy to achieve convergence.

The third toolkit is Synchronization. This is important when multiple teams are involved in the same iteration. In this part, the author introduces three different ways to synchronize the work, known as Synch & Stabilize, Spanning application, and Matrix. The first method is realized by building a small batch of work in a short period of time and then test it. In this way the manager can make the developers be synchronized. The spanning application method means that a small advance team will develop a simple spanning application which works continuously during the iteration. The spanning application can be policy or introduction or something like that. Besides these two methods, matrix is often chosen when different teams are not stay in the same place, thus Synch & Stabilize won’t work. This approach stars by developing interfaces between teams, after which each team can only deal with their own subsystems.

The last tool is Set-Based Development. “In set-based development, communication is about constraints, not choices.”[24]The main aim of this tool is to make communication more efficiently. To apply this toolkit, the manager should develop multiple options, communicate constraints, and let solutions emerge.

So in this part, the authors brings up the priority of concurrent development over sequatial development and what is "decide as late as possible"[5] and why. They start with the comparison of cost of adapting changes to die design in American and Japanese car production process in 80s last century. The cost in Japan is much lower not due to a better original design but because they are using a more efficient and change-tolerance method, concurrent process. And same in software development, programing has shown great improvement after switching to concurrent development[6]. According to the book, instead of traditional depth-first design that constrains high-level and low-level decisions together, the new developemt applies breadth-first approach in design that high-level problem or changes can be adapted with much less cost since breadth-first method allow engineers to consider most options so inevitable changes or problems can be found and worked out as soon as possible which will overal cost much less time in deliverying the final product. Also, the design of a product should be more flexible to accept possible changes that could occur in development process or after release to avoid cost escalation since software is something need lifetime upgrade. Decide as late as possible could help with it since it could help minimized the high-stake constrains and apply breadth-first approach to make them as correct as possible. It also can reduce the decisions number leading to changes and the cost escalation factor for changes. So using concurrent development and decide as late as possible help reduce the cost by minimize the constrains of a product to accept changes and reduce the changes cost.

The first tool introduced in this part is options thinking. As mentioned by the authors, the attraction of satisfication guaranteed warranties is that irrevocable decision is not preferred by people when there is uncertainty. They use HP printer sales as a good example of how delay decisions helps in this condition that they make the electrical configuration of their printers after the orders are made so there could be adjustment among countries with different configuration. This is called "option open"[7] that delay the decision that make less constrains on options until the uncertainty gone. Another example given is the Microsoft which also gambled in options by providing several systems that allow them to hold most options in market to reduce risk. And same in software development, minimize the options limit by delaying decisions until the customer requirement is clear or mature technology has been achieved would reduce cost in future changes or adjustment. However, the authors emphasize that options thinking is not something guaranteeing success but move the development into a favorable direction when there is uncertainty. To well apply it, engineer must be experienced and research much to decide which options should be open instead of keeping everything open.

The second tool is the last responsible moment. According to previous approach, concurrent development allow delay commitment but the delay has to be a deadline. The last responsible moment is the toolkit to help make decisions. It is the due date that commitments have to be made to eliminate other important alternatives, or decisions would be made by default[8]. The authors shows several practical tactics to help. These tactics not only help make decision before the last responsible moment but also teach us how to decide and improve the last responsible moment, such as "share partially complete design information"[9], "organize for direct, worker-to-worker collaboration"[9], "develop a sense of how to absorb changes"[9]and etc..

The third tool is making decisions. In this part, the authors have summarized some components in previous tools and talk about approaches in decision making. First, they talk about the comparison between depth-first approach and breadth-first one as mentioned in the first tool and claim their advantages and risk and see conidtions which approach should be applied. Breath-first approach is normally the more effective one since it has less limitaion and requirement. Then talk about the intuitive decision making compared to rational decision making. It is actually pretty surprising that intuitive decision making performs better in most conditions that high-stakes mistakes is more likely detected because rational decision would suffer tunnel version and timing. The authors have given examples in fire department and the Marines to support this opinion which is pretty convincing. At last, the author clarify that the rules that decision making follows must be simple. Simple rule can help well in flexibility, robustness and self-organization[10]. It allows people to act quickly without waiting and as mentioned before, quicker action/response allows later decision making.

This chapter is stared with a series of examples of real life delivery in different businesses. Using those examples, the author trying to tell us the benefits of fast delivery: “Rapid delivery means companies can deliver faster than customers can change their minds. It means that companies have fewer resources tied up in work-in- process, whether inventory or partially done development. When work-in-process represents risk, rapid delivery reduces risk”[25]. Deliver as fast as possible can not only reduce risks, but also a complement of decide as late as possible (which is already introduced in the third chapter), this is because you will have longer time to delay your decisions if you can deliver faster.

There are three toolkits related to fast delivery. The first toolkit is called pull system, it is a method that can assure that employers always know what they should do, so that they can make full use of their time, and make largest contribution to the company. The main strategy of pull system is letting the customer pulling work instead of using a schedule to push the work. In 1980s, many manufacturing plants used to use material requirements planning (known as MRP) software to schedule their business. The workers are pushed to work based on what the schedule tell them to do. Similar method is also used in software development. The disadvantage of this method is that if there is even the slightest change, there have to be a totally new plan, which will cause a restart of the whole working flow. After many years struggling, people began to use kanban system to deal with the scheduling problem. “Kanban is the enabling mechanism of just-in-time. It is the thing that tells people and machines what to do from hour to hour in order to achieve optimum plant output.”[26] Kanban is now known as one of information radiators of software development systems which shows what need to be done and what is already done and who is working on what.[27]

The second toolkit is queuing theory. The software development process is actually a queue, in which every batch of code need to be built, debugged, and tested. The queuing theory provides a thinking about how to find the bottleneck in software development, and how to solve it. In the author’s point of view, cycle time is the fundamental measurement of a queue, it is “the average time it takes something to get from one end of a process to the other. ”[28]. So our main aim here is to reduce the whole cycle time. Two methods can be done to solve this problem: steady rate of arrival, and steady rate of service. The way to control the rate of arrival of work is to release small packages of work, which in software development, can be translated as release small batch of code.The way to remove the variability from processing time is increasing number of people that process work in a single queue.

Cost of delay is the third toolkit being introduced. This thinking tool is quite important when you are trying to determine whether you need to buy a tool to speed up development or not. According to Preston Smith and Donald Reinertsen in their book Developing Products in Half the Time, the benefits of rapid development are usually larger than you might expect. So, before you turn down the tool request, you should put a price tag on time. In this part, the author provides a series of economic model to drive development decisions, such as product model and application model. These model can help you to tradeoff decisions.

This chapter start to talk about the toolkits to improve the satification and manufacture efficiency. The authors start his point by going back to the historical period that traditional scientific management start turning from a impressive method to a source of dissatification in the industry and being challenged by the lean development method. After several failed reformative versions, people realized that it's time to make essential changes. After some exploration, the idea "moving decisions to the lowest possible level in an organization while developing the capacity of those people to make decisions wisely"[11] has been raised and accepted. Empower is proved to be a very good method to keep workers motivated and improve the efficiency. CMMI, an advanced verison of CMM, is introduced as a successful mature management tool applying the above principals[11].

The first tool introduced to empower the team is self-determination. The autors raise the sample that NUMMI (New United Motor Manufacturing)[12] turned a disaster plant into one of the highest productive plant in the US. It turns out the crux of previous disaster is "the workers did not appreciate being told how to do their jobs."[13] which lead to the lack of motivation. The secret is the toolkit which is gonna be introduced in this part, self-determination that workers are trained to make decition themselves and work in team made of workders instead of being commanded by manager. The author using this sample to claim that let workers decide by themselves instead of told by higher level people who is less experienced can fully inspire their capability and motivation. The author also clarify in a easily understood words, "Treat People Like Volunteers"[14].

The second toolkit followed is motivation. "Passion and camaraderie create an intense atmosphere in which anything is possible"[15], the author descript so to indicate the importance of the motivation. Using the example of 3M, the author shows us the spirit that keep the company growing larger and fast. The leader of this company raised great opinions that leads the company culture, such as “Hire good people, and leave them alone”, “If you put fences around people, you get sheep. Give people the room they need”[16]. Expanding from this example, the authors present us the advantage of motivation and what we should do to help accomplish the purpose of motivation since people should not follow any purpose unachievable just due to motivation. The authors gives us detailed description of how to build motivation correctly and what are necessary to keep it going.

Good motivation and purpose need good team to push it forward and a team leader is a key component of a good team. So the third toolkit given is leadership. In this part, the authors introduce the personality and ability that a leader should maintain and where the leadership should fit in in development process.

The last toolkit in this part is expertise. With only motivation and leadership, work won't work well unless people on their work have related expertise. The authors present the example of Nucor and Xerox to show how helpful workers' expertise related to their responsibility would be. From these examples, we can tell that it is important for team and company to address expertise level of workers and put them on right duty.

This chapter is talking about toolkits related to integrity. The integrity is divided into two dimensions: external integrity and internal integrity, which in this book being renamed to perceived integrity and conceptual integrity. “Perceived integrity means that the totality of the product achieves a balance of function, usability, reliability, and economy that delights customers. Conceptual integrity means that the system's central concepts work together as a smooth, cohesive whole. ”[29]

The first two toolkits are perceived integrity and conceptual integrity. To apply perceived integrity, we should establish first-class customer-developer information flows first. There are several techniques can be used here. Firstly, the people who judge the system’s integrity should have immediate access to development teams. Secondly, ask customer to test the production, which can provide best customer-developer feedback. Next, a type of language should be established between user and developer of which the customer can understand while the developers can use it directly. Finally, there should be a master developer as a manager to connect between the developer and the customer and make sure the product is just as the customers expected. As for conceptual integrity,
it is also realized using four techniques. The first technique is try your best to use existing parts. The second way is to begin to write the software before the design detail are finalized. After the software is partially finished, show it to customers to get feedback. The third method is letting most experienced developers being involved in the most critical part of code, they will make sure the user interface is designed well. Last, there should be a master developer to control different teams to work together as a whole.

The third toolkit is called refactoring. This toolkit is a complementary to conceptual integrity. When new features are asked by customers, and when the system structure looks not healthy enough, refactoring should be applied. So the most important thing is to find out in what kind of situation the system can be considered as ‘not healthy’. In the author’s point of view, there are five characteristics, each of which when lost, will cause the software architecture unhealthy. The first factor is simplicity, which means the functional design should never be too complex. The second factor is clarity, this factor is similar as the first one, which means that code should be easy to be understood. The third factor is called suitability for use, this tells us that every design should meet its original purpose, in other words, the production should be easy to use. The last two factors are No repetition and no extra features. The former means identical code should only exist once, while the latter tells that if a part of code is no longer needed, it should be deleted.

The last toolkit is testing. As to the author, testing is a main part in software development. First, tests unambiguously communicate how things are supposed to work. Second, they provide feedback on whether the system actually works the way it is supposed to work. Third, tests provide the scaffolding that allows developers to make changes throughout the development process, making tools such as last responsible moment, set-based development, and refactoring useful in practice. When development is done, the test suite provides an accurate representation of how the system was actually built. Finally, by developing and maintaining test suites for all systems in production, making changes to production systems that interact with each other can be done safely by running a full suite of tests for all related applications. [30]

"A system is not just the sum of its parts—it is the product of their interactions"[17], the author starts this section by the definition of what is a system. According to them, system thinking is the way that consider a organization consisting of parts working together systematically. The authors believe that it would be a good way to predict difficulties and problems by applying system thinking to create simulation based on a organization's agreement and policies since any problems confront could also be predictable in the organization. Then the authors introduced three basic patterns: limits to growth[18], shifting the burden[19] and suboptimization. All these patterns are to help solve underlying problems from the very root instead of just fixing the symptoms to make things worse.

So to optimize a project process, first thing(toolkit) is measurements. The authors raise the example of Armstrong's race strategy to explain to us why top measurement on subtasks may not lead to a optimized result. It is very vivid and easy to understand by doing such analog since development subtasks are same as stages that cost in each of them will affect the whole result. "maximizing local measurements is often at crosspurposes with optimizing the organization as a whole"[20], the authors have concluded so since the local measurements may lead to idle period or extra features in other tasks which cause the hurt to the whole system. Then the authors present us reasons to use the pattern suboptimize and how to use it correctly in measurement.

To work as a whole, trust is a very key features that different groups need to hold to work together. So the second toolkit introduced is the widely used trust guarantee - contract. The authors go from the Toyata's cooperation with US suppliers to indicate that different parties need contracting to help them build trust on each other to work together. If groups have to guard against their partners to take advantage from them, work together as a whole is just a joke. After clarify the importance of contruct, the authors shows us different contracts and their application conditions, such as fixed-price contracts, time-and muterials contracts, multistage contracts[21] and etc..

As the last chapter of this book, no more toolkits are introduced.The author are trying to give us some advise about how to gain the understanding of lean principles and how to be a manager of a company. I would highly recommend you to treat this chapter as a relaxation after you finish study all 22 toolkits, just as the author said here, "Toolkits are usually packaged with instruction sheets and a warranty card, which most of us try to ignore", this chapter is something that we may not care, but still important:)