The New York Times published an article comparing Yahoo! and Google’s products and their development times. It was an interesting read. In that article, the Ash Patel, Chief Product Officer at Yahoo!, mentioned Scrum as a method used to reduce software development time by managing team size:

Meanwhile, Yahoo says it is now trying to emulate Google’s faster method of creating products. Like most big companies, it used to develop software by first creating a comprehensive design that defined how features would be written and tested. Instead, it is now trying what is known as a scrum method, where it will plan, build and test parts of a product every 30 days.

Several days later, Pete Deemer, Chief Product Officer, Yahoo! Bangalore, made a post to the Scrum Group on Yahoo! and this is what he said:

What the Times doesn’t say is that Yahoo! is now 18 months into its adoption of Scrum, and has upwards of 500 people (and steadily growing) using Scrum in the US, Europe, and India. Scrum is being used successfully for projects ranging from new product development Yahoo! Podcasts, which won a webby 6 months after launch, was built start-to-finish in distributed Scrum between the US and India) to heavy-duty infrastructure work on Yahoo! Mail (which serves north of a hundred million users each month). Most (but not all) of the teams using Scrum at Yahoo! are doing it by the book, with active support from inside and outside coaches (both of which in my opinion are necessary for best results).

Pete Deemer Chief Product Officer, Yahoo! Bangalore / CSM

This is a testament to the Agile Method for developing software. At Amazon, we used a cowboy-scrum version which worked fine. But, I think doing things “by the book” often yields better results, provided that the method is tweaked to fit the company culture etc.

The great thing about creative and knowledge work is that it’s much easier to try new methodologies because of lack of physical inventory. The challenging part, however, is that the inventory that is present is virtual, which makes visual management difficult since there’s no physical inventory.

It’ll be curious to see what methodologies are adopted by the software development community in the upcoming years. What do you think?

The post Scrum at Yahoo! appeared first on 6sigma.

[contentblock id=35]

1. Joe Spooner said, August 21, 2006 @ 1:58 pm What are some of the agile development success stories Mary has seen in government or higher education?

I haven’t done a lot of work with governmental organizations and none with higher education. But I did have one great experience with a defense contractor. The group had a very interesting project going, but every month they had to report to the general in charge how they were doing on something like 63 process measurements. They found this frustrating and so did the general so they wanted to know how to improve their measurements. I asked what does the general really want you to accomplish in the end? Find that out, and then figure out how to constantly test your current capability to do it. Show your progress to the general at the beginning of every report, and you’ll get his attention. Some months later I learned that the team had established a single, high-level performance measure, and then they focused like a laser on making sure that the software improves that measure every month. The general follows the team’s progress with great interest, the team is completely engaged, and the program is considered an outstanding success.

2. Mishkin Berteig said, August 21, 2006 @ 2:25 pm Mary, based on your experience with lean environments and your experience with agile environments, what do you think is the most important improvement or change to be made to the Scrum methodology to make it more lean?

Scrum should not be considered a static methodology, it should follow its own advice (inspect and adapt) and evolve over time. One way to make sure this happens is to keep up with what Scrum’s inventor, Jeff Sutherland, is doing with it today. It is important that Scrum teams focus on the whole product, not just developing software. At Jeff’s company, this is accomplished by defining the end of a sprint as successful live deployment at multiple customers’ production sites. The whole development team is engaged not in making the product owner happy, but in getting all targeted customer sites to go live on time. This means sending out release candidates early and happily accepting and adapting to the surprises they uncover. It makes the customers’ users and support people as much a part of the team as the developers.

According to Jeff, ScrumMasters must be true leaders who help teams self-organize to meet commitments. The team must focus on and adapt to customer needs dynamically, as part of every sprint. Architecture must support incremental development. Disciplined development and deployment practices must be in place. Product managers must have an accurate, up-to-date assessment of what is possible, and may commit only to what can be done within the team’s proven capacity. Finally, senior management and company culture must be fully engaged in supporting this way of working.

3. Jeremy B said, August 21, 2006 @ 2:31 pm What is your favorite experience about agile and lean development to interest people?

Agile development is a good description of how I developed process control software in the early 1980’s. I worked as a junior member of a very experienced and competent engineering team that built new plants and put in processes to make roll-based products such as adhesive tape, magnetic tape, graphics products, anything you could make by spreading some sort of soup on a film. This organization’s job was to build new plants and design and install new equipment every job was completely different than anything that had ever been done before. Computer controls were just coming in at the time, and I was the new kid who knew how to program minicomputers. I learned how to do disciplined, adaptive development as I watched these experts design a new plant and its new equipment and get it in shape to make a completely new product. Although there was no talk about process, the organization could repeatedly and reliably design and install a top-notch new manufacturing line in about a year.

4. TheBizofKnowledge said, August 21, 2006 @ 3:09 pm In your opinion, what is the best way for a company to switch from plan-driven projects to an Agile/Lean approach? Is agile/lean the best environment for all projects, or are there some that might work better if handled in a more traditional way?

I don’t like the term plan-driven’ when it is used as an antonym for Agile, because Agile is as plan-driven’ as any other approach; I would use the term forecast-driven’ instead. Agile is feedback-driven, while non-agile approaches tend to be driven by forecasts of the future. In domains where these forecasts are likely to be accurate, you can assume that the forecast is fact and devise a plan based on that assumption. Just remember when variances occur that they are as likely to be caused by faulty assumptions as faulty execution.

When a forecast is a mere guess, it is far better to use an approach which adapts to the future as it unfolds. In manufacturing feed-back-driven (pull) approaches produce better results than forecast-driven (push) approaches in almost all cases. I would speculate that the same is true of development, although I don’t believe that any single approach can fit all situations.

To return to your first question, the first step in moving from forecast-driven projects to feedback-driven agile/lean methods is to change the measurements. The book Rebirth of American Industry by William Waddell and Norman Bodek makes a good case that the measurements imposed by traditional cost-accounting methods are the biggest impediment to the successful implementation of lean manufacturing. Similarly, I believe that the measurements imposed by traditional project management methods are the biggest impediment to the successful implementation of lean development. In particular, instead of measuring variation from plan, we need to start measuring the delivery of realized business value.

If a company wants to move from a forecast-driven development to a feedback-driven development, it needs to shorten the cycle time from customer request to software delivery, or from concept to cash. The shorter your delivery cycle time, the more responsive you can be to feedback. Queuing theory says that short delivery cycle times depend on having very short queues of work-in-process, so a good approach for switching to agile is to take a hard look at how much partially done work you have in your system.

