Lean Software Development: Meshing With Extreme Programming for Increased Productivity

Transcription

1 Lean Software Development: Meshing With Extreme Programming for Increased Productivity Philip Ridderheim Lund Institute of Technology, Sweden March 03, 2013

2 Contents 1 Introduction 1 2 Research Method 1 3 Background Lean & TPS Toyota Production System, TPS The Poppendiecks & Lean Extreme Programming, XP Results Kaizen Kanban The essence of Kanban Constraints theory Just In Time, JIT & Decide as Late as Possible Visual Factory, 5S Conclusions 11 6 References 12

3 Abstract There is a widespread perception that Lean Software Development and Extreme Programming, XP, are not compatible with each other because of the fact that they focus on eciency in an organization from two ends of the spectrum. Lean from an organizational standpoint and XP from a developer standpoint. This report looks at the possibility of meshing the parts of Lean with XP in an eort to improve XPs lack of focus on organizational matters. Three parts of Lean were chosen as the most relevant, Kaizen which focuses on the continual improvement of a product thru small steps as they become needed. Kanban which gives the development team an easy way of checking the development status and lastly the practice of Visual Factory, the need for standardizing and keeping the workspace clean. This report concludes that Lean and XP are meshable to a large extent as XP lacks focus on the functionality needed to support the development team which Lean focuses heavily on.

4 1 Introduction The basis for this paper is the current popularity of the software development methodologies, Extreme Programming, XP, and Lean Software Development and their perceived incompatibility due to the fact that Lean looks at organizational structures and XP revolves around the developer; this perceived incompatibility is further perpetuated by the fact that the lean movement has its roots in the very ecient Japanese manufacturing industry and XP in the more laid back software development world of teams whose culture isn't understood by outsiders. Even though their are fundamental dierences between these two mindsets there is still valuable information that is applicable to both sides. By looking at both and locating which lean practices mesh best with the XP methodology a more improved methodology can be created. Though as with methodologies in general, they need tailoring to each specic situation. Therefore this paper will look at the fundamentals as not to skew the results in favor of a particular tailored instance of XP. 2 Research Method While writing this paper the possibility of using the development groups of the course EDA260 at LTH might have been done. It would not have been a viable and academically sound base for making any conclusions applicable outside the course as: The course does not use strict XP. There are alot of deviations on important points in the XP methodology. The sample size would not be large enough to draw any conclusions as to the methodologies themself. The knowledge level of each student varies to a large extent from fairly seasoned and commited to uninterested student only looking to get their required academical credits. The workload of the student vary as they have other courses. Virtually none of the students taking the course have previously worked in an agile development project. None of the coaches have previous experiance with coaching an agile development team (12)

5 Other studies are carried out at the same time making the working styles of each team varied. Considering these facts, using the development groups to conduct a study is not a viable option. Therefore a traditional documents study is opted for with a focus on looking at the fundamental principles and practices behind the methodologies (12)

6 3 Background In this section the origins of Lean software development and how it diers from it will be explained, then Extreme Programming will be described. Both methodologie's fundamental values will also be explained. 3.1 Lean & TPS Many attempts have been made to adapt the seemingly perfect methodology of the Toyota Production System, TPS, to other elds of engineering. These attempts have had a varied amount of success, mainly due to the fact that TPS was created solely with Toyota in mind, it's creator didn't want to create a great production methodology. The goal was simply to make Toyota a more successful and ecient company.[12] Even though the creators of Lean don't explicitly discuss its relation to Lean Manufacturing[13], another ospring of TPS, it can be assumed that it was used as a base when Lean Software Development was designed Toyota Production System, TPS The Toyota Production System is one of the key factors that have made Toyota into the company it is today. The systems creator Taiichi Ohno created two concepts. The rst has its roots in Henry Ford's book, Today and Tomorrow, 1926, which provided the basis for the production system and the other was based on an idea by Kiichiro Toyoda, the founder of Toyota. The idea was called Just-In-Time and was formulated by Ohno after a visit to an american supermarket in This second concept provided the basis for the continuous materials supply part of the TPS system.[12, 9] TPS builds on four categories of principles [9, 10]: Long-Term Philosophy The Right Process Will Produce the Right Results Add Value to the Organization by Developing Your People Continuously Solving Root Problems Drives Organizational Learning The main objectives of TPS are to remove overburden (muri) and inconsistency (mura), and to eliminate the seven wastes (muda), by the use of processes that avoid these problems.[12] (12)

