Lean Development and Management 1

"Lean? Isn't it just another agile fad?” An Analysis of Lean Software Development and Management

Jonathan Stiansen University of British Columbia

Correspondence concerning this article should be addressed to Jonathan Stiansen, Department of Computer Science, University of British Columbia, Vancouver, BC, Contact: stiansen@cs.ubc.ca

Lean Development and Management 2

Abstract In spite of the adaptive methodology of Agile software development, the harsh reality is still that large IT projects go over­budget by an average of 45 percent and still provide 56 percent less business value than predicted (Bloch 2011). A new method is needed, and Lean Software Development has recently emerged as a popular choice. This report seeks to provide the reader with a synthesis of Lean Software Development’s history, practice, and misuse. It also seeks to enlighten the reader as to the role of project management within a Lean organization. The method of analysis is through the summary of papers, blogs, and book content. The reader should emerge with a clear knowledge of its origins, basic tenets, it’s efficacy, and the issues involved with implementing it. Many of the mentioned papers target various case studies where excellent efficacy has been reported or measured. Said papers attempt to show that Lean Software development can give some gains of over 300 percent when adopted fully, and even by adopting some tenets of Lean Thinking one organization saw a decrease in mean development time by 73 percent (Middleton 2012). It is also found that there is a great need for further research and study within the field of Lean Software Development (Sjoberg 2012), especially within the field of Large Scale Systems (Pernstål 2013). While there are lots of benefits in becoming and Lean company but there are also inherent downsides to attempting to pilot this program. The author finds that lots of care should be taken when evaluating whether or not Lean is a fit for the company, and how much support it is willing to give. Lean can make people uncomfortable (Middleton 2012), or simply not fit within the company’s management and dynamic (Ahmad 2013). Additionally it is costly to implement and may need a rehaul of the existing businesses structure to proceed effectively.

Lean Development and Management 3

What is Lean?

Lean is a philosophy, coupled with a set of evolving context specific practices. It’s not reducible to only a way of running a business, or ‘tried and true’ steps to succeeding. Instead it’s principles can be applied to many, if not all, areas of ones life and business. In some blog posts and many forums individuals refer to Lean as the desire to eliminate waste, some equate it simply to the tool ‘Kanban’, and many believe it is simply another agile methodology. The reality is much more complex, and nuanced.

History and Context of Problems

The more known history of Toyota starts in the 1900s . Henry Ford started introducing 1

interchangeable parts into his automotive business, which allowed extremely fast construction of his automobiles. After coming to america to study Ford’s manufacturing plants, Sakichi Toyoda the father of Toyota, admired the effectiveness of the measure and decided he would like to enter the automotive business. The contributions of Taiichi Ohno ­ a consultant, Shigeo Shingo ­ an employee, Sakichi Toyoda ­ founder of toyota, and lastly Kiichiro Toyoda ­ Sakichi’s son, are foundational and they influenced all coming Lean philosophies. Over the course of a few decades Toyoda, now called Toyota, created the philosophies of Just­In­Time, FLOW, autonomation, non­stock production, the ‘Five whys’, and perhaps the most popular: waste elimination. These are crucial tenets of the Lean manufacturing and form a basis for the current topic, Lean Product Development.

The post World War II period proved a catalyst for Toyota. For instance after World War II, Japan was in a state of disrepair ­ many plants in Japan were immobilized and needed to get back up and running. The U.S. send consultants over to assist in this including Deming, Juran, and Shewhart. Deming was ineffective at convincing America plants to improve quality and management. However the Japanese listened and implemented, to the extent that the pinnacle of achievement for a Japanese company is the 'Deming award’. By the mid 1960s Toyota started the philosophy of mistake proofing, or zero inspection. This required more interaction from employees and based off the principles learned from Deming ­ Toyota decided to empower employees to have a large influence in problem solving. This became a central pillar of Toyota, namely “respect for people”.

The remaining history and efficacy of the Toyota production system in Japan is impressive. Its important to note that it was not widely used or adopted in Japan until the late ‘70s. Other manufacturing companies had been producing based on ‘economies of scale’, which used larger batch sizes to enable machines to be continuously running. For the previous decade the country had been wealthy and manufacturing plants were able to sell all their products. In 1973 Japan went into an economic downturn, and factories that once could sell everything they

1 See appendix A for summary of some pre­1900s foundations for Lean Production

Lean Development and Management 4

produced created wasted parts and were unable to be competitive with Toyota. This led to a more widespread adoption of Toyota principles in Japan. American companies in the late ‘70s and early ‘80s had already started to seek to understand how Toyota was thriving, at this point Toyota now had 2% market share in the U.S.. This led to many consultants, and companies attempting to implement independant parts of, what they understood to be, the Toyota Production System. Largely it was misunderstood and poorly implemented. In the ‘80s Toyota's market share grew to 3% in the US. While the number seems small at first glance it’s important to recognize it as a growth of 50%.