Start by looking for churn (rework): if you have test-and-fix churn, you are testing too late. If you have requirements churn, you are specifying requirements too soon. Next look at the defect list: test-driven development finds and fixes defects before they need to go on a list. Finally, look queues of work between departments: a cross-functional team can develop an increment of value from idea to deployment without using an inter-departmental list or queue.

5. Carlos Miranda said, August 21, 2006 @ 3:19 pm Which are the differences between your two books on Lean Software Development?

Our first book, Lean Software Development, is aimed at people who do not understand why Agile development is a good approach. It provides the underlying justification for rapid, incremental development. The second book, Implementing Lean Software Development, makes the assumption that the reader has bought-into agile development, and wants to figure out what to do next.

The second book is filled with things we have learned over the last few years: including answers to questions we have often heard and (anonymous) stories of enlightening situations that we have encountered. It delves more deeply into areas we have found to be increasingly important, including:

1. A Focus on the Whole Product 2. Test-driven Development 3. Respect for People

6. Horst Franzke said, August 22, 2006 @ 4:10 am I see teams entering the Lean software arena through a specific set of practices (e.g. XP), which often help them attack their most obvious problems. BUT at the same time I see many teams miss the underlying Principles, which would help them to really grow and improve in the long run. What would be your approach to help such a team with lean practices to adopt the underlying principles? Thanks!

The first thing I would do is ask these questions:

1. Is the team focused on delivering increments of real value to end customers and does everyone understand what that really means? 2. Is the team a Whole Team composed of everyone necessary to deliver value to the ultimate customer? 3. Does the team reliably and repeatedly delivers on its promises?

When you can answer yes’ to these three questions, I’ll bet you won’t feel the team is missing underlying principles. If your answer is no’, then the first order of business is to change it to yes’. But how do you do that? I observe that when teams miss the mark in the areas I just mentioned, there is often a leadership vacuum. Take a look at the team and see if it has both technical and marketing leadership. I believe that teams need a leader who understands and cares deeply about the customers and their problems. They also need a leader who understands and cares deeply about the technical integrity of the product. This leadership may reside in one or two people, or in small teams it may be distributed among several people. But teams which lack market and technical leadership tend to produce mediocre results.

7. Steve Hebert said, August 22, 2006 @ 2:37 pm In addition to the lean tools that programmers use, how do you influence lean processes outside the group (minimizing unchecked code downstream in QA and helping upstream specs arrive at the last responsible moment)? Also, what tools do you see that exist to help manage this type of process (i.e. seeing how many turns features take between development and QA, allowing all team members to triage their own lists, handle gating of large functions (release an item to QA when all needed components have been completed). Thank you

Your question seems to indicate that separate organizations exist to create specs and check code. I would recommend that these responsibilities should not reside in separate departments, but specialists in these areas should be members of a Whole Team everyone necessary to deliver value to the ultimate customer. An increment of customer value should go from specification to delivery in a very short time without spending time in interdepartmental queues. I would not measure turns of features between development and QA there should not be any such thing. In lean manufacturing, the job of QA is to mistake-proof processes so that it is impossible to produce defective material.

In lean software development, the job of QA is to create a test-driven environment that makes defects virtually impossible. Thus QA precedes development, it does not follow it. The idea is to go from feature request to production deployment in a very short cycle time. Jeff Sutherland’s company, PatientKeeper, has three cycle times: They deliver any maintenance fix they choose to implement in a week. They deliver any new feature they choose to implement in a month. They deliver any new application they choose to implement in three months. By deliver’ I mean they go live into production at customer sites customers who are using their software to store medical records. Each year for the last three years, the company has gone live with about 45 releases a year, never missing a deadline. PatientKeeper uses one tool to accomplish this fete it is a tool that lists in detail what remains to be done for every pending release, and how long that work is expected to take. The development team is never loaded beyond its capacity to deliver, and the management team at the highest level of the company adjusts release expectations every week to be sure that teams can meet their deadlines.

8. Vivian said, August 24, 2006 @ 3:11 am I am planning to launch Lean Concepts and Tools for process improvements. I would like to first introduce Lean thinking and Concepts and some time down the line introduce basic tools. My company is a part of the Outsourcing Industry. Could you show me a roadmap that’ll make the launch successful?

There is no roadmap that will guarantee lean success, but we do have a roadmap at the end of our new book that might help get you started in the right direction:

1. Begin where you are: How do you create value and make a profit?

2. Find your biggest constraint: What is the biggest problem limiting your ability to create value and make a profit?

3. Envision your biggest threat: What is the biggest threat to your ability to continue creating value and making a profit over the long term?

4. Evaluate your culture: Establish and reinforce a culture of deep respect for front line workers. Remove barriers that get in the way of pride in workmanship.

5. Train: Train team leads, supervisors and managers how to lead, how to teach, and how to help workers use a disciplined approach to improving work processes.

6. Solve the Biggest Problem: Turn the biggest constraint over to work teams. Expect many quick experiments that will eventually uncover a path to a solution.

7. Remove Accommodations: Uncover the rules that made it possible to live with the constraint. Decide what the new rules should be.

8. Measure: See if end-to-end cycle time, true profitability and real customer satisfaction have improved.

9. Implement: Adopt changes supported by results.

10. Repeat the Cycle: With the biggest problem addressed, something else will become your biggest problem. Find it and repeat the cycle.

9. Jon VanSweden said, August 24, 2006 @ 5:34 am Mary, I am looking to benchmark a company that has applied Hiejunka principles within the office. Have you applied this lean tool in your organization?

An office organization is very different than a development organization, and I focus on lean in development, so I would not be able to recommend a company for you to benchmark. Heijunka in an operating environment means producing at takt time. In a development organization, heijunka means establishing a cadence that keeps development moving forward at an even pace. In software development, the cadence is established through regular, short iterations and regular, closely spaced releases. Just as in bicycling, a steady, relatively fast cadence optimized for your situation is the best way to sustain high performance over the long term.

10. psabilla said, August 25, 2006 @ 4:58 am I’d love to see examples (and/or) suggestions of how to implement the following to software organizations: 1) Kanban, 2) 5S, 3) Visual Workplace, 4) The Big Room (Product Management, Development, QA, etc¦) ” how to best plan and coordinate between all stakeholders, 5) SMED, 6) 5 Why’s, 7) TPM. This is an Epic-sized question, I know, but I think sharing your knowledge will help all of us tremendously. Thanks so much!

An epic-sized question indeed! I’ll do just a brief comment on each one, and then refer you to my most recent book, Implementing Lean Software Development: From Concept to Cash, for more on some of them.

