Archive for the ‘Lean’ Category

• Speaking at Orlando Scrum Gathering – Mar 9th 2010

  Date: 2010.02.23 | Category: Conferences, Design Excellence, Lean, Presentations, Product Owner, Pugh Concept Selection, Scrum | Response: 0

  Finally had a few moments to write about my upcoming speaking engagement at the Orlando Scrum Gathering from March 8th to March 10th.  I am VERY excited about the chance to speak at a Scrum conference and I was lucky enough to be selected to provide two presentations in Orlando.

  1. Prioritization with Pugh – this workshop is designed to provide Product Owners a new tool to help evaluate conflicting priorities and focus the discussion on factors that matter to the business by using a Pugh matrix.  Pugh matrices come from the Lean world and are an excellent collaboration tool to resolve conflicts from conflicting stakeholders.
  2. Insights Into Scrum Illuminated by Lean – this Pecha Kucha will focus on how we can learn more about the essential elements of Scrum by looking at the Lean principles embedded natively in Scrum.

• I Really Hate CMMI

  Date: 2009.09.23 | Category: Agile, Lean, Transitions | Response: 0

  I came across a question on a usergroup asking the following (it’s condensed):

  “In our projects we maintain product backlog and do high level estimates in story points. Then when we actually start the iteration we do estimates in the sprint planning meeting in story points and then when the story gets completed we mark the actuals against it. Our understanding of story point is one ideal day (i.e.6 hours). Our estimate for the story include analysis, design, coding and testing. Now the CMMI group is recommending us that we should divide our story into analysis, design, development and testing substasks and track estimated and actual efforts against them. Their argument is that by doing this, there can be some data available which will tell us on how are we doing on each of this area and where we need to improve. For example if the analysis tasks are taking longer then estimated then we should identify reasons and actions to handle it. My argument was that we can not go below the story level because in agile way of working analysis, design, development and testing is kind of merged into a story  and since the story is a smaller piece its not possible to break it further in such a way. I told them that this will be too burocratic and there will be lot of administrative overhead. The CMMI group told me that in their previous implementations they have done it only this way even in organizations where they are using agile methodology (Scrum, XP etc.) and this was the only way they could find to handle this situation.”

  There are so many things wrong here, I will just highlight a few.  Having worked at a CMMI ranked company, from perspective of a contributor most of these rankings are pure bunk.  The CMMI ranking had absolutely no impact on the quality of the system delivered or the timeliness of our delivery.  In both aspects, the CMMI process produced a lower quality, more costly system than an Agile approach.  As applied at this company, CMMI only served to reinforce all the bad habits and waste of waterfall (I really hate the term waterfall since it is SO pejorative.  Just exactly who admits to doing waterfall? – CEN).

  When I hear the phrase “this was the only way they could find”, it just sets off warning bells in my head.  My only advice is to trust your instincts in resisting the mindset from the CMMI auditors. From the short description, it seems to me they are trying to create mini-waterfalls within an Agile process. As for the improvement the CMMI auditors are looking for, they are simply suboptimizing by focusing on tasks – that is such Taylorism.  I am reading an excellent book by Craig Larman and Bas Vodde talking about using Lean thinking to scale Scrum to larger product organizations.  This book provides the intellectual firepower to destroy the last vestiges of the waterfall in modern software development.

  From my experience of CMMI and talking with some auditors, in many instances you only need to show evidence that a practice is occurring in order to pass an audit. There are many legitimate and creative ways to provide evidence your are following the practices described in CMMI. If your instincts are telling you the auditors are wrong, trust them.  Learn what the auditors are looking for and work with them to provide the same information.  Don’t let their intellectual laziness strangle real change and innovation in your organization.

  As a practical matter, you need to placate these CMMI folks because they obviously have the attention of management. I would try to understand what management is looking for with a CMMI rating – beyond the obvious we need a ranking to get more and bigger contracts. What advantages would it give the business? How would you know that the organizational change caused by CMMI is producing the effect your company seeks? Then I would show your management how Scrum is helping in some areas and where it is deficient. In the deficient areas, maybe CMMI can help. Perhaps the CMMI people are right and the processes are unstable. Think about what you could be doing to make the entire system more predictable (hint – think Lean, not CMMI).