7 3.1.2 The Poppendiecks & Lean Following the popularization and widespread implementation of Lean Manufacturing, the ospring of TPS, Mary and Tom Poppendieck set about adapting the philosophy to software development; The end product is Lean software development.[13] It's seven core principles are closely related to the ones of Lean Manufacturing. The principles can be explained as[13, 14] : Eliminate Waste - This principle has it's roots in the seven wastes that TPS describes. Amplify Learning - Testing is an essential part of the Lean concept. The learning curve is sped up by the usage of iterations that are short that are coupled with refactoring and integration testing enabling quick detection of inconsistencies. Decide as Late as Possible - Customers rarely know what they actually want so building complex structures that eventually might need large refactoring can end up costing more than the customer or the developer was expecting. Decide when all the relevant facts are known and not too early in the development process. Deliver as Fast as Possible - When the facts are clear, deliver as fast as possible while maintaining quality will help ensure the success of the project. Empower the Team - The actual person doing the work usually has a greater understanding for what he or she is doing and therefore should take part in the decision making process. The aphorism "nd good people and let them do their own job"[8] describes it best. Build Integrity In - Both perceived and conceptual integrity are important as they help ensure the continued commitment of the customer and developers to the project. See the Whole - By decomposing large tasks and standardizing dierent stages of development defects can more easily be found and their root causes eliminated (12)

8 3.2 Extreme Programming, XP The Agile method Extreme Programming was developed by Kent Beck and described in his book Extreme Programming Explained: Embrace Change. The method is "lightweight" meaning that delivering fast is of utmost importance to ensure economical worth. Instead of analysing and designing a structure one should expand the code as need arises. XP also dictates that instead of specialising the team members they take part in all parts of development such as writing analysing, designing, coding, testing and integrating. By having as much face-to-face communication as possible the need for documentation is limited.[2] XP is built around 12 core practices[3]: Fine Scale Feedback Pair Programming - Development should be done by pairs of two where one is the driver, i.e. the one doing the actual programming. THe second developer lls the role of the navigator, he makes sure that they stay on track. Planing Game - This is where cost estimation is done by the development team and the customer. Test Driven Development - All development should be based on tests. The tests are the verication that the requirements set forth are covered. Whole Team - The customer is considered as a user of the system and should therefore be part of the development process as he has knowledge about the products target domain. Continuous Process Continuous Integration - The development should always be focused around the latest version of the code. To enable everyone on the team to stay up to date they should commit/upload their work every few hours or when a signicant step has been achieved. Refactoring - The code should be refactored as soon as someone sees a need for it. The sooner a refactoring is undertaken the quicker it will be done. Limiting the wasted time using obsolete code. Small Releases - Releases should be done as often as possible. This will enable the customer to gain condence in the progression of the project (12)

9 Sharing Understanding Coding Standards - A coding standard should be agreed apon by the entire team and should be adhered to at all times. This will make it easier for a developer to work on other developers code. Collective Code Ownership - All developers on the team own all the code. This will ensure that developers focus on xing problems instead of trying to nd who should x the problem. Simple Design - The simplest implementation tends to be the quickest and therefore the most cost eective. Since prot is the main focus of most ventures costs should be kept to a minimum. System Metaphor - A story that describes the system and how it is intended to work. This story must be understood by all parties in the project, developers, managers and customers alike. Programmer Welfare Sustainable Pace - The development should be undertaken at a pace that is manageable and does not overwork the developers. Beck advocates the 40-hour work week, no overtime (12)