1. Kanban. The Kanban of Software development is the index card. Stories are written on cards, estimated and selected at the iteration planning meeting, posted in the team room, updated when the story is being worked on and when it is done.

2. 5S’s. Apply the 5s’s to the server which stores the code and associated documentation, to desktop environments used by more than one person, and to the code base. We have examples in our new book.

3. Visual Workspace. There are three aspects to a visual workspace the Kanban card (index card) which tells people what needs ot be done, the Andon, or signal that something is wrong (eg. lighting up a red light when the build breaks), and big visible charts which tell everyone how things are going. We also have a section on this in our book.

4. The Big Room, or Obeya. Take a look at the video 21st Century Jet (KTCS, Seattle) and you will see good examples of the Big Room in action during the development of the Boeing 777 in the 1990’s. This isn’t a new idea, but it certainly is a good one.

5. SMED, or Single Minute Set-up. The time it takes to test and deploy a release is the set-up time of software development. Many companies take so long to test software that releases are very far apart, and every effort is made to stuff as much as possible into each big-batch release. Some companies release to production several times a day (anti-virus software comes to mind) they have SMED figured out.

6. 5 Why’s. Root Cause Analysis for any problem is a fundamental skill that all teams need to learn. First we have to implement a Stop-the-Line mentality with test-driven development and continuous integration, so that we find and fix most defects instead of putting them on a rework list. Only then can we start using the 5 Why’s to discover the root cause of the remaining problems that occur.

7. TPM or Total Preventative Maintenance. In software development, we call this refactoring. We keep on improving the design of the code base to keep it healthy and prevent it from calcifying and becoming a jungle that can no longer be maintained. Legacy code is code that has not had regular TPM.

11. Mike Griffiths said, August 25, 2006 @ 2:25 pm When comparing lean manufacturing techniques to software engineering. Some authors map Toyota’s Set Based Concurrent Engineering to practices such as supplying multiple available time-slots options for a meeting, yet the manufacturing process is really based on parallel development and then survival of the fittest solution. This would be akin to having several developers or teams of developers creating the same components and then selecting the best version. Have you seen SW companies follow a parallel development approach and aggressive pruning of less suitable solutions? Also, what guidelines (circumstances, batch sizes, etc) would you give for concurrent engineering in SW project?

The most important time to evaluate multiple solutions is when an irreversible decision that is critical to the success of the system must be made. For example: Which language should we use? Which middleware will we standardize on? Which database will we go with? How do we structure the architecture to support the response time we need? How will we organize the main flow of the user interface? And so on. It is a good strategy to make these tough and critical decisions as late as possible, and I have seen companies develop multiple solutions in all of these areas when the decision was critical to success.

Note that developing options does not mean setting up separate teams to compete; usually it entails creating objects that are a bit more general, and maintaining multiple build-time options. For example, it is fairly easy for a code base to support multiple databases, user interaction strategies, and even middleware, with the selection made at build time. There certainly are critical choices that can’t wait until build time: language, security strategy and the core architectural strategy come to mind. When these types of choices are critical to the success of the system, it can be a good idea to thoroughly explore several approaches by actually developing and testing critical capabilities using each alternative. However, for most parts of the code and in most (but not all) domains, the best way to maintain options is to minimize the number of irreversible decisions that are necessary.

Early releases of software should not preclude future changes. Instead early releases should be as simple as possible and protected with tests, so that the code is easy to change later. The use of change-tolerant coding techniques is the quite often the best way to maintain options in software development this allows exploration of the design space sequentially, as the problem emerges. I find that embedded software and games are domains that are particularly amenable to set-based design, that is, the exploration of multiple solutions during development. This is because these types of software generally do not change once they are released, so the decisions made during development are, basically, irreversible.

12. Deborah Hartmann said, August 27, 2006 @ 8:34 am I’ve heard vaguely, several times, of something that’s beyond Agile and referred to as Lean, though I don’t really know if it is. Called a flow process, it seems to describe a short-cycle-time software production line, in which there is no backlog, or maybe just a short one. I was referred to your book but didn’t find it. I must admit, it sounds like lazy Agile to me – just do whatever comes in, don’t bother setting expectations. Any idea what I’m talking about here, where it comes from? Is this a photocopied too many times version of some valid approach?

Developing Software in a short cycle time from concept to cash is covered in some detail in our new book, Implementing Lean Software Development (release date August 29th, 2006.) Short cycle time development is hardly lazy! It is quite a challenge to be able to fill a request or develop a new feature set just as soon as the need is recognized. Short cycle time expectations are very demanding: for example, when a new virus threat is discovered, a security response team is expected to have software to defeat the threat ready to deploy within hours.

Just about every software development organization I know of has a list of work to do that is far longer than it can hope to accomplish in what customers would consider a reasonable amount of time. And rarely do these organizations have the luxury of turning off the spigot of requests coming in. So the waiting list of stuff to do gets longer and longer, and the development organization looks to be increasingly unresponsive.

Agile development solves this problem by having someone prioritize the list and then having the development team select from the top of the list the amount of work it can reasonably expect to accomplish within an iteration. But look at this practice from the point of view of the people who have their requests lower down on the list. They have no idea when their request might get filled, and in practice, most items lower down on the list will probably never get done. In a lean environment, the idea is to keep the list of work to be done as short as possible, by dealing with requests honestly at the onset and by not accepting work beyond the capacity of the team to deliver.

In the health care industry, some experiments were done with waiting lists at doctor’s offices. One clinic near us used a combination of overtime and limiting new patients to gradually shorten the typical waiting time for a doctor’s appointment from 60 days to 2 days. What they found was that there was no difference in the types of cases the doctors handled on a daily basis except for the fact that patients had only been waiting a day or two, rather than a month or two, to see the doctor. The 60 day waiting lists served no useful purpose at all.

Similarly in software development, long queues of work often serve no useful purpose and worse, they give the wrong message to customers about our intent to deal with their problems. Such lists should be pared down from years worth of work to perhaps a couple iterations worth of work. Agile development gives us visibility into the capacity of a team to deliver, lean development suggests that we do not queue up work beyond that capacity.

The post Book Review: Implementing Lean Software Development appeared first on 6sigma.

Be sure to read our other interviews in our leadership series.

My plan is to collect a series of questions from my readers. A subset of these Mary will graciously answer and I’ll post the entire Q&A here on shmula. I will stop accepting question on August 25, 2006 and I will post the interview on August 28, 2006 [1. Read More Leadership Interviews].

Here are Mary Poppendieck’s other responses to readers’ questions:

