The Nordstrom Innovation Lab

At the Nordstrom Innovation Lab, a new team is applying agile and lean startup techniques to move quickly from conception to deployment. The team is acting like a startup within a large organization. They work in a collaborative open workspace and go through several iterations using frequent customer feedback loops to plan out their next iteration. They keep their planning simple and light-weight by using sticky notes and index cards and following agile engineering practices like pairing and test-driven development. Watch this team in action below.

 

http://nordstrominnovationlab.com/

The Tyranny of the Plan

Mary Poppendieck gave a talk on lean software development at the UK Lean Conference. Mary started out by describing the process of building the empire state building. The building was exactly on time and 18% under budget:

· 9/22/29 – demolition started

· 1/22/30 – excavation started

· 3/17/30 – construction started

· 11/13/30 – exterior completed

· 5/1/31 – building opened

Mary next explained how they managed to do that before there were computers, GANTT charts and PERT charts. The builder focused on workflow. They did not need to figure out the details and lay out a plan. There was no design when contract signed. They used deep experienced on a fixed priced contract. They focused on key constraint which wasn’t labor, steel or stone. It was material flow of needing the right stuff at the right time (500 trucks a day delivering materials, no storage on site). The building was designed to be decoupled. There were 4 pacemakers which were independently scheduled workflows. They avoided having cascading delays. They understood that it pays to invest money to save time (cash flow thinking). Every day of delay cost 10K (about 120K today). Schedule was not laid out based on the details of the building design. They created the schedule and created the design to fit the schedule. The building was designed based on the constraints of the situation (2 acres, zoning ordinances, 35M capital, laws of physics, and May 1, 1931 deadline). Traditionally we start by figuring out what you are going to do, break it down into pieces (WBS), sum up the total and there is your schedule. Instead here they started with the constraints and created a schedule that can fit within the constraints.

Mary summarized the lessons learned. Design the system to meet the constraints; do not derive constraints from the design (budget, time). Decouple workflows; break dependencies from architectural point of view and scheduling point of view instead of organizing them on a schedule (PERT chart). Workflows are easier to control and more predictable than a schedule. For control and predictability establish a reliable workflow instead of establishing a schedule that needs to be followed.

Next Mary explains that there are 2 reasons that we schedule. The 1st is to control when things will happen. However, detailed schedules are deterministic and do not allow for normal (common cause variation). Machines break down, weather, no way to deal with variations unless we add slack. Attempting to remove common cause variation from a system will cause it to oscillate wildly. Flow systems on the other hand build in slack whenever they need it. Managing a level workflow is a lot easier than following a deterministic schedule.

Lean Concepts for IT Professionals

At ThoughtWorks conference, Richard Durnall and Kraig Parkinson gave a talk about Lean Software development. They start out by giving a brief history on Lean and how it led to the Toyota Production System (TPS). They then describe Lean in detail and cover the 4 levels of concern as

1. Philosophy - long term thinking or challenge. How are we going to accomplish these goals given the constraints: Long term vision(looking at 5, 10, 20 years), adaptive planning as we learn more and are faced with new challenges, process based company with human focus.

2. Process - steps to take to get there: Pull systems (wait for order before starting), eliminate waste, value streams, Jidoka automation (providing humans with tools to support what they do), Heijunka (even out the work to make a balanced system), visual controls (see where the work is), stop the line (at Toyota the line stops about 27,000 times a day), build in quality.

Eliminate waste (overproduction, waiting, unnecessary transportation, over processing, excess inventory, unnecessary movement of our people, defects, unused employee creativity)

3. People and partners - Respect and work together towards the ultimate goal. Supplier and partner relations (share resources to make suppliers and partners better since they share the same ecosystem), encourage the right behaviors (point everyone in the same org in the same direction), training and personal growth.

4. Problem solving - in depth look at the real issues. Genchi Genbusu (go, see and do for yourself, get involved), 5 why’s (root cause analysis tool – ask why 5 times and at the 5th time you know the root cause), 5s (stabilize and standardize what we do as a platform for continuous improvements going forward), ishikawa (fishbone diagram for root cause analysis tool), A3 reports (get all information you can on one side of A3 paper – annual financial statement – intent that less is more), PDCA (plan, do check, act cycle).

Wrapping all this together is a sense of continuous improvement (Kaizen).

Next, they look at Lean in IT:

1. IT has a problem - mediocrity: over budget, over schedule, not delivering useful features, projects failing.

2. IT is a business process and we can use Lean techniques to improve them like value stream map to measure cycle time efficiency. The process involves walking through the process and tracking 3 metrics: value added time (amount of time to do something of value that the customer will appreciate), elapsed time (from start to finish including waiting time), and cumulative elapsed time (over all time from request until delivery). This shows IT waste like extra features, waiting, unnecessary transportation, gold plating, partially completed work, unnecessary movement, defects, and unused employee creativity. One can apply Lean practices like pull practice, eliminate waste, and adaptive planning to improve the cycle. We do not need to fix everything. We need to work on our immediate constraint and once that is fixed we can move on to the next one.

