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