The 1990s were tough economic times, where products were starting to be mass produced by the cheaper labour in China and other less developed countries. Many of Japan’s manufacturers downsized and were unable to sustain the same level of employees. Even in these conditions in the U.S., Toyota’s market share grew to 8%. The market was ready for Womack and Jones, from MIT who in 1990 wrote the book “The Machine That Changed the World” based on their collective research done at Toyota. This book opened up North America to Lean thinking, and enabled other companies to attempt to emulate Toyota. Today Lean has emerged as a philosophy which is very difficult to duplicate because of current corporate structure in North America as much of the production in North America is based on Economies of Scale. Lean still has tremendous power, not least of which is the way in which it respects the individual, and trusts that they are competent to make decisions.

Lean Production Tenants

The philosophy ‘eliminate waste’ is perhaps the most cited tenant of Lean. However, eliminating waste is a just a byproduct of a Kaizen culture which, according to Toyota’s past president Gary Convis, is one of two pillars of thought and philosophy in the company. Kaizen means continuous betterment or has been coined: continuous improvement. Some methods are used to measure and quantify nearly everything that is being done at Toyota so that the company can be objectively improving, continually. To continually improve Toyota documents many different types of waste including materials, time, personnel, unplanned work waste ­ and takes steps to cut it down.The second pillar is “respect of people”, and it’s important to note exactly what it means. It involves empowering people to make more decisions involving their respective areas. It also involves boundaries for employees to operate within. Its also about trusting them to assist each other, and give important input. This pillar, which empowers individuals is key for implementing a successful Lean system.

To bring the pillars to realization some practices have been introduced. Just­In­Time (JIT), embodies creation and building of products. It represents the process of letting the system ‘pull’ what is needed through each step. It manifests itself in Non­Stock production, where you do not stock more parts than are absolutely necessary. This cannot be done naively, there usually must be systems in place to allow this; in the context of manufacturing, interchangeable parts on machines enable this. This ties in with limiting work in progress (WIP) to maximize the FLOW

Lean Development and Management 5

of a system. FLOW can be distilled to creating as little resistance in an organization as possible, i.e. minimize variance. This can be achieved with setting up an organizational cadence, and creating a unified vision . FLOW and cadence often require a company to put standardization processes in place.

Autonomation is the ‘automatic’ detection of defects, and it is ‘autonomous’ of people, thus: Autonomation. Even with modern day technology this can be difficult, as early as 1930s the Toyoda looms had a mechanism in which if a loom did something unexpected it would immediately stop without human input. This becomes an important feature in Lean Software Development as well.

Zero inspection (ZI), this is partially implemented through Autonomation. ZI’s goal is for there to be no need to manually inspect a product. This first involves quality being build in, and autonomation is the key here. There is also an element of ‘Mistake Proofing’ being built into the design. In other words, make it impossible for a mistake to happen from any possible source.

The ‘five whys’ is an illuminating term for ‘get to the root of the problem’. Essentially keep asking until you are at the root of the problem, this involves literally going to the plant floor to discover the problem in manufacturing. A manager is expected to go all the way from the sales office to the production line if that is where the problem originated.

Lean Product Development and Management Principles

An issue that is not discussed in Lean manufacturing is, “how do you move from the wrong ‘starting point’ to a near optimum solution?” For instance, you can optimize your whole process, and work to perfection but if you’re working on the wrong project ­ it still may not succeed. To develop new models of cars Toyota has re­innovated the Lean system to create the Toyota Product Development System, which is further generalized into Lean Product Development (LPD). Lean product development has been broken down into principles by multiple authors. Most prominently Kennedy and Liker, here I’ll discuss Kennedy’s.

Kennedy (2003) describes 4 main requirements for the Lean Product Development system, of which only numbers 3 and 4 are generally observed or mentioned in the studies. 1. A project is owned and run by an Entrepreneurial System Designer (ESD) 2. Engineering of the product is done through Set­Based Concurrent Engineering 3. The ESD manages through Responsibility Based Planning and Control (RBPC) 4. The team are an Expert Engineering Workforce (EEs)

The goal of these principles to deliver a continuous value stream to the client. Lets explore the definitions through a narrative of a software company:

A company, Gawgle, has decides to release a new product, a Gawgle hat with integrated with impressive technology. In this case the product is a ‘hat’ and there is an expert engineer (the ESD) who is in charge of making sure it’s design, hardware and software development, marketing, and deployment (release) are a success. The ESD then sets a timeline for the project, assigning different synchronization points (SPs) to the teams. These team’s SPs would have

Lean Development and Management 6

certain overall requirements that must be met at the end; a requirement could be either a module, feature, or deliverable. The ESD thereby sets the overall process for the flow of the product. Each team is in charge of creation of their own process, and their own creation of value of their activities. This is RBPC, giving teams responsibility and control over completing their task.