3. Further engage business and deliver better results: IT works across business units and can see the process from end to end. Focus on customer. Realign key management metrics to be more of a throughput focused vs. status focused - what is the profitability, how smooth is the process.

4. Look at other lean organizations and learn from them. Start with the customer, focus on quality not cost (and cost will drop as quality improves), find the change agents and empower them, don’t get trapped in the tool age (concentrate on philosophy, beliefs and values), and remember that anyone can introduce change.

This presentation is available on InfoQ at http://www.infoq.com/presentations/durnall-parkinson-thoughtworks-lean-it

The Development of a New Car at Toyota

Kenji Hiranabe gave a presentation at Agile 2008 about Lean at Toyota. He talks about Nobuaki Katayama, former Chief Engineer at Toyota, and how they build new cars. There are 3 phases to car building:

1. Planning and concept development: concept, style, market research, pre-development, cost and profit target. Spend a lot of time in this phase. Start out with a good concept, then visit dealers and users and get feedback to see if this concept work and then redo. The next 2 phases are management of milestones.

2. Real car development: Design prototyping, evaluation

3. Production and sales:

Managing big projects:

1. Planning and concept management: project backbone, clear appealing points are needed, 1st concept and plan has to be refined until satisfaction, discuss multiple opinions from wide views, rules to avoid immature “go”, calm evaluation with 3rd person

2. Development process management: needs to be a strong dedicated leader with org that supports him, with clear milestones, and supporting people to achieve them, rules to avoid proceeding before achieving them, mechanics to avoid “too late”, trigger of 3rd person, honest communication (face to face), bad news 1st rule, early and reliable backup plan.

3. Resource management: people and money, work hard does not work, visualization estimate based on actual record, make projects slim. Cost: Visualize the target cost, leader owns buffer, assign target cost based on actual record, value sense of completion, avoid sense of being “forced to do”, plan in detail and follow up and adjust seeing the whole

4. Cost management: Reduce cost means save profit so that the company can grow, everyone and every division think about global competition and cost reduction. Culture of do not complain but cooperate. Analyze past and present cost. Use it as base cost data. Reduction of cost is accumulated step by step by everybody. Value engineering is the technical competence. Each team is responsible for reducing cost.

5. Benchmarking: it’s about knowing competitors strategy. Not copy others techniques, but focus of parts that are better than ours. Set performance targets including ahead and behind time difference. Study designs of 2 to 3 years ago and develop product 1 to 2 years away. Use it for continuous competiveness.

6. Leader attitude: Leadership, teamwork, macroview, passion are good. Dictator, one man shop, leave all to subordinates, charismatic are bad for leadership.


Kenji then contrasts “do it until it’s done” vs. “do it until the time”. Mr. Katayama explained that for phase 1 use do it until it is done and for phases 2 and 3, do it until time.

Kenji wraps up by mentioning the Nobuaki Katayama values consistency and integrity over passion and strong leadership, values engineering thinking, and tries to understand new ideas.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Toyota-Kenji-Hiranabe

Agile Styles: Lean

Mary Poppendieck covers Lean Software Development at Agile 2006. She mentions that Lean came into being in 1990 based on book ‘The Machine that Changed the World’. The book compares and shows the advantages of Japanese auto manufacturing vs. USA manufacturing. Most of the Lean practices trace their history back to Toyota. Originally it used to be Just In Time (JIT) and then later it became Lean. It’s used it manufacturing, operations and supply chain. We can’t apply it directly to software development, but we can use the Lean principles and look closed at Lean practices in product development. These principles end up deriving the agile practices.

Next Mary discusses some fundamental principles of Lean. She starts with eliminating waste. The trick here is to decide what waste it. She states that it is the customer’s view of waste that matters. MUDA is Japanese for waste or anything that does not add customer value.

Then Mary mentions that Testing is not for finding defects. In lean the job of testing is to prevent defects. If you have a quality process, you are building quality into the code. If you routinely have test and fix cycles, it means you are testing too late. Your process is defective. Final verification should be used to verify that something is working as expected and not for debugging. Defects are a management problem. We should look at defects as caused by a system which allows defects instead of just caused by developers.


A fundamental principle of Lean is to respect people. Toyota’s success was based on their ability to harness intellect of ordinary employees.

Lean looks at the whole picture. Software by itself is useless. It needs to be embedded in a business process, hardware, or an activity to become useful. The goal of software development is to support the development of a complete product (a process that helps customers get job done). The team should include business people not just developers.

Next Mary covers the process of iterative development. She also mentions that if churn or requirement change is as high then you are writing requirements too soon. You should move requirements gathering later into the process.

Lean has quality built in by having:
1. Standards: Architecture, Conventions, Tools. These should constantly be challenged and changed.
2. Continuous improvement: Improve the process, refactor the code.
3. Synchronization: Merge early and merge often. Configuration management, automated build, one click build, continuous integration, nested synchronizations, stop and fix if something is wrong
4. Frequent deployment. Small releases, automated deployment, automated installation.