• Original Article to Ask Mary Poppendieck Anything
• Mary Poppendieck’s Answers to ALL Readers’ Questions
• Should Lean be Top-down or Bottom-up?
• An Interview with Mary Poppendieck with Pete Abilla
• Mary Poppendieck on the Handoff and Waste

[contentblock id=29]

The post Interview with Mary Poppendieck and Role of Lean Leadership appeared first on 6sigma.

Be sure to read our other interviews in our leadership series.

Here are Mary Poppendieck’s other responses to readers’ questions [1. Read More Leadership Interviews]:

• Original Article to Ask Mary Poppendieck Anything
• Mary Poppendieck’s Answers to ALL Readers’ Questions
• Should Lean be Top-down or Bottom-up?
• An Interview with Mary Poppendieck with Pete Abilla
• Mary Poppendieck on the Handoff and Waste

Mary & Tom, can you please introduce yourselves and tell us what your currently working on.

Mary: My name is Mary Poppendieck and I’m working on the concept of Lean Software Development. I was a programmer for many years and then I went into management, into product development and got out of software development for a while, and then I came back in again after I left the company that I was working with. I was involved as a Project Manager and that’s the first time I ever ran into this idea of “waterfall”. I said to myself: “How can this possibly work?” Then I discovered it actually didn’t work, so I decided to figure out how to apply the concept of Lean, which I’d worked with when I was in manufacturing, to software development.

Tom: I’m a physicist. I’ve been a professor, a high-school teacher; I’ve worked in industry – working on navigation systems for commercial airplanes. I’ve been in small and large, and I’ve spent the last part of my careeer as a software consultant and encountered many of these ideas as they were being introduced in the last decade. Currently we’re working together to spread the ideas of Lean, as they establish a context for Agile software development

Where does Lean come from?

Mary: Lean comes from the Toyota Production System which was invented at Toyota for automotive manufacturing in the late 1940s, 1950s, 1960s. We didn’t actually discover how it was working in the US until perhaps the early 1980s, when the idea of “Just-In-Time” manufacturing started competing against other US products, so we started seeing Toyota and other Japanese cars taking market share away. In my industry, which was 3M, we were making video cassettes and all of a sudden we found that Japanese competitors were selling video cassettes for a third of what we could selling for, and less than we could make them for. We were trying to figure out what caused that. It turns out that this concept of Just-In-Time manufacturing was strongly behind what was going on, and later the concept became known as Lean manufacturing.

What is Lean software development?

Mary: We’ll talk about Lean in general. The Lean history starts over here in manufacturing. Here the first thing Lean was known as was “the Toyota Production System” (it was the way Toyota learned how to manufacture cars). That became known as Just-In-Time and that how it was known when it came to the US and Europe. Then, in 1990 a book was published “The Machine that Changed the World” – the Story of Lean Production. That’s where the word Lean production came from. They’re all basically the same thing. They’re a way of thinking about manufacturing that allows you to do rapid manufacturing with very low inventory and high variability. Then, if we come down this path there’s something in logistics (warehousing, moving materials between companies) called supply chain management (SCM). SCM is the way that you use Lean in the logistics area. And if we come over here there’s a whole other area which I’ll call Product Development, which is very different than manufacturing and logistics. We now apply Lean thinking principles (not the practices, but the principles) from manufacturing and logistics into Product Development. When you apply Lean into Product Development you get a different way of looking at it. And I believe that software development is a subset of, is like, it’s part of Product Development. When you apply Lean to software development you take the general principles of Toyota production system or Lean and you apply them into the Product Development environment but you don’t use the exact practices that you would use in manufacturing. You have to go back to the first principles of what you’re trying to accomplish and move those into software development.

What are the main principles behind Lean?

Mary: The main principles behind Lean were articulated by Taiichi Ohno, the person at Toyota who invented the Toyota Production System. The first principle would be the idea of Flow (or Low Inventory, or Just-in-Time). The second one is what I would have to call “expose problems” or “no workarounds”. The idea is that you have flow and you have low inventory: it’s like you have a boat on the water and your boat is sailing above these big rocks, which are problems. This is your inventory level here. If you lower your inventory level, at some point you’re going to run into a rock rock and your boat is going to come down and bump into this rock. If you don’t get rid of these rocks when you lower your inventory you’re going to bump into rocks, and crash and burn. The first thing you’re doing is lower your inventory to expose those problems so that you can get rid of them. If you don’t expose problems and stop and fix your problems, then lowering your inventory is just going to crash your boat. You have to do two things: you have flow but you also have no tolerance for abnormality. You just don’t allow defects into your system; you don’t allow things to go wrong. When something wrong happens you stop, you figure out what is causing it, you fix it rather than continuing on and just ignoring it or working around it. These are the two basic principles.

What does “inventory” mean in software development?

Mary: In software development inventory is anything that you’ve started and you haven’t gotten done. It’s “partially done” work. In manufacturing if you start making something and it is in-process, it’s not sold, it is inventory. In development it’s the same thing. If you started developing something and it’s not done, it is inventory. What you’re trying to do Lean software development is the least amount of “partially done” work as possible. You want to go from understanding what you’re supposed to do to having it done and deployed and in somebody’s hands as rapidly as possible.

Tom: “Done” means coded, tested, documented, integrated, “Done”, so there’s no more work to do. It is one of the main reasons why Lean approach gives you a more reliable delivery, a more trustworthy delivery. So that instead of finishing activities like requirements, which doesn’t tell you much about how far you are along overall, each piece of work that you do is completely done.

What are some of the other principles of Lean?

Mary: The way I apply Lean into software development, I have seven principles that are the foundation of the way to look at it Lean in software development. The first principle is to eliminate waste. The second is to amplify learning. The third is to delay commitment. The forth is to deliver fast. The fifth is to build integrity into the product. You can’t test it in later; you have to build it with integrity in the first place. The sixth is to engage the intelligence of the people who are doing the work. The last is to optimize the whole system, not just part of it.

What is “waste” in software development?

Mary: Waste is anything that the customers do not value. If you’re doing something and in the end the customers don’t think it is important for them, then it is waste. There are lots of ways to look at waste. One is: partially done work is waste. Just like in manufacturing, inventory is waste; in software development partially done work is waste. Also, extra features you don’t need right now is waste; stuff that causes delays is waste; things that get in the way of a rapid flow of product are waste. Because customers, when they have a problem they want the problem solved now, and stuff that delays that is waste.

What does this look like practice?