To come up with different designs, each team ­ hardware, software, production, etc. then defines the realistic ‘solution space’, that is the range of characteristics which the product may actually embody. Each team seeks to define sets of possible solutions relevant to their team, based on the solution space. In other words, they will attempt to categorize different areas that they could use to produce the product. For example a software team can seek to come up with different technologies, methods of using said technologies, and different ways that they would be beneficial. Then the team will create versions of those categories to validate their assumptions, and to learn more about them.

At this point each team has its own ‘sets’, or domains of solutions. And each team rotates its sets through to the other teams to validate or invalidate assumptions that were made based on the intersection of the sets. Following the example, the software team passes on the sets to the hardware team, allowing the hardware team to invalidate the way in which the software team assumed their software would interact with the hardware. The hardware team would do this based on their own hardware sets, i.e. hardware categories within the solution space.

This is the process of converging, sets are eliminated or reduced and the product is moving closer to final development. As this process finishes, each team then continues developing their remaining sets ­ to follow the example the software team will then develop more on the remaining sets, and this process repeats until late in development.

The ESD measures the effectiveness of the whole, receives input from teams, and pursues problems all the way ‘down to the shop floor’. They’ll look for ways to maximize handoffs and integrations between teams, changes in the market, and some other aspects of the process ­ while leaving each team to optimizing themselves. The ESD will not interfere with teams between SPs, as the ESD will assume that each team knows how to complete their own task in the best way.

It may seem that creating multiple products and prototypes and continuing developing more than one solution is waste and thus opposite of Kaizen. The reality is that teams are creating knowledge, they have methods in place for keep track of all knowledge for the coming project ­ allowing a company to have a large amount of data on many solutions. They also have a much higher chance of creating an excellent solution, since they can validate assumptions about multiple models.

Within the framework of RBPC, the engineers will all come together to determine their goals for the synchronization point. Then it is up to those engineers to determine the best process and what they will do to achieve the end goal, for each SP period.

Teams are made up of Expert Engineers (EEs), where each team member is working towards mastering their own field. The company supports this by investing in quality training. Managers are those who have mastered their field so well that they can teach effectively to

Lean Development and Management 7

others. When EEs need information or become stuck they are responsible to ‘pull’ the information from its source. Each team of engineers are responsible for determining the best process and goals for their SP.

Toyota has demonstrated that these principles together, while acted in the confines of a Lean organization produce amazing results. The goal of these must be to deliver a continuous value stream to the customer. As an anecdote, in 2006 Toyota product development released 14 new models which was greater than all of general motors. The most impressive part of this is that Toyota has only 70 thousand employees where GM had 360 thousand, over five times as many.

Lean Software Development History

Mary Poppendieck and Tom Poppendieck (2003) first coined the term Lean Software Development (LSD), and they have arguably been the main driving force for Lean Development in software. LSD is build off of the principles of Lean, and has different tools to assist in many of them. This is a description of how those tools came to be.

In 2001 ThoughtWorks, a large software consultancy company, released the first continuous integration server. Continuous integration is the practice of all copies of the codebase (branches) being merged into the main codebase (trunk) often, typically daily. The system needs automatic verification, which ties in with the principle of Autonomation ­ where failures are automatically detected and stopped. This practice helps teams to confront integration issues quickly and develop the ability and courage. Years later a paper entitled “the Deployment Production Line” (Humble 2006) drew parallels between Toyota’s short times between starting a car to finishing a car, and the idea that software could do the same. This is now called ‘continuous deployment’, and with the help of dedicated software, a team could deploy (release) their project quickly with the full confidence that they could ‘revert back’ to a previous version, if failure occurred. This helps to shorten feedback loops which enables the gathering of more data, more quickly. Data allows for honest “continuous improvement”. If the concern is the end user, which is what Lean philosophy would argue, the best possible way to gather meaningful data is to deploy features to them and find out how they will actually use them. This enables the culture of Kaizen (continuous improvement) to be fostered even in development, and to have a focus on delivering features to the end user ­ through pulling.

The entrepreneur Eric Ries released a book based on his past experiences in start ups, and a new model for doing a startup. The book was titled ‘Lean Startup’ (Ries 2011) and took the principles of delivering the Minimum Viable Product, short feedback loops, always improving through metrics, while being adaptive. This has been a catalyst to making “Lean” a household name, however it may have also created some ambiguity in the term.

Lean and Management

When considering implementing Lean management its important to consider all the changes that must be made. As a project manager, a person would assume the role of

Lean Development and Management 8

Entrepreneurial System Designer (ESD). They would be in charge of more than planning and process, additionally an understanding of how everything fits together and the responsibility for its effectiveness is required. Trusting employees will be required, as managers should start to follow problems ‘down to the production floor’ problem solving. That is they should ask the people at ground zero, what the issues are. They should work towards measurement of many things, since being data driven is crucial to Kaizen and Lean culture (Middleton 2009).

