Lean Management – A Metaphor for Extreme Programming? Michela Dall’Agnol1, Andrea Janes1, Giancarlo Succi1, and Enrico Zaninotto2 1 Center for Applied Software Engineering, Free University of Bolzano-Bozen, Italy {michela.dallagnol,andrea.janes,giancarlo.succi}@unibz.it 2 University of Trento, Italy
[email protected]
Abstract. This work focuses on the analogies and the differences between Lean Management and Extreme Programming. Lean Management (LM) is a management strategy that continuously tries to improve business processes focusing only on activities that provide value to the customer. The word lean means that only activities that increase the provided value for the customer are performed. Any additional activities that can be avoided are cancelled, that influences not only production-related processes but also to management structures. XP is a discipline of software development based on the principles of Agile Methodologies. The term agile describes “the ability to both create and respond to change in order to profit in a turbulent business environment [1].”
1
Introduction
A metaphor is “an expression which describes a person or object in a literary way by referring to something that is considered to possess similar characteristics to the person or object you are trying to describe” [2]. That means that a metaphor points out similar characteristics between two things. It establishes a system boundary that helps to decide what attribute the described object does or does not include. XP and Lean Management have been often compared (e.g. [3]), in this paper we try to establish a metaphorical relationship between LM and XP and to deepen our understanding of analogies and differences. Metaphors have been used by XP as a vehicle to convey information between people who do not share the same working language, e.g. developers and customers. In this way XP experts and LM experts will be able to properly define their respective scopes of actions and identify additional areas for improvement. We use this view of is or is not suggested by Kent Beck on OOPSLA 2002 to focus on where similarities and differences between Lean Management (LM) and Extreme Programming (XP) exist.
M. Marchesi and G. Succi (Eds.): XP 2003, LNCS 2675, pp. 26–32, 2003. © Springer-Verlag Berlin Heidelberg 2003
Lean Management – A Metaphor for Extreme Programming?
2
Background
2.1
Lean Management
27
LM has become a well-known and a successful management strategy. Its principles are those explained by Taiichi Ohno in his book The Toyota Production System [4]. LM and the underlying thinking model are based on an integrated set of industrial principles and methods. Its beliefs are these: value, value stream, flow, pull, and perfection. The first step in Lean Thinking is to understand what value is and which resources are absolutely necessary to create value. Once this is understood, everything else is muda – the Japanese word for waste. To eliminate muda it is necessary to focus on the value stream. You must divide the several steps in three kinds of actions: those that add value, those that do not directly add value but are also necessary, and those actions that do not add value: they must be eliminated [9]. Moreover, emphasis is put on a constant flow of production: set up times of machines are kept short, buffers are downsized and employees in form of teams are entitled to be active in problem-solving: if a problem occurs, worker are allowed to stop the line and to search for the real roots of the problems. Pull means that production is not based on forecasts; the production is delayed until demand is present to indicate what the customer really wants. It may seem that lean system is fragile, because there is not a definitive plan. Instead, the Lean Production is forceful because it acts when the flow of information is maximized and does not anticipate the future. The last principle is perfection: it is impossible to eliminate every kind of waste. You must come near it through incremental steps. The result is a better quality, a decrease of costs, deliveries on time and satisfied customers. 2.2
Extreme Programming
XP was first described by Kent Beck [5], where he describes XP as a “lightweight methodology for small- to medium-sized teams developing software in the face of vague or rapidly changing requirements.” XP let the customer pull the development of the product. XP assumes that the customer has detailed knowledge about the problems to solve, but not about the solution to develop. Only when the development of the solution has started and the outcome becomes visible and understandable the customer starts understanding how his/her problems could be matched to proposed solutions. Then he/she can advise what is missing and what is misleading in the solution.
3
Analogies between LM and XP
In this section we discuss analogies between LM and XP, in section 4 we discuss the differences.
28
3.1
Michela Dall’Agnol et al.
Methodologies
“XP manages teams that produce software; LM manages companies that produce goods.” – this was our first thought when we started to think about the relation of the two subjects. XP is a methodology – “a system of ways of doing, teaching or studying something”, LM talks about management – about the “control and organization of something” [2]. So in this view they are very similar: they both teach you how to improve the quality of the desired output – whatever it is – software, cars or other goods. Both developed from the need and for this reason they are very practical. The recommendations they make consider primarily their specific problem domain – XP was introduced for software development, LM as a management strategy to lead producing industries. 3.2
Wicked and Tame Problems
To point out that the two subjects deal with the same class of problems we consider the categorization of problems into “wicked” and “tame” [6]. Some problems are obvious to solve. An example for this type of problems could be the writing of the New Year’s greeting letters. Even a child understands that you are faster if you separate the task into different phases (buying sheets and envelopes, writing the letters, putting the letters into the envelopes, putting a stamp on every envelope). The separation of the task into different phases is an intuitive way to master apparently difficult tasks. In the mentioned example it was possible because it was a so called “tame problem”, i.e. problems that can be analyzed and solved with already well-known techniques in a straightforward way. This “divide and conquer” approach can only be used if the problem can be planned in every detail. If it is not clear what consequences a certain activity has, the mentioned method does not work well. So called “wicked problems” have this characteristic. They can not be described entirely in every step. And therefore it is not possible to solve them perfectly but only to measure the grade of solution. Every proposed solution to a wicked problem is unique. For that reason there is no immediate and no ultimate test of a solution to a wicked problem. Both, XP and LM deal with wicked problems. The one right solution is not possible to find so both have to improve their solutions continuously. 3.3
Muda
Lean Management addresses wicked problems in enabling the company to adapt rapidly to changing demands of the market. The basis is the absolute elimination of activities that are not needed to accomplish required tasks and that hinder the company to adapt to changing demand. Those unnecessary activities are profoundly exposed by Just-in-time Manufacturing. JIT can be described as a Pull from Demand strategy: Only activities that are required from demand are performed. And they are performed exactly the moment they are needed. XP addresses the same idea in different ways: the Planning Game helps to identify requirements continuously and allows easily changing, adding, or removing require-
Lean Management – A Metaphor for Extreme Programming?
29
ments. The customer is directly involved: with Customer-on-site it is guaranteed that even during development the customer can be asked if important decisions have to be made. The use of metaphors helps to establish a common vocabulary between customer and developer so that an efficient communication between the two is possible. Testing in XP is performed before coding so that the test is used to define the required functionality. After writing the test (that in this case works as the specification for one feature) the minimum necessary code to satisfy the test is written. In this way developers concentrate only on creating the needed functionality and the phenomena of Featuritis can be avoided. “Software is growing far too complex ... Each new release of an application is festooned with gratuitous options and an army of tiny icons, the meanings of which I no longer remember [7].” This outline of Featuritis describes exactly the kind of waste Lean Management tells us to avoid. Collective ownership and Refactoring in XP can be seen as the counterpart to “continuous pursuit of perfection [8],” a characteristic of the lean movement. Lean Management implies that the company should continuously try to improve the ability to avoid waste and to improve changeover times. Refactoring in XP has this objective: to constantly improve the code in the sense that waste (wrong, superfluous or difficult-to-read code) is eliminated. Collective ownership guarantees that failures and bugs are quickly corrected. This practice can be found in Lean Management too: everyone has the right to stop the production when a problem arises without having to ask a superior. 3.4
Teamwork
Working together can help to avoid mistakes, to solve emerging problems and to focus on essential activities. The practice of Pair programming in XP and the empowered teams in LM address this matter. By programming in pairs the knowledge about the code is better distributed and the problem field better understood. Teams in LM have similar purposes: The team is directly involved in the process. Tacit knowledge has to be leveraged and for this reason the team is used for problem solving. Human resources play a very important role in both areas, for this reason too much overtime has to be avoided: the “40 hour practice” in XP helps to avoid mistakes done because of tired developers and keeps the team fresh and energetic. In Lean Production also it is stressed that human resources are a vital part of the whole system. For this reason the working place should be clean and everything should be in place. LM states that in that case you should be more motivated workers, and that so accidents at the working place can be avoided. The reaction to employees not willing to integrate in the team – not willing to adopt the new culture is the same in both systems: this employee has to leave the company – even if he or she was a very skilled worker. 3.5
Iterations
Lean Management is very determined to ensure a constant flow of production. This is to avoid extensive buffers between the different stations. The measure to establish is the “Takt time” – a German word meaning “beat” or “cycle” – it describes the speed
30
Michela Dall’Agnol et al.
at which products are ordered by customers and it helps to level production and to avoid excessive capacity costs. In XP the planning game has the task to set the amount of features to develop during the next iteration. Before each iteration completed and planned tasks are compared so that the “velocity” (it could be described as a “tasks per iteration ratio”) is determined. To find out the “velocity” – the speed of the development team helps to “level the production” – that means to constantly develop with a certain stable speed. This (together with the “40 hour principle”) leads to higher quality and to higher job satisfaction. 3.6
Quality
In Lean Management quality is verified after every production step. If a problem arises it is cheaper to stop the production in order to reveal the root cause of the problem instead of fixing the problem afterwards on thousands of defect parts. Lean Management advises always to ask five times “Why” to really identify the root cause of an error. XP deals with quality issues using tests. Unit tests are made by programmers to ensure the correct working of a piece of software, acceptance tests are made by customers to confirm that the implemented functionality corresponds to the required features. The practice “Costumer on site” has the same purpose.
4
Differences Between XP and LM
4.1
Knowledge Transfer
If we consider the environments in which XP or LM should be adopted, and the way in which the ideas are implemented, the two are indeed very different: XP describes a set of practices primarily thought for developers. It wants to ease the tenseness often experienced between developer and customer because of conflicting aims. LM is addressed to the upper-management of a company and sees his task in the optimization of the whole company. In XP the knowledge transfer usually is initiated by convinced developers. They use XP to improve the quality of their software. Often management is not easy to convince to adopt XP because of certain practices that seem to be against common sense like pair programming or refactoring. LM on the other side is a top-down approach. It is a decision of the management to implement lean thinking in their company, to change current processes – it is not only a slight optimization but a radical reorganization of the whole company. In the software word the manager is also a software expert: the idea is that a developer can become a manager. In XP there is a flat system: the manager is seldom been a high-quality developer. Infect, the XP manager must know the software discipline and he can not be only acquainted with the management subjects. In the other side, in LM a worker can not often become a manager. The LM manager has high skills of problem solving and he does not work in the manufacture process. There is a clear division between the chief and the other employees, even if a worker can stop the process if there is a problem.
Lean Management – A Metaphor for Extreme Programming?
4.2
31
Measuring
The productivity of a software team is difficult to measure. You can not use the lines of code written by developers in an hour without controlling the quality of these. You can not estimate the ability of a team considering only the time spent in a day to program. Often, the XP teams work less hours, but they produce software with high quality. Some manager has not understood this aspect and they has dismissed the XP developers even if the final result was optimal. In LM it is simpler to valuate the quality of a product: you can check the physical defects. The productivity of a team can be determined by the numbers of items produced in an hour without defects. The manager has a clear vision about the capacity of a manufacture team. 4.3
Cost Structures
In XP the percentage of labor cost respects of overhead costs are higher than in LM. In LM many costs are linked with machineries, instead in XP many costs derived from the number of developers needed in a project. It is more difficult guess the labor costs in a XP project: every software product is different and every product requires different effort. In LM the costs of human resources are considered fixed costs and so they are simpler to calculate.
5
Summary
We think that many ideas that led to the development of Lean Thinking are directly related to fundamental principles of XP. To deal with wicked problems both approaches try reduce complexity by delaying decisions about produced goods with significant consequences to a point where the answer is easy to find: exactly to the moment when the good is really needed – just in time. The underlying principles of both approaches are analogous: both underline the “Pull principle”, in both cases it is important to banish waste in form of unnecessary work and to empower those who are holding the knowledge about the produced good.
References 1. Jim Highsmith: Agile Software Development – Why It Is Hot! In: Michele Marchesi, Giancarlo Succi, Don Wells, Laurie Williams: Extreme Programming Perspectives. The XP Series, Pearson Education, Indianapolis (2002) 9-16 2. Cambridge Dictionaries Online. Cambridge University Press (2002). Available at http://dictionary.cambridge.org, visited on January 10, 2003 3. Mary Poppendieck: Lean Toolkit (2003). Available at http://www.poppendieck.com/ld.htm, visited on March 10, 2003. 4. Taiichi Ohno: Toyota Production System. Diamond Inc, Tokyo (1978), English translation published by Productivity Inc (1988) 5. Kent Beck: Extreme Programming Explained: embrace change. Addison-Wesley (2000)
32
Michela Dall’Agnol et al.
6. Mary Poppendieck: Wicked Problems (2002). Available at http://www.poppendieck.com/wicked.htm, visited on January 10, 2003 7. Nicholas Negroponte: Information Overbundling by a Monopolist (1998) available at http://www.mit.edu/~mcadams/papers/featuritis_talk_spring_1998-9.ppt, visited on January 13, 2003 8. Bruce A. Henderson, Jorge L. Larco, “Lean Transformation: How to Change Your Business into a Lean Enterprise,” Oaklea Press, 1999 9. James P. Womack, Daniel T. Jones: Lean thinking: banish waste and create wealth in your corporation. Simon and Schuster, New York (1996)