10 4 Results The result of the research and the conclusions based on that research will be presented in the following sections. As the main focus of this paper is improving XP, the results will concentrate on what principles and practices in lean software development that can be meshed with XP and improve it. 4.1 Kaizen The Kaizen principle of TPS dictates that the evolution of the product should come from continuous improvement[13, 14]. It is one of the foundational building blocks of TPS. This meshes very well with software development and especially software conguration management. The concept of Kaizen works very well with XP in the fact that it has a direct counterpart in XP, "Continous Integration", that lls the same function. XP also has two more practices that Kaizen meshes well with, Refactoring and Small releases both work towards focusing the developer on present problems and not on possible future problems. 4.2 Kanban The Kanban practice is one of the most prevalent ones from the TPS method as it can be transferred to agile software development with little eort. The specication set up by the Poppendiecks didn't specify any attributes[13]. On the other hand there has been a lot of activity around making Kanban practical for the Software Development community. These works do not specify what states should be present, but rather it gives a framework for how a state should be represented, and what parts should be present for each state[6], whether there should be: Constraints on the parallelism of the work in progress. What is required for the task to be moved and considered done for the particular state. These attributes enables the development to be dened up front without having to generate large documents and work can begin earlier. The most important gain with the Kanban practice is the communicability of the current status of the work in progress. [4] (12)

11 4.2.1 The essence of Kanban The practice is easily understood and to a very large extent self explanatory. It revolves around using cards that represent individual tasks. These are then moved or pulled thru the development process. Each step in the process is represented as an area on the Kanban board. The steps are organized in their progression with a pool of tasks to be undertaken at one end and at the other end a completion pool where tasks that have gone thru the entire development process. Under each step in the process a "denition of Done" is attached dictating what critera the tasks need to fullll to enable it to be pulled to the next step in the process. To maintain focus and avoid the overstreaching of the team, limitations can be imposed on a specic step. In the example board below only four concurrent tasks are allowed to be developed at one point in time. This ensures that tasks are pulled forward and in this case to "Granskning", which is swedish for auditing.[11] Figure 1: An ordinary Kanban Board as used in the course EDA260[11] As XP's development methodology is based around stories[2] Kanban makes for a good complement as it gives the developers a good visual overview of where the current state of development is at. Kanban also enables the on-site customer an easy way of keeping up to date as Kanban is very intuitively designed.[4] This eliminates the need for a specic set of routines related to preparing documentation and brieng the on-site customer and keep him/her up to date (12)

12 4.2.2 Constraints theory An important part of the Kanban board is the constraints theory. Meaning that by constraining the concurrent work being done overproduction, extra/unnecessary features, can be mitigated[7]. In software development this gets another meaning as well; it also helps to avoid the shared data problem as described by Babich[1] by limiting the amount of parallel work being done reduces the risk of merge issues occurring. This is a very important aspect in XP as it is based on making changes quickly and not waste eort on things that the customer hasn't asked for.[2] Just In Time, JIT & Decide as Late as Possible The Principle of "Just In Time" is one that meshes very well with XP due to the fact that XP advocates not spending eort on non essential development. XP also dictates that only the simplest and most cost-eective solution should be used as all else is wasted eort. This is in its core a fundamental change in how development/production is viewed as traditional development practices suggest that development should be done right from the start.[2] 4.3 Visual Factory, 5S Cleanliness and eciency is something that many associate with the japanese industry and especially Toyota. In software development cleanliness is very important as it will enable developers to faster nd what they are looking for. A clean workspace will enable the developer to get a better overview of the work to be done. One practice to help with the overview is Kanban as discussed in section4.2. The visual factory is a principle that focuses on the workspace. It is built upon 5 principles which can easily be transferred to software development:[5] Sort - Focus on what the customer is asking for. Only build what is needed and required. Deconstruct customer requirements into their smallest valuable parts. Don't spend eort on activities that won't result in any added value to the product or the customer. Straighten - Organize teams and projects in order to optimize the ow of work and lessen the development time for each part. Decide only when necessary. Project Control Tools such as Kanban boards should be used. Involvement of the entire team for major decisions is important (12)