A Lean manager will need to invest in training for employees, possibly more than they already did, facilitate more than before, and be willing to build a fragile system where employees are highly valued. A manager must also ask themselves whether or not you are willing to step back from some of their current leadership and encourage others in all areas of the company to be leaders, and to be willing to be lead. The goal must be to foster an environment of collaboration, trust, respect, and accountability. Its not easy.

Note: For lower level managment tips see question below, “if we move to Lean Software Development, what will my role as a team manager be?”

Relevant Standards

As of 2014, there are no governance bodies for Lean product development in North America. One leader in teaching and training is the University of Michigan, whom offer many training courses in Lean for areas ranging from the typical manufacturing, and new sectors such as healthcare. One reason they may have achieved prominence in Lean is that one of the prominent faces of Lean is a professor as of 2014, Jeffrey Liker.

Agile Certification Institute Inc. (ACI) offers ‘Accredited Lean Software Development Practitioner’ is an accreditation to demonstrate that a candidate has knowledge of Lean software development and understands how that can be seen and implemented in software development. As the Lean methodology becomes more popular, there will be more certifications that will materialize.

Tools

As mentioned previously there are different practices within Lean development that can be assisted by tools. Most prominent are Kanban tools, which are used to limit WIP and visualizing work that is going on, and its flow. As of December 2014 the prominent tools are:

1) Often teams use whiteboards and sticky notes to implement a kanban board where the columns are stages in the development cycle, and stickies are work

2) trello.com is a free to use, sharable and customizable board. Most uses of it are to do with kanban ­ however it does not track statistics

3) kanbanery.com offers version control integration, advanced reporting, and compatibility with iOS devices. It costs monthly between $22 for individuals and $228 for large corporations.

Lean Development and Management 9

4) JIRA by atlassian offers many features and has many different customizations offered a starts at $10 for 10 users and grows to over $1000 monthly with additional features added on top

5) Kanbanize.com offers a applications on both iOS and Android, which is also full featured without version control integration. Starts free, and goes to over $349 monthly for corporations.

6) Blossom.io is for all types of Agile project management and includes Kanban, it is likely the most fully featured option and starts at $19 for 5 and goes to $149 monthly for 25 people. This is the most costly service, but also seems to be widely used. To assist with shortening feedback loops, this author suggests determining what

Continuous Integration tools exist for the development platform that a company is using. Then using a trial version to install on your system to enable you to validate your assumptions on integration. If applicable for a given product, continuous deployment is a difficult but excellent practice to adopt, though it is recognized that many organizations are unable to do this.

In regards to communication tools, the Lean philosophy has always held that the most important interactions between individuals are face to face. It stipulates that unless impossible it is crucial to attempt to foster communication it in this way.

Key Publications

Key Books Throughout Lean’s popularity books have been a popular way to spread Lean thinking.

Womack and Jones brought popular attention to Lean in North America with “The Machine that Changed the world” (1990), and later “Lean Thinking: Banish Waste and Create Wealth in Your Corporation” (1996).

Kennedy wrote a book describing the LPD in “Product Development for the Lean Enterprise: Why Toyota’s system is Four times more productive and how you can implement it” (2003), he elaborates on principles of Lean development which can be used for product development. Jeffrey Liker wrote the Toyota way and expounded on what he saw as the 14 principles of Lean Philosophy (2004). Morgan and Liker (2006) then wrote a foundational work 2

for doing product development the Lean way. Mary Poppendieck wrote: “Lean Software Development ­ an agile toolkit” (2003),

coining Lean Software Development (LSD) and bringing a some practical structure into bringing Lean to software development. After Mary and her husband Tom released “Implementing Lean Software Development: from concept to cash” (2007) further elaborating on the turning a team into a Lean software development team.

“Lean startup” by Eric Ries (2011) illustrated the principles of validated learning, entrepreneurship as management, the idea the “entrepreneurs are everywhere” (pg. 8), and the

2 Appendix B has the 14 principles summarized, though the book is recommended for any Lean practitioner

Lean Development and Management 10

need for a short Build ­ Measure ­ Learn loop, so that you can constantly validate your assumptions of value.

The following article illustrates implementing Lean Software Development, which I give

a summary of. It does little to address knowledge creation ­ which was addressed above in the Lean Product Development section.

Lean Software Development: A Tutorial ­ Mary Poppendieck, Michael A Cusumano In this article on Lean Software Development (LSD) Mary and Michael both do a comprehensive job of touching on some notable differences and similarities between LSD and current models such as Agile. They work hard to make key ideological distinctions between Lean and other models, and attempt to make it clear that Lean is not just a subset of Agile, but instead something different and even older. Early they stress the fact that “if Lean is thought of as a set of practices, it doesn’t translate well from operational to development environments” (Poppendieck et al. 2012 p. 28) but instead if one can use the principles of Lean, they can improve the quality of both the software and the processes.