Mary: We start by asking people to draw a Value Stream Map. You start with a customer problem-need request, and you go to where that request is filled. So, you put on “customer glasses”, and now I want to watch what happens to that problem until it is back and the customer problem is solved. You draw a map or a timeline of everything that happens from the time the customer request comes in the organization until the customer has their problem solved. You lay out the activities there and how much of the time are you really adding customer value and how much of the time is just sitting there contending with other work that has to happen.

So, one of the things you do to eliminate waste is to say “From customer request to customer delivery, what is my cycle time? How fast do I do that, reliably and repeatably (not: every so often I can do it this fast). What are the steps and how much of that time am I really adding value?” You do that and you find out that, for instance, you develop these requirements… Oh, first of all, it takes forever to approve it, because some how or other you don’t think approving is important, and then you develop this set of requirements, and after a while you discover that you have to change them. So, you go back, you loop back, you’ve done a lot of work that’s isn’t even needed because it gets changed, and then you actually code it.

Well, when you have requirements churn, meaning you’ve done some requirements work and then it needs to be changed, that means you’ve written your requirements too soon. If you don’t wait until it’s time to write those requirements (that’s what I mean by “delayed commitment”) that’s when you’re going to have a lot of changes in requirements. On the other hand say you get to testing and you find errors – oh my goodness! Now you have to go back and code-and-fix, and code-and-fix. If you have that cycle in your value stream you’re testing too late. The idea is to move the detailed requirements closer to the coding, the testing closer to the coding, and do it in smaller chunks.

What it looks like in practice is an iterative cycle that’s 2 to 4 weeks long in which, just before the cycle begins, I take the top priority things that I want and I blow them out into detailed requirements. I write the test first, because the test really helps me understand the requirements, and then I code so that I pass those tests. I make sure that I’m documented, and done and ready to deploy. That means I’ve integrated it into the code base, on a constant basis; if something goes wrong I stop and I fix it, I don’t build up a bunch of defects.

I actually don’t have a defect list, it’s much better to fix the defects, not that you don’t have a couple of those that you decide to ignore, but generally speaking you don’t even have to have a defect list: you need to have a practice that says”When I find something that’s wrong I fix it.” It’s either wrong or it’s right and I don’t have to say “I’m going to have things that I can fix later”. So you write the test, you write the code to pass the test, you integrate every single hour or two into the code base; when something goes wrong you stop. Now this requires automated testing. It also requires a lot of discipline.

When it’s done I have already tested and integrated it. Yes, I do a validation stage but I shouldn’t be finding errors in the validation state. I should generally pass my validation stage and then I can deploy it. Probably automatically, and with something that makes the customers feel safe. This is very much like maintenance programming where maintenance gets the error, and if it’s a serious error in 24 hours they have that thing fixed and patched and back in production. This is what I mean by a rapid cycle.

What does it look like when you have a large team, let’s say 30 developers?

Mary: When you have 30 developers you have three teams and not one, or maybe even four teams. Or maybe you’ve tried to create a divisible architecture so that your architecture allows individual pieces of smaller teams to work on that. Then that’s coordinated by a few people from those teams.

Tom: But even if you’ve broken it down into three teams they all work on the same code based so they’ll continue integrating and synchronising with each other. If it’s a distributed environment you still have one code based one repository. People that live near the repository get faster builds, the ones that are remote get slower builds.
What impact do delays that are outside the development group have and what can you do about that?

Mary: I’d like to stop and say that the development organisation should not be an independent thing. The development organisation is trying to make something that’s bigger than the development organisation. If you’re just developing software you’re actually just developing something that’s probably pretty useless. If the software is not embedded in a business process or in a product it is really not very useful. The first thing to think about is: the development team is part of a bigger team, one that is trying to change a business process or that’s trying to put a product on the market. You need to look at the development team as a piece of that whole team that’s trying to deliver value to the customer. There has to be somebody that is looking over the entire process and making sure that all the different organizations are working together to create that fast value stream. But I admit that every time we find value streams with big pauses and big delays in it, guess what: it’s almost always true that you’re crossing organizational boundaries at that point. Nobody seems to own moving the process forward across the organizational boundaries. So, you need to have an environment in which those organizational boundaries have somebody owning it, making sure there’s coordination across the whole thing you’re trying to do; the whole product or the whole business process, not just the development part. Otherwise you can develop forever and not actually have something that’s an overall business success.

Tom: The bottom line here is that there’s no such thing as technical success; there’s only success – and success means that the business benefit, that ROI that justified this, is realized success – this means that this product sells on the market. Technical success is irrelevant. It might make individual people feel good, but if it doesn’t succeed in the market, in delivering ROI, it’s a failure.

Mary: So one of the things I’m looking for when I say “optimize the whole”, is a team that looks at the whole picture and not just the development portion of it; and a leader that leads the team across the entire value stream, not just the piece of it that’s “development.”

You mentioned one of the principles as “engage intelligence of the workers”. How did you do that? How does that look like?

Mary: It means first of all, understanding that the people that are doing the work are the people most capable of figuring it out how to do it best. So if you have a process, it is not designed by some organisation that you might call ” Process Police,” that figures out how things should be done. You have the people that are doing the work figure out what is the best process to do the work. You don’t pretend that management is the people with most intelligence to figure out how things should be happen.

You create what I would call a visual work space so that when somebody shows up for work in the morning he can look around, see what needs to be done, figure it out and make it happen. Some of the mechanisms to do that is, if you have a team working together and at the beginning of the iteration they decide together what they can do over that iteration, then they take cards and post it on the walls and when they walk in they say “Ok I’m going to do this story,” etc. They can see what is done, they is not done, they meet daily to figure out how they are going to solve the problem and at the end of the two week iteration they have it done. Nobody is tracking each task and telling the team how to do every individual thing; instead the team is being chartered to figure out how to make things happen themselves and how to make things best. When I was a manger we were trained that the most important thing is to make sure the people who are doing the work are the ones that know it best; if you think that you can make decisions for them: guess what, you’ll make more mistakes than they will. You need to structure the work so that it can be done well by the people doing the work and so that they can figure out how to do the best thing. That’s what I mean by engage the intelligence of the workers. The team should be doing the project control, they should be deciding what tasks should be done next; you shouldn’t be having somebody telling them what to do.

Tom: The opposite of that is conformance to somebody else’s plan, to somebody else’s process. It isn’t that there isn’t a process, but the process is owned and evolved and continuously improved by the people using the process, rather than having a process imposed.

This sounds a lot like Scrum. What’s the difference?