13 Shine - Store and remove unused modules, features, components and so forth. Remove obsolete parts. Remove everything that does not add to the current value of the project. Standardize - The 3 S's should be reinforced by the development processes such that they are a natural part of development yet exible enough to deal with unforeseen changes. All team members should be well versed in the processes. Sustain - Evolve the system as new needs arise and old ones change. Empower team members to take part in the process evolution. Make the processes visible by using measurable value points that can be presented to team members. The concept of the Visual Factory is completely left out of the Poppendiecks book even though it is an important part of what makes the TPS methodology work.[13] The XP practice of pair programming and coding standards make visual factory a very applicable practice as having a standardized development environment used enables other developers to more quickly get up to speed which the layout of the environment and the code when they pair up with other developers.[3] The practise also relates to a general practise in software development of having a clean repository, meaning that code in the common repository should pass all intended tests. Both Lean and XP both have practices and principles that looks at the continual improvement of the developers, though XP looks more at the individual developer and Lean looks at the organization. Visual factory helps with ensuring that the improvements go into collective knowledge and not just an individual developer. By documenting and standardizing the environment optimizations will be pushed to the entire organization instead of just beeing implemented in an individual developers environment.[5] (12)

14 5 Conclusions Even though Lean and XP start at opposite ends of the spectrum, Lean from the organization downwards and XP from the developer up, both have the same intended end product; A more eective organization. Where XP lacks in organizational structure Lean compliments it very well. Xp's main attraction is the fact that it is easy to tailor and is simple enough to be taught quickly but as it is simple it misses a lot of important ground layer practises. This is where Lean comes into play with its organizational focus. The principle of Kaizen which is a very well understood concept in the software world though as a by product of version handling which is probably the base for its inclusion in XP. Kanban with its visual representation of a project's status that enables the development team to quickly and tactually interact with project planning and coordination. This is one of the greatest lacks in XP, the capability of getting a good overview of the projects status. Visual Factory, which emphasizes the need for a clean workspace so that new knowledge is spread and that it doesn't accumulate in one workspace making that individual irreplaceable. Both Lean and XP have large followings but at present there is a lack of meshing between the two methodologies. This might be due to the fact that most organizations use some tailored version of one that inadvertently also uses parts of the other. It might also be due to experts in one are rarely experts in the other. All considered it can clearly be seen that XP at least has a lot to learn from Lean and TPS (12)

15 6 References [1] Wayne A. Babich. Software Conguration Management, Coordination for Team Productivity [2] Kent Beck. Extreme Programming Explained: Embrace Change [3] Kent Beck. Extreme Programming Explained: Embrace Change, 2nd Edition [4] Jesper Boeg. Priming Kanban [5] Christopher D. Chapman. Clean House With Lean 5S [6] Kenji Hiranabe. Visualizing agile projects using kanban boards, [7] Kenji Hiranabe. Kanban applied to software development: from agile to lean, hiranabe-lean-agile-kanban. [8] Pirmin Lemberger. Managing Complexity of Information Systems: The Value of Simplicity [9] Jerey K. Liker. The Toyota way : 14 management principles from the world's greatest manufacturer [10] Jerey K. Liker. The 14 Principles of the Toyota Way: An Executive Summary of the Culture Behind TPS [11] Niklas Hansson Niklas Fors. Kanban i Extreme Programming [12] Taiichi Ohno. Just-in-time for today and tomorrow [13] Mary Poppendieck and Tom Poppendieck. Lean Software Development - An Agile Toolkit [14] Mary Poppendieck and Tom Poppendieck. Implementing Lean Software Development (12)