The tutorial covers seven different principles of Lean, which I have distilled down into a key point which I’ve determined from each. The article is already concise, and I recommend reading the article for elaboration.

1. Optimize the whole: Efficient small parts can work against the whole. 2. Eliminate Waste: Measure and identify waste so that it can be removed. 3. Build Quality in: With continuous integration (CI) it will force quality into the product. 4. Learn Constantly: Learn first by experimenting immediately, then get real feedback. 5. Deliver fast: Each department should, and is accomplished with quality releases.

Releases are done with CI and Continuous Deployment to the customer. 6. Engage Everyone: The organization should push important decisions down to the lowest

possible level, meaning each team should be able to form their own process. 7. Keep Getting Better: Know there are no magic bullets ­ measure, act, and learn.

They believe that some parts of agile can help introduce Lean to a company, these include SCRUM ­ in as far as it assists the team with its FLOW. eXtreme Programming (XP) which requires that testing be done before functionality, this can lead to Autonomation which is manifest in automated testing. Kanban is often used in Agile projects and it is a fundamental tool to help teams start visualizing other areas as well.

They finish by specifying that there are parts of agile which are detrimental to LSD, such as the customer/product owner roles. They believe this is because these roles can lead to local optimization within the development team, and violate the ‘optimize the whole’ principle. This is where the Entrepreneurial System Engineer is important. They also believe that Lean can excel where agile stumbles, in that it takes a much more holistic view and seeks to create a complete value chain out of the organization.

Lean Development and Management 11

What are the issues involved with Lean Development? The following questions will be answered through the analysis of at least one paper each.

“If my company transition to Lean Software Development, what will my role as a team manager be? Some agile literature says managers are useless, is that the same with Lean?”

Lean is different than agile when it comes to management, it understands the need for someone with a higher level view to assist. However the role of lower management will still be different than typical organizations. In “Leadership in Kanban Software Development Projects: A Quasi­controlled Experiment” (Ikonen 2010) the authors create a quasi experimental design to see how different managers will lead a Lean team. They found lots of types of waste in different circumstances (p. 90­94), which the Lean team should work to eliminate. However they found that without some intervention from a manager, even teams that recognized different types of waste did a poor job of working to eliminate the waste. The authors believe that change cannot happen from the outside, and thus someone whose role is to facilitate and encourage progress is generally required. They found that the manager who encouraged their team to follow process, which speeds up time and reduces waste by over 25% (p. 95) in the same Lean context.

“We’ve recently switched to agile development, and we’ve heard that Kanban is a good tool ­ but we can’t switch to a different methodology right now. Can we use Kanban?”

A recent paper by Ahmad et al. (2013) analyses the use of Kanban at 19 different organizations. It details different benefits and also challenges. If you have a certain type of agile environment where you are able to speak to a client, you have some control over your own processes, and you can put some supporting practices into place ­ then Kanban offers key benefits to your company (p. 12).

Why would a team have to change other standards to support a kanban board? If the team has no control over how much work it takes in, or is mandated to do everything that comes it’s way ­ you have little or no control over WIP, and you have less control over what is valuable. Combinations of these issues were encountered by almost each organization studied (p. 13). Like any Lean practice, the author recommends that buy in from the team precludes the decision to implement it ­ since the team uses it. So the answer to the above question is yes, probably. If one chooses to implemented it, it is recommended to do it gradually (p. 14). “How does our team convert from a waterfall like development model to an agile one using some Lean principles? Can we do this in the context of a non­Lean organization?”

The answer is yes to both, but a team must be cognisant of the difficulties. A paper by the name of “Innovation in Software Development Process by Introducing Toyota Production System” by Takagi, V. K. F. V. T., Sakata, V. A., & Okayama, V. D. (2007) covers one instance of adoption. The paper details the implementation of some Lean philosophy mixed with Agile practices at Fujitsu development in Japan. This transformation to Agile methods uses one of two

Lean Development and Management 12

Lean pillars, continuous improvement, to shape its process. Its useful in that it details the implementation of the change at Fujitsu, and also details of how change’s efficacy was evaluated. They’ve taken steps to measure different facets of the development team before and after the transformation, this way another company can attempt to reproduce their results. While this paper has illustrative power, it’s also important to recognize the issues with this style of implementation. That is, when implementing Lean it’s often important to take into consideration all of the Lean principles. They do not detail the how of theses change and process decisions. If it was company mandated and the employees were told how to ‘best’ implement Lean in their department ­ it would be violating one of the pillars of Lean already, respect for people. They did not detail anything about management or how they make changes to process, which in a truly Lean environment would be primarily left up to the team. However this organization does not have a Lean company structure. So perhaps these shortfalls are the effect of operating out of a larger, non­Lean company ­ and is thus useful to read for any company considering Lean Development within a larger organization. “What are some issues I’ll face attempting to fully implement Lean Software Development in my organization? Will it be worth it?”