• Prioritization with Pugh

  Date: 2009.03.03 | Category: Collaboration, Design Excellence, Design for Six Sigma, Lean, Product Owner, Pugh Concept Selection | Response: 0

  I came across a recent blog entry where Brandon Carlson was discussing one technique he used to speed up the prioritization of Product Backlog items with Product Owners.  He describes the scene like this:

  “It was late July and I was sitting through yet another agonizing prioritization meeting. The sounds of debating product stakeholders filled the air, each weighing in on his or her pet feature’s relative merit, desperately trying to inch it toward the beginning of the development queue.”

  Reading further along in the article, you learn they solved this problem by scoring each feature (on a scale of 0 to 3) how well each feature met twenty-two key attributes from the perspective of both the business and the system.  The features that scored the highest were moved to the top of the prioritization queue and the ones which scored the lowest moved to the bottom.  What broke the logjam for them was having the ability to talk about the features using data and moving away from advocacy.

  What Brandon described is essentially Pugh Concept Selection – a Design for Six Sigma tool.  Bernie Thompson gives an excellent description on his blog of using a more “pure” application of Pugh to select between different cell phone plans.  Pugh was originally used to rank various design alternatives during Analyze, but again the Lean world has yet another mature tool that the Agile community can apply in our lightweight environments.

• It’s Just Lean, No Hyphen Please

  Date: 2009.02.12 | Category: Agile, Design Excellence, Design for Six Sigma, Extreme Programming, Lean | Response: 4

  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?

• If This Wasn’t True…

  Date: 2008.12.29 | Category: Agile, Coaching, Lean | Response: 0

  …it would be funny (Lost the Dilbert strip during the move, sorry – 01/31/2009 CEN).

  In many big companies, the people who are allowed to bring about change are people who have titles like Director, VP, CIO, CMMI auditor, Black Belt – you get the idea.  One of the things that is so exciting about the Agile software development movement is it turns this idea on its head – it asks the people who are doing the work, how they want to change things. The last of the 12 Principles behind the Agile Manifesto, speaks specifically to improvement.

  At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

  This is an application of the Lean concepts of continuous improvement (kaizen) and relentlessly eliminating muda, mura and muri on the short time scales of Agile.  Each iteration, we ask the people participating in the process on how to make things better and then implement the suggestions.  Management (and other outsiders) need to avoid the temptation of telling the teams how to fix things and just genchi genbutsu.  The people doing the work know what needs to be changed, all we need to do is listen to what they have to say.

• Agile is Lean for Software Development

  Date: 2008.12.10 | Category: Agile, Design Excellence, Lean | Response: 0

  I know – not the most profound insight or the most original.  I think I am finally beginning to understand the relationship between the two after studying all this Lean Six Sigma and Design Six Sigma stuff.  Agile is simply a co-evalent instance of the Lean concepts and principles applied to software development.   I don’t think there really is a “Lean software development” – it is just “Lean applied to software development”.

  While I respect the Poppendiecks, and they have been thinking about this WAY longer than I have, I think Lean software development misses the mark.  IMO, they have tried too hard to build the bridge from Lean manufactoring to the software world.  It seems to me that some of the subtleties of Lean are lost with the Poppendiecks’s books, Lean Software Development and Implementing Lean Software Development.

  OK, that is a serious charge to make against some of the most respected thoughtleaders on Lean software development by a guy who has, admittedly, not that much experience with Lean.   Now, it is very likely I am completely misundertanding their writings or what they are saying has evolved from their writings.   What is missing from their writings is much of the innovation the Lean Six Sigma and Design for Six Sigma world has brought to the table.  Alan Shalloway seems to be pushing the Lean envelope further than the Poppendiecks.  I think that he gets there is really no such this as Lean software development, but that it is all just Lean.