Archive for February 12th, 2009
-
It’s Just Lean, No Hyphen Please
Alan Shalloway has posted an interesting blog about how Scrum is evolving in its understanding of itself much the same way Extreme Programming (XP) did in the early part of 2000. As someone who was very much into XP at that time, I agree that XP was first defined as the original twelve practices that you always had to follow and then morphed into XP is what you do after doing all the practices – not a very useful definition for people not familiar with the process steps.
However, the more I think about Agile and Lean, the more I become convinced that its ALL Lean and we do not need to rebrand what we do as “Lean-Agile”. As I alluded to earlier, I believe that Agile is an instance of parallel evolution of Lean in the software industry. Either by accident or deliberate thought, the Agile thoughtleaders of the late 1990′s came up with a manifesto for software development that is essentially Lean. Only later when the Poppendiecks showed up (not sure when) is when many more people began to make the connections to Lean.
So what is Agile? How is it related to Lean? Lean is a set of values and principles that are portable across industries. Unfortunately, many of the Lean practices were developed for manufacturing and if we have learned anything from Scrum it is this: software development is NOT a manufacturing activity, but new product development. As a result, many of the original Lean practices are not applicable. Normally, we would be out of luck as practitioners went through trial-and-error to learn what Lean tools worked in software, but we got lucky. We had an independent instance of Lean appear in our industry about 10-15 years ago and we have gone through a lot of trial-and-error to understand what works and what does not.
IMO, Agile is the toolkit you use when you want to do Lean software development. Many of the tools are mature, but there are also many gaps. One that comes to mind is the weak state of product design in the Agile community. Agile’s default position on product design is you iterate on your code until you get something the market wants – I think that might work if you have small products and\or only serving a single market segment. For big organizations, multiyear projects that approach could be exceeding naive. There are Lean tools out there that have gone through the trial-and-error process, so why not use them?
Frequent Topics
Agile Agile SD Certified ScrumMaster Class Design Coaching Collaboration Communication Conferences Daily Scrum Design Excellence Design for Six Sigma Extreme Programming Games Innovation Games Lean Legacy Code Links of the Week Measures Movies Pair Programming Personal Planning PMI Practices Presentations Product Owner Quality Refactoring Retrospectives Rugby Scrum ScrumMaster SIMSOC Spain Team Test-Driven Development Testing Tools Training Transitions Travel Voice of the Customer
Calendar
NetPromoter Score
No progress bars found
Recent Comments
- Kenneth van Rumste on Scrum Roles Defined
- Carlton on Scrum Roles Defined
- Kenneth van Rumste on Scrum Roles Defined
User Groups
Archives
- May 2012 (1)
- April 2012 (2)
- March 2012 (2)
- October 2011 (2)
- August 2011 (1)
- May 2011 (1)
- February 2011 (1)
- January 2011 (5)
- December 2010 (1)
- November 2010 (3)
- October 2010 (6)
- September 2010 (5)
- August 2010 (4)
- July 2010 (6)
- June 2010 (2)
- May 2010 (2)
- April 2010 (5)
- March 2010 (3)
- February 2010 (5)
- January 2010 (7)
- December 2009 (8)
- November 2009 (2)
- October 2009 (6)
- September 2009 (9)
- August 2009 (7)
- July 2009 (4)
- June 2009 (3)
- May 2009 (3)
- April 2009 (5)
- March 2009 (6)
- February 2009 (6)
- January 2009 (7)
- December 2008 (10)
- November 2008 (11)
- October 2008 (10)
- September 2008 (4)
- August 2008 (5)
- July 2008 (5)
- June 2008 (8)
- May 2008 (5)
- April 2008 (3)