There may be lots of issues, but the outcomes can be very worth the trouble. In 2008­2009 Middleton and Joyce wrote the paper, “Lean Software Management ­ BBC Worldwide case study” detailing a transformation to Lean Software Development at BBC Worldwide. This study is especially important as the authors carefully took time to assess their own situation, took time to study Lean Software Development, and thoroughly expound on the results. The authors first studied Lean and its various principles and uses, received feedback from professionals such as Liker, and had the upper management buy in which allowed for real change. It is valuable in that this team worked within a larger organization which was a traditional waterfall organization. The strategic direction and prioritization of features was still chosen by business and project boards.

The team combining elements of Lean with traditional agile. Liker’s (2004) 14 principles were studied and evaluated to determine which could be applied safely in the development team. This was necessary since the team was still under the constraints of a non­Lean organization. They found that within their own context only 7 could be pursued, these were principles 2: Limiting WIP, 3: Pull, 4: Level out process, 5: Stop­the­line culture, 6: Empower people, 7: Visualize, and 8: Autonomation.

They use some agile methods in conjunction with some Lean tools to attempt to improve the quality of their software. They initially implemented test driven development (TDD), automated acceptance testing, source control, and bug tracking. They visualized their workflow through a Kanban board, and also visualized their architecture and project structure always through boards as well. As they got more familiar with the system and became more customer ‘pull’ oriented, they came across the concept of Minimum Marketable Feature (MMF). MMF is a

Lean Development and Management 13

‘nothing extra’ feature that is expected to directly add value to the customer. They ended up using the time to produce an MMF to be the best measurement of effectiveness on the team.

The goal of this study was to see if management could improve the software development process. The data show that delivery lead time was reduced by 47%, time for delivering a software feature was reduced by 37%, and the mean development time was reduced by 73%. Impressively the mean number of days spent blocked was reduced by 81%. Last but not least, reports revealed happier customers.

In the end the team believed that greater value was being delivered. They attributed this to: only high valued work was being processed and developed. They continuously deployed, which allowed faster delivery of value to the customer. By getting the customer to pull features through, they reduced the risk of working on misunderstood or low value tasks.The authors found that the Lean approach can handle ‘big, complex projects’. The difficulty with large projects is infact the human mind and its difficulty in conceptualizing such a project. To combat this they visualized both a ‘master kanban board to show the larger project broken into parts.’

They give a few reasons why this system may not work at some organizations. Some organizations may not welcome, or allow the visual aids of Kanban boards on the walls. An organization that is “Heavy plan process driven” with standardized corporate reporting may not appreciate empowering the team. Because of Lean’s transparency and frequent deliveries, it doesn’t work well with companies that rely on “targets, milestones and gantt charts” (p. 29). Since this form of development requires customer validation, there is a requirement of contacting the customer to get validation which isn’t always an option. Last, its an uncomfortable change for some, in that managers have to move towards a facilitation role. Other employees must also move towards a more empowered role.

“We’re interested in Lean Software Development but what concrete solutions does it give?.”

There has been a study which identified the five most common problems in organizations in regards to achieving success in Lean Product Management. This paper was written by Maglyas et al. (2012), the title is Lean Solutions to Software Product Management Problems. The authors detail the five most common problems they’ve found through interviewing and reviewing documentation on software at 17 companies. Below is my summary of the five most common problems companies faced, and a solution to each.

Problem 1: Their cycle times were too long, many managers didn’t fully know the total process from start to finish. For the companies involved, each department worked in discrete chunks. Each starting only after the previous department was finished, i.e. “throwing the pig over the wall”. The issue with this is that no departments had a knowledge of the whole system or had the whole system in mind when doing their work. The biggest difficulty was departments views of development. Others would view it as a black box where requirements (features) went in as inputs and some incomplete set of features came out. It made the development unpredictable, and so departments didn’t start their own work until they knew what actually came out of

Lean Development and Management 14

development, this usually happened after development was done. A solution would be to use iterations to reduce interruptions and disallow feature request between iterations. Marketing could then know what is certainly coming out the other end of an iteration and get started on its marketing earlier. With continuous integration a company can even know with good confidence that the software will work at the end of the iteration.

Problem 2: Product managers did not keep track of key performance indicators key performance indicators (KPIs), sometimes because management was only concerned that it got through on time and on budget. Also there were no real penalties for failure, so managers were not motivated to track KPIs and felt the responsibility was elsewhere. However, if they would keep metrics based on the whole value stream, such as the rate of accomplishing the company’s goals in numeric form, and the numbers for each team. By tracking only a team’s performance, no one individual is singled out but instead teammates can help each other improve.

Problem 3: Collaboration between organization and customers was an issue. 8 of 13 businesses all small and medium sized did not do in depth analysis of customer needs or wants before developing. To solve this, development could be done based on customer needs only, ‘Pulling’ as its called. It will take fewer resources if customer requests and use is validated before development. Continuous deployment will help get updated products to the customer for more accurate feedback.

