AXELOS ProPath, the world's most powerful project, programme and portfolio best practice certifications

10 myths about Lean projects

Adeline Teoh
February 6, 2012

Lean and Agile processes are becoming more popular as project management begins to take on board concepts such as reducing rework, reducing waste and focusing on quality.

Thomsett International presents its Lean Architecture and Agile Feature Implementation course in Melbourne over 16–17 February 2012. Project Manager Online spoke to presenter James Coplien on what makes software architecture Lean and a project Agile.

Can Lean/Agile be used in projects other than software development?

Of course. ‘Lean’ is commonly taken to imply practices inspired by the Toyota Production System and its relatives like Total Productivity Maintenance. These practices were being used in automobile manufacturing long before software gave them formal stature among its practices.

We’ve been interacting with a construction firm here in Denmark that is one of many firms worldwide doing Lean construction: homes, highways, office buildings and the like. These principles are broad, and are commonly and broadly applied in an integrated way.

The term ‘Agile project’ is kind of a strange word that doesn’t strongly classify a development, so it’s a little harder to answer that.

What are some of the common misperceptions about Lean/Agile project management?

1. People feel that Lean and Agile are about project management. Lean is about processes for producing product. Project management is usually focused on time and money management, and usually derives from a fixed budget with an eye to delivering a project in the long term. Good Agile development focuses on small bites of incremental delivery, and Lean focuses on value.

2. People feel that Lean and Agile are about loosening constraints, but for most people they entail a higher level of discipline than holds for other techniques. Time boxing without overtime is a key feature of Agile: it takes guts and discipline to do that. Delivering a Done product in Scrum takes immense discipline even in parts of development that are usually invisible to the business such as refactoring code.

3. People feel that Agile means fast. Sometimes you need to be fast to keep pace with suppliers and the market, but both Agile and Lean are more about synchronisation and rhythm than they are about speed. In the Toyota Way it’s commonly called takt (from the German word taktzeit, which translates to ‘cycle time’).

4. People feel that Agile and Lean give them productivity. Productivity links closely to overproduction, which the Toyota Way views as the number one cause of waste. Productivity is why we have so many unreviewed requirements and such masses of code that are never executed.

5. People feel that Agile and Waterfall are antonyms. In fact, the main problems of Waterfall are that it gathers all requirements up front, and that it tends to organise people in stovepipes. That means people touch a product only for a slice of its development rather than following it cradle to grave. Most people think that the evil of Waterfall is its phases of analysis, design, implementation/test, yet we find these in Scrum.

6. People feel that Agile is about not doing upfront architecture, a concept borne of the XP (extreme programming) idea that “you’re not going to need it”. That’s kind of a naive application of the Toyota ideas of ‘just-in-time’. XP and Agile are much about doing, usually always together with the computer: writing code (in pairs), testing code, interacting with other, getting the software to work, collaborating with customers, and so forth. Doing, doing, doing. There is little thinking in Agile.

The Toyota Way, on the other hand, is all about planning. It’s not about following the plan, but as Dwight D Eisenhower said: “I find that when going into battle, plans are useless. Planning, however, I find to be indispensable.”

7. People often confuse the practices of the Toyota Production System with its essence. The practices include just-in-time, reduced inventory, and minimised waste. The contemporary meaning of Lean corresponds largely to the assembly of these practices. The Toyota Production System, at its heart, is about people and about continuous improvement, commonly called kaizen. Very few Western companies that claim to be doing Lean are doing anything close to The Toyota Way.

8. People think of kaizen as a high-energy exercise analogous to a team that’s on an emotional high, ready to take on the opponent. In fact, kaizen starts with introspection and what the Japanese call hansei: a deep, personal sense of regret for having missed an opportunity to do better.

9. People call Scrum a methodology. In fact, the whole concept of Agile is that no method can work: we have emergence that calls for continuing change. There is no method that can regularly prevail over informed self-organisation in an complex adaptive field like software development. Methods work on simple and complicated problems; software development is complex, a level more difficult than complicated problems.

10. People feel that PMI and Scrum are compatible, or that PRINCE2 and Scrum are compatible, and so forth. I see far too many hand-waving explanations about how to make these combinations work but only at a mechanical level.

However, the underlying worldviews and value systems are radically different in spite of the apparent compatibility at the level of the superficial interfaces. This misunderstanding leads to some of the most disastrous failures for so-called Agile adoptions.

What are some of the clear benefits of using a Lean/Agile approach to project management?
Lean focuses on reducing waste, smoothing out flow along the value stream, and having an integrated view of the process and product. Agile is about self-organisation and feedback. Project management, in the broad sense, neither encourages nor disallows these. Perhaps that implies that Lean and Agile provide more focused and contextualised values, structures, and principles for development than project management does. You certainly would find that if you compared, for example, Scrum with PRINCE2.

For more information, or to register for the course, see Thomsett International > Lean Architecture and Agile Feature Implementation course

Adeline Teoh
Adeline Teoh is the editor and publisher of She has more than a decade of publishing experience in the fields of business and education, and has specialised in writing about project management since 2007.
Read more

One thought on “10 myths about Lean projects

  1. Thanks for this article that teases out some aspects of Lean/Agile. Having worked a long time ago with RAD & JAD & RIPP – arguably precursors to Agile – I have a few insights into the approach of Agile. It was good to have Lean added to this perspective, especially showing that it can work together with Agile.

    I’ve attended a couple of seminars that attempted to explain Agile to PM audiences, but I think I’d have invested my time better by just reading this article!

    It is well written and cohesive, while still quite succinct. A good teaser to the enquiring mind to catalyse the purchase of a book or some other form of further investigation.

    I’d have liked to have seen a brief section where Agile (&/or Lean) might NOT be as relevant, to put a bit more context. And I think that the comment re Waterfall vs Agile as perceived antonymns misses most people’s perceptions that it is the large time frames and the separation from the pervasive deep interactions with the Business Users in Waterfall that defines the frustrations with Waterfall.

    Peter Reefman.

Comments are closed.