Mary: Scrum is a fine example of a Lean environment. Scrum is a set of practices; this is how you do things. Lean would be the principles behind those practices. Lean is the general principles that encourage you to use something like Scrum. Lean would basically say: “You can decide in any given environment how that principle should be applied.” So what it means to have delayed commitment? In one organization it might be different than in another. With delayed commitment, for instance: don’t make decisions until they have to be made. In some Scrums you have a fixed two week window, in some organizations, maybe you really can delay commitment until a week before. Maybe if you’re doing embedded software you have to synchronize how you do things with the hardware team. And so exactly how you do things will depend upon the context in the environment, but the underlying principles apply, and if you apply the principles you will get that Scrum it’s definitely a Lean process, for example. But there are other processes that also could qualify. For example a lot of “open source” development could be conceived as quite Lean, but doesn’t actually conform to a lot of the other principles. There are many example of how Lean can be applied and Scrum is a really good one.

Tom: The difference between Scrum or XP and Lean is that Lean looks over the whole value chain and allows you to understand some of the impact that organisational boundaries have on your efforts, when there are boundaries between testing organizations and deployment organizations, requirement organizations and so forth, and things get handed off from one group to another. There are delays, there’s information lost, there’s lack of feedback, and all these things are exposed when you start with the value stream. They’re not really visible when you measure only a little piece of the process, which software development methodologies alone tend to do.

What popular ideas and processes are directly in conflict with Lean and what is your position on those?

Mary: One of the popular processes that is not exactly in conflict but comes from a different industrial paradigm would be CMM. CMM has this concept of breaking things down into little tiny pieces and measuring every single little tiny piece. That comes from the good old scientific management days, it’s a Taylorist concept where you break things down into little pieces and you optimize every piece rather than the whole. Instead of having hundreds of detail measurements, Lean would focus on a few key high-level measurements, like cycle time. For instance, from the time I get a request to the time I deliver it, if I can rapidly and repeatedly do it in a two week window or a known time frame, I have to have all of the disciplines that CMM wants me to have in place, in order to do that. But I wouldn’t necessarily be measuring every single one; I would know that my overall measurement shows me that I’ve got my process in control.

In manufacturing a mature organization is one that has a fast repeatable cycle time, and the definition of maturity is rapid repeatable cycle time; that covers all the other disciplines that have to be in place. I define maturity as repeatable, short cycle time. Is not that a Lean organization is not capable of receiving CMM certification because most certainly probably would be and because you can’t go fast repeatedly without having the disciplines in place. Instead of dividing things in detailed things and making sure that every individual piece is done, you look at one overall measurement and that drives all of the other things to be in place. I think CMM comes from mass-production paradigm of dividing things into little pieces, whereas Lean comes from the paradigm of having a more overall look at the whole measurement instead of the detailed pieces.

Tom: Cost accounting is aligned with CMM: measure the cost of each little part and add it up. Throughput accounting measures “how much money did you make from your activity?” That’s Lean

What about Rational Unified Process? How does that fit in?

Tom: The rational unified process, like CMM, has a very significant amount of wisdom, that is distilled, systematized and organized. The value of it can be very large as an aid to an organization in learning techniques, as checklists. But the way that is adopted is unfortunately very often a bureaucratic and compliance-driven, rather than a “Lets get the parts of the wisdom , that are applicable to our current context.” It can be very valuable but it is packaged in a way that is difficult to find the parts you need, unless you are an expert. And if you are an expert, you don’t need it anymore.

Mary: There’s a concept that RUP people say: that you configure up and you can only use the pieces of it that are applicable to your area. In practice that does not happen. People don’t do parts of RUP, they do every part of RUP and although that is not necessarily the way it was meant to be, it is definitely the way it is oftentimes implemented. So, you can’t downscope and take the good parts. It seems you have to take everything whether it is truly applicable or not. Once you do that you’re adding a whole lot of waste into your process, stuff that is not really necessary. There’s no focus on “what of this can we not do,” because it’s waste. The same is true with CMM. “What of these pieces do we not need, because we are already there in those places?” or “We don’t need that piece for this context.” It’s sort of like you have to do every little bit and let’s look at the overall thing to see which pieces are going to give us the best result. Which of these pieces is just plain waste, just stuff that doesn’t have value from a customer’s point of view?

Tom: Unified Process is also based on a set of principles which are not totally dissimilar to the Lean principles. But the principles are suppressed and ignored and the focus is on the practices, and the artefacts, and the documents and the processes. If the adoption of the RUP would focus on the RUP principles, as we advocate focusing on the Lean Principles, the likihood of success, leveraging the intelligence of the people rather than encouraging their conformance, is far more likely to be successful. It is not RUP vs. Lean vs. Scrum vs. XP, it is the mindset of the individuals and of the organization that matters; which is why we focus on the principles and how it applies in individual contexts rather than on individual practices or artifacts or anything else.

What is “delayed commitments”, one of the principles you mentioned?

Mary: The idea of delayed commitments is not to decide until you have the most information that you possibly can have. Then you make decisions based on that. It’s the idea that (not that you procrastinate and never make decisions) but that you schedule decisions for when you have the most information. For example, pilots are trained that when they have to make a taught choice, they should decide when they have to decide, and not to decide until then because that’s when they have the most information. The military paradigm: when you’re threatened decide when you need to respond and don’t respond ahead of that, wait until that time because then you have the most information. But don’t wait any longer than that. So, it is the idea of scheduling decisions until the last moment when they need to be made, and not making them before that, because then you have the most information.

For example, let’s take user interface. When do you really need to design a user interface? Oftentimes it drives the whole design, but in fact you don’t really need it until you’re about to do your first alpha test. Before that you can be designing the business layer and you can actually put testing in below the user interface and you can be designing all of the other business logic; you can get that done with any kind of interface and in fact you ca drive testing with a automated interface, and then just before you go to alpha testing you decide what you want for your user interface. Then you take it off and at that point in time you figure it out. But up until that point in time you don’t need that. And there are many pieces of decision in software development, where there’s this idea that we have to design the whole thing before we get started. But the fundamental Lean principle in product development is that we should not make any design decisions until we absolutely have to. We really do not want to have decided anything until we need to; and so at the point it time of the decision we should still have 3 options. Still have a couple of middleware options, or still have not decided how we’re going to do the user interface. You wait until you know the most possible information before you make decisions. So, the idea of having a complete detailed spec at the beginning is the exact opposite of the Lean commitment.

Tom: At the beginning is the time of maximum ignorance about what you really need. It is hardly the time to make your key commitments. Most of the cost is incurred when you make the first commitments. If you can delay that, you can do a much better job.