Problem 4: Short term thinking, all but one company had roadmaps that were equal to or shorter than one year. One company believed that since they had to adapt so quickly, the roadmap would quickly be invalidated. However, this causes them to lose the ability to target a niche, hire experts that target that niche, and wouldn’t allow protection of key intellectual property. To fix this, they could adopt long term thinking so that you are not only reacting, and sometimes choosing NOT to react, which should help in delivering unique value to the customer, reduce its own costs, and increase efficiency. Driven by internal goals, and metrics rather than competitors!

Problem 5: Trying to change the company instantly, many smaller and medium companies tried to implement product practices all at once, and often they involved a lot of work. This was not present in large organizations as they carefully planned and prepared for each change, since they had already learned how to manage the increased complexity. The other companies could use the concept of perfection for incremental change, i.e. kaizen ­ small simple incremental improvement. This also allows organizations to manage small change slowly.

Research Gaps

There is one large systematic review of gaps in Lean Software research, that paper was written by Pernstål, J., R. Feldt, and T. Gorschek. “The Lean Gap: A Review of Lean Approaches to Large­scale Software Systems Development” found many areas that need to be explored, attributes which the current literature is deficient in, and detail the information the authors would like to see in future Lean research. They carefully quantified 38 Lean Software

Lean Development and Management 15

papers, and their goal was to determine empirical findings found from using Lean within software development. In fact Pernstål et al. have created a comprehensive document on the lacking areas in LPD. Only five out of thirty eight papers had even mediocre rigor, i.e. they scored greater than 1.5 out of 3 (p. 14­15) in rigourousness. This is consistent with the findings of Sjoberg (2012). This study identified that a only a minority of studies were of real industrial cases, and out of all industrial cases only a small subset were systematic in their collection of data before and after the transformation to Lean.

Even fewer studies were identified that address the issues inherent in large scale software development. What they found especially lacking was research that examined how to deal with interdepartmental issues, which they believe are crucial to implementing Lean software development. The author notes “[literature] specifically addressing LPD, are typically referring to studies on TPDS.” (p. 5) They are speaking of the fact that implementing Lean product development isn’t exactly just starting to reduce waste and using a Kanban board, but it also has to do with the format of knowledge creation ­ as mentioned in the section on Lean Product Development. In most studies it would be beneficial to more strictly define what “Lean” they are implementing, that is, which principles, methods, structure exactly that they are using. Ahmad et al. (2013) concluded that not one of the 19 organizations studied could “clearly and deeply demonstrate Kanban method, and how they should be used in a software environment”. This research would be most beneficial if it was performed systematically and rigorously, including carefully measured data from before the transformation and many data points taken throughout the transition. It can also be seen that order effects may come into effect in these studies, since we have no studies where a ‘Lean’ company removes Lean practices and moves towards agile, or less adaptive methods.

In the opinion of the author, an area that is sorely lacking is studies on Lean Product Development in the context of software and otherwise. Few management studies are done, research into the efficacy of adopting a Lean management style would be beneficial. This leads to the necessity to include studies which include a key player who is responsible for the entire end to end project, who takes responsibility for success or failure ­ the Entrepreneurial Systems Designer.

The author further suggests that studies go further than simply changing of teams, but also case studies on Lean transformations of vendors relationships and its efficacy. A need for a model to measure an organization's ‘respect for people’ may be important for determining how an organization is ‘respecting its people’ since this is a central ‘pillar’ of Lean.

Lean Development and Management 16

Appendix A Early Foundations of Toyota

Lean manufacturing was born out of Toyota in the 1900’s but it’s roots were already partially developed in 1785, with Honoré Blanc who demonstrated the use of replaceable parts in muskets. Replaceable parts allowed lay­people to assemble muskets with little training. As luck would have it, Thomas Jefferson saw this demonstration and brought the idea back to the U.S. These roots further developed during the turn of the 20th century century, while Frederick Taylor was asking, ‘what is the best way to perform a task’ and even ‘how can the task be done with the least variability’. Taylorism, as it became known, is now thought to be synonymous with scientific management which uses the analysis and synthesis of workflow to continue to improve its efficiency in management.

Taylorism has some large problems, first and foremost it did not respect people. In ‘Understanding Taylorism’, Littler referred to Taylorism as defined by “the bureaucratization of 3

the structure of control but not of the employment relationship” (p. 1). In other words it rigidly creates levels of control/governance over the individual, but it does not create any levels for that individual to move up through ­ since there was no career structure to an organization. Spender 4

believed that taylorism caused the abuse of people by reducing them to machines.

3 Littler, Craig R. "Understanding Taylorism." The British Journal of Sociology 29.2 (1978): 185. Print.

4 Spender, J.­C, and Hugo Jakob. Kijne. Scientific Management: Frederick Winslow Taylor's Gift to the World? Boston: Kluwer Academic, 1996. Print.

Lean Development and Management 17

Appendix B A summary of Liker’ 13 principles of The Toyota Product Development System: 5

1. Determine what the customer­defined value truly is, this enables your team/company to separate the value from waste

2. Front­load the product design process. This allows you to explore the issues, and benefits of different models truly without ruling out viable alternatives before you’ve generated knowledge on them.

3. Establish a product development process that utilized levelling to maximize the flow (a picture of Mary’s book would be good here).

4. Rigorously standardize to reduce variation, giving a defined space for exploration and creativity. This also enables fewer variables, and thus a better ability to scientifically understand your project outcomes and surprises along the way.

5. Start using a ‘Chief Engineer System’ to integrate development from start to finish. 6. Organize to balance functional expertise and cross­functional integration (more is

involved here than your father’s matrix management). 7. Develop towering technical competence in all engineers. 8. Fully integrate suppliers into the product development system. 9. Build in learning and

continuous improvement. 10. Build a culture to support excellence and relentless improvement. 11. Adapt

technology to fit your people and your processes. 12. Align your organization through simple, visual communication. 13. Use powerful tools for standardization and organizational learning.

5 Editor in chief of Target magazine ­ Robert W. Hall’s book review of ‘The Toyota Product Development System” (Liker 2004)

Lean Development and Management 18

Bibliography

Ahmad, M. O., Markkula, J., & Ovio, M. (2013, September). Kanban in software development:

A systematic literature review. In Software Engineering and Advanced Applications

(SEAA), 2013 39th EUROMICRO Conference on (pp. 9­16). IEEE.

Bloch, M., Blumberg, S., & Laartz, J. (2011). Delivering large­scale IT projects on time, on

budget, and on value. Harvard Business Review.

Bodek, N. (2003, November). Quality Conversation With Gary Convis.

http://www.qualitydigest.com/nov03/articles/05_article.shtml

Humble, J., Read, C., North, D. (2006). The Deployment Production Line. In Proceedings of the

conference on AGILE 2006, 113­118. IEEE Computer Society, Washington, DC, USA.

doi: 10.1109/AGILE.2006.53 http://dx.doi.org/10.1109/AGILE.2006.53

Ikonen, M. (2010). Leadership in Kanban software development projects: A quasi­controlled

experiment. In Lean Enterprise Software and Systems (pp. 85­98). Springer Berlin

Heidelberg.

Kennedy, Michael N. Product Development for the Lean Enterprise: Why Toyota's System Is

Four times More Productive and How You Can Implement It. Richmond, VA: Oaklea,

2003. Print.

Liker, Jeffrey K., and Michael Hoseus. "Human Resource Development in Toyota Culture."

International Journal of Human Resources Development and Management 10.1 (2010):

34. Print.

Liker, J. K. (2004). The Toyota way: 14 management principles from the world's greatest

manufacturer. New York: McGraw­Hill.

Lean Development and Management 19

Marasco, J. (2001, July 1). On Climbing Big Mountains.

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/jul01/OnClim

bingBigMountainsJuly01.pdf

Middleton, P., & Joyce, D. (2012, 12). Lean Software Management: BBC Worldwide Case

Study. IEEE Transactions on Engineering Management, 59(1), 20­32. doi:

10.1109/TEM.2010.2081675

Morgan, James M., and Jeffrey K. Liker. The Toyota Product Development System: Integrating

People, Process, and Technology. New York: Productivity, 2006. Print.

Pernstål, J., Feldt, R., & Gorschek, T. (2013, 12). The Lean gap: A review of Lean approaches to

large­scale software systems development. Journal of Systems and Software, 86(11),

2797­2821. doi: 10.1016/j.jss.2013.06.035

Poppendieck, Mary, and Thomas David. Poppendieck. Implementing Lean Software

Development: From Concept to Cash. Upper Saddle River, NJ: Addison­Wesley, 2007.

Print.

Poppendieck, Mary, and Michael A. Cusumano. "Lean Software Development: A Tutorial."

IEEE Software 29.5 (2012): 26­32. Print.

Poppendieck, Mary, and Thomas David. Poppendieck. Lean Software Development: An Agile

Toolkit. Boston, MA: Addison­Wesley, 2003. Print.

Ries, Eric. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create

Radically Successful Businesses. New York: Crown Business, 2011. Print.

Womack, James P., and Daniel T. Jones. Lean Thinking: Banish Waste and Create Wealth in

Your Corporation. New York, NY: Simon & Schuster, 1996. Print.

Lean Development and Management 20

Womack, James P., Daniel T. Jones, and Daniel Roos. The Machine That Changed the World:

Based on the Massachusetts Institute of Technology 5­million Dollar 5­year Study on the

Future of the Automobile. New York: Rawson Associates, 1990. Print.