Mary: You want irreversible decisions, decisions which you can’t change, to be made as late as you possibly can. Otherwise, if you make them early you’re going to lock in the decision, because you’re going to build stuff on it, and you didn’t need to make it yet. And if you wait, you leave options open so that you can chose later exactly what you need to do. That’s just basically a good design heuristic.

Another principle you mentioned is “deliver fast”. Shouldn’t we be slow and more careful?

Mary: Well, I don’t believe, and there’s a lot of evidence to show, that being careful, having high quality, is most certainly is not related to how slow or fast you are. If you take a look at companies that are really good, they also tend to be really fast. Take a look at how fast Dell can deliver a computer. You can’t do that if you’re sloppy. Take a look at how fast Fedex can deliver a package. Only companies that really have their act together and are disciplined technically can be fast.

In Lean the whole idea is that you can have variability with speed and quality. You can’t go fast without having everything together. PatientKeeper, which is Jeff Sutherland’s company, delivers 45 cycles to its competitor’s one cycle. Now, they can’t deliver, they die if they have defect-ridden code. They have to have good stuff. If they don’t have a slick, workable installation process they couldn’t do it. They can take one code base, they don’t have a lot of branches, ant therefore they have mandatory updates for all kinds of their customers, who are hospitals. If they didn’t have software that their hospital trusted, and allowed them to have continuous upgrades, they could not get away with it. So if you’re going to be fast and rapidly respond, you’ll have to be very trustworthy. Just like the maintenance department. Let’s say you have a critical error and your system crashes. Your maintenance programmers go in there, find out the problem, they figure out the fix, they test it and they put it in the patch and you let them do it all the time. That’s because they’re fast and they’re also trustworthy. If you think about software, why is other software any different than fixing up a critical error? You should have all of the same processes in place that a good maintenance department has so that when something goes wrong you can detect it, you can fix it, you can put it in the patch and you can do it where the entire organization has confidence in your capability to do that. Real true speed is actually something that has to come with extremely high quality. So, I really contest the concept that you’ve got to go slow and be excruciatingly careful. What gives you confidence is excellent testing procedures, is automated testing, is stuff that’s disjoint from each other so that as you add features you don’t add complexity. It’s simple code and very disciplined procedures but not go slow. In fact is have your automation there, so that you can go fast. Then you can have higher quality than “let’s be slow and careful”.

This sounds nice but is it realistic in large organizations with a lot of boundaries between departments?

Mary: We get people saying a lot: “I can’t do that in my company”. It is very true that the organizational boundaries are where this falls apart so we’ll give a class in Lean and people come back and say “I can do it until I run into testing, but the testing department does not want to have anything to do with it” or the people in requirements, or our customers don’t want to think about things differently. As you get up to boundaries you really have some problems.

But organizations that are in a deeply competitive environment tend to figure this out pretty fast. Because, if you get a single competitor out there that can do this, they can probably knock your socks off real fast. So, for instance, PatientKeeper puts out 45 cycles to its competitors’ one, and all of a sudden your competitor can flood the market with really good, high quality, constant improvements and you can’t – you’re in trouble. What we find is that the organizations that figure out how to do this are the ones that have threatening competition and they have to be able to do something that is really new, novel, different and highly competitive. If you don’t have a lot of competition and you can keep going the way that you’re going and you don’t have to think about how your organization is structured, you might actually not be able to do Lean in your organization. But when you got into competitive companies where you have got to be creative and you have to figure out how to hit the market better than your competitors, this becomes a very nice competitive advantage. And, the companies that we see using this are the companies actually forced to think really hard about how they can have some leverage their competitors can’t have.

Tom: We’re seeing both very large and very small companies using these ideas. This kind of thinking is largely responsible for the success of Dell, Wal-Mart and other small companies like that.

What do you do when you can’t get Lean into your organization? What’s one approach?

Mary: If you run up against an organizational boundary that you can’t do, then Lean is not coming into that company at a high-enough level. Very often it is said that you really have to have Lean as a corporate philosophy, that’s in the blood of the whole management structure, otherwise it tends to have problems. So, you really have to think about this as being a fairly high-level corporate philosophy or culture, before it can actually work across the various organizational boundaries you might run into. Not all companies want to switch their culture that way.

On the other hand, there are a lot of Lean initiatives happening in our world these days, in other areas, not software. You’ll find it in operations, in retail operations, in warehouses, in manufacturing and in business processes – Lean has become an initiative that various companies have. One day that finds its way into the software development environment, and when it does at least you have a management structure that is beginning to understand what Lean means. And if you translate it correctly into software development, you probably can get some serious management support for Lean initiatives, also in software.

How do you do Lean under contract?

Mary: Ah, well that’s really a problem. All of the Agile techniques run into trouble when the organizational boundary that you’re crossing is into another company. Because, when two companies start working together they tend to need to have a contract between them. And the contract usually has to spell out exactly what were doing, and exactly how much it is going to cost; most contracts then create a game between the companies, where you have predefinition of everything, and you have to check it all off later. If you have a contract like that it is very difficult to have a Lean environment, or any kind of Agile environment.

But there are now some contracts that are being formulated that recognize that Agile gives you better results. For example, Norway has a PS2000 contract, it was written by the Norwegian computer society, and it is a standard contract for a large public service, public IT contracts, and it is specifically written to encourage Lean, or Agile, software development. It defines how the parties are going to interact together with the assumption that the parties are going to figure out on an outgoing basis what it is that they really want to do. And it creates a contracting environment that allows people to “inspect and adapt” as time goes on, and have feedback in the entire development process. But most contracts don’t do that, and a contract that doesn’t allow feedback, change, that requires everything to be predefined is going to make it very difficult to do any kind of Agile process at all.

For more on Lean for Software, please visit this interview I had with Mary in August 2006.  The source for the content above can be found here.

[contentblock id=29]

The post Lean for Software: Interview with Mary Poppendieck appeared first on 6sigma.

Amazon is a company that is absolutely customer obsessed — from the top-down.  It’s been able to build a culture with the customer at the center, because its processes, technology, and the general worldview of its employees are centered right on the customer.

The Amazon.com Core Values

The Amazon Core Values, for example, are not just a list of rote phrases the people forget after they are tacked-up on the wall: they are hard-core in every Amazonian.  Specifically, the Amazon Core Values are:

• Customer Obsession: We start with the customer and work backwards.
• Innovation: If you don’t listen to your customers you will fail. But if you only listen to your customers you will also fail.
• Bias for Action: We live in a time of unheralded revolution and insurmountable opportunity provided we make every minute count.
• Ownership: Ownership matters when you’re building a great company. Owners think long-term, plead passionately for their projects and ideas, and are empowered to respectfully challenge decisions.
• High Hiring Bar: When making a hiring decision we ask ourselves: Will I admire this person? Will I learn from this person? Is this person a superstar?
• Frugality: We spend money on things that really matter and believe that frugality breeds resourcefulness, self-sufficiency, and invention!

How do the core values weave their way into how people work at Amazon?  One example is Ownership.  Ownership is manifested in the way Amazon compensates its people.  Restricted Stock Units (RSU) are a big part of the annual bonus and merit increases.  And, because of the strong services and store-focused nature of the Amazon business, each store that is launched has a business owner, or general manager who owns the P&L for that store — so, that entire team has P&L responsibility with their compensation tied to the P&L — indeed, true ownership is manifested when your livelihood depends on the success of your project or initiative or, in Amazon’s case, the store.

Amazon.com Product Development Process

Here’s another example: the product development process at Amazon is centered on the customer.  Amazon follows a process called “Working Backwards”, which means that the first deliverables created are the documents at  launch, then work backwards towards the items closer to the implementation.  Defining a product this way adds clarity and simplicity — you know at the front-end what the customer can expect, and working backwards allows the team to build it.  Here are the general steps followed in this process:

1. Start by writing the Press Release.  Nail it. The press release describes in a simple way what the product does and why it exists – what are the features and benefits. It needs to be very clear and to the point. Writing a press release up front clarifies how the world will see the product – not just how we think about it internally.
2. Write a Frequently Asked Questions document. Here’s where we add meat to the skeleton provided by the press release. It includes questions that came up when we wrote the press release. You would include questions that other folks asked when you shared the press release and you include questions that define what the product is good for. You put yourself in the shoes of someone using the product and consider all the questions you would have.
3. Define the customer experience. Describe in precise detail the customer experience for the different things a customer might do with the product. For products with a user interface, we would build mock ups of each screen that the customer uses. For web services, we write use cases, including code snippets, which describe ways you can imagine people using the product. The goal here is to tell stories of how a customer is solving their problems using the product.

1. Write the User Manual. The user manual is what a customer will use to really find out about what the product is and how they will use it. The user manual typically has three sections, concepts, how-to, and reference, which between them tell the customer everything they need to know to use the product. For products with more than one kind of user, we write more than one user manual.

Following this process reduced so much “front-end” time — that is, the cycle time from concept-to-delivery (brainstorming, discussions, and arguments) was significantly reduced because the team and peripheral stakeholders agreed earlier rather than later on what the product would look like in the end.  Moreover, because of the bias-for-action core value, people naturally want to produce, rather than have long, drawn-out discussions: at the end, people want working code, manifested in a store that is launched and adding value to the top-line.

This process places the customer at the center, and drives simplicity and clarity throughout the process.  Start with the customer, and work backwards — is a very effective process that works well and places the customer in her rightful place.

The post Start with the Customer, and Work Backwards appeared first on 6sigma.

Be sure to read our other interviews in our leadership series.

Here are Mary Poppendieck’s other responses to readers’ questions:

• Original Article to Ask Mary Poppendieck Anything
• Mary Poppendieck’s Answers to ALL Readers’ Questions
• Should Lean be Top-down or Bottom-up?
• An Interview with Mary Poppendieck with Pete Abilla
• Mary Poppendieck on the Handoff and Waste

Earlier, Mary and Tom responded to the question of Waste and the Handoff in software development.  Today, they respond to two questions from Ursula Rutherford:

Ursula Rutherford said,

November 16, 2007 @ 3:55 am

The term Lean is very little known in the software development and system delivery industries. Do you expect there to be more explicit use of it in the future?

It seems IS people are treading their own path towards quality management and capability maturity without reference to other industries. Perhaps if Lean were a more well-known term in IS, we could benefit from several decades of experience and from training in lean principles.

MBP >>

I have to agree, there is a lot to be learned from good old low-tech industries.  What will drive improvement into software development is competition – in highly competitive industries, there is no alternative but to find the approach that has the least waste, lowest cost, and highest quality.  As software becomes more and more pervasive, those who develop systems wisely will end up at the top of the competitive hill.

TDP >>

Lean looks at the whole value stream from concept to cash or order to payment.  It delivers more value by avoiding sub-optimizing choices and handoffs.

About 1/2 hour later, Ursula poses another question to Mary and Tom Poppendieck:

Ursula Rutherford said,

November 16, 2007 @ 4:22 am

Making a broad generalization, it seems lean initiatives in many industries need top-management support to have a chance of success. In contrast, there are many accounts of agile   programming techniques being adopted at team level with good results.

At what level of organizations do you recommend lean software development be introduced?

Imagine an organization with high-level sponsorship and a generous budget to make software development lean¦ Should change begin with education or practice; in the development team or the boardroom; slow or fast; a pilot project or for real’; imposed by decree or encouraged by incentives?

MBP >>

Where to start is very dependent on the context and on the location of the biggest constraint.  If the biggest constraint is a huge end-of-cycle test and merge bottleneck, then you can make huge strides by getting stop-the-line testing disciplines in place.  This involves integration of testing with development, but that might be possible at a rather low level.

On the other hand, if the biggest constraint is caused by thrashing because more work is being dumped on the development organization than it can hope to handle, then higher level of management involvement is usually necessary to make a big difference.   If the approval process is insisting that a host of low priority features be developed, you have yet another problem that needs to be addressed from the perspective of a broader organization.

I generally recommend that you do a rough value stream map in order to find the biggest constraint in your system.  Actually, people probably already know what the biggest constraint is, but are reluctant to confront it, and a value stream map might just help to put difficult issues on the table for discussion.  Once you have found and are ready to confront the biggest constraint in your development process, then you don’t need a value stream map for a while, instead you need a top notch, team-based process improvement process that addresses and gradually removes the key constraint.  Since the constraint generally occurs at organizational boundaries, it usually helps to have senior management involvement at this point.

TDP >>

At its heart, Lean is a management philosophy based on deep respect for people and relentless elimination of waste from the delivery of value to customers to return sustainable prosperity for the organization.  Sustainable deployment of Lean (or Agile) must reach high enough in an organization to control the entire value stream and to control how people are treated.  In some cases, this may only extend to departmental or divisional level management, in other cases, it may need to extend beyond organizational boundaries to an entire supply chain.  How people are measured and rewarded determines how they will behave in the long run.

[contentblock id=29]

The post Lean for Software Transformation: Top Down or Bottom Up appeared first on 6sigma.