In much the same way Michael Kunze coined the acronym LAMP, I propose the use of a new industry acronym for Agile. Scrum, Lean, Kanban & Kaizen. (SLKK, pronounced slick)  I have successfully used this process which incorporates techniques from all of these areas and felt it needed a name.  I also feel that it will be very useful to many of you that are already using or just beginning to use Agile.

 

Scrum – Describes the artifacts, meetings, backlog and iteration terms, etc. A good intro here. (Hat tip Ken Schwaber and Jeff Sutherland) 

Lean – Describes mechanisms for the elimination of waste, systems thinking and pull concepts. Wikipedia description here. (Hat tip Tom and Mary Poppendieck)

Kanban – Introduces the card wall, reduction of work-in-progress(WIP) and resource workflows.  Personal Kanban also useful. A great description by Kenji Hiranabe here. (Hat tip Taiichi Ohno)

Kaizen – Company and culture. Also speaks to elimination of waste using the scientific method. Using actionable items found in Scrum retrospectives, teams perform “kaizen blitzes” to improve processes and performance. Personal Kaizen also useful. (Hat tip TPS, W. Edwards Deming and Joseph M. Juran)

 

I have read numerous articles and blog posts discussing one technique vs. another and have found it amazing that very few discuss the how they compliment one another. This is what I hope to begin to do in this post.  If you would like to learn more about any of the four pieces, click on some of the links above or books below. First a picture to graphically show my thoughts.

 

Figure 1 – Scrum, Lean, Kanban, Kaizen Relationship

In a nutshell, here is what the process looks like:

1. Initial Backlog prioritized by business value.  Value drawn from market (client) needs.  This is the pull in Lean.
2. Map your value stream.  Make sure you understand how you will measure partially done work, task switching, defects, etc.
3. High level estimates.
4. Build release roadmap based on value and estimates.  Refactor if necessary.
5. Release planning session for release.  Make sure everyone is clear on the vision of the release.
6. Sprint planning session.  Limit Work-in-progress (WIP) as much as possible.  Prioritized by business value.  Make sure work is buffered and balanced. 16 hour SBI’s.  Make sure everyone is clear on the vision of the Sprint.
7. Commitment on Sprint Backlog.
8. If not already done, automated build and test environment setup.
9. Kanban card wall goes up for Sprint.  An electronic version of this on a 60” LCD works well!  :)
10. Daily Scrums review the card wall deltas.  If electronic, task cards added to personal Kanban walls.  If manual, use resource swim lanes.  How have we improved on our Kaizen item?
11. Sprint Review.  Demo new value features. What was the Throughput in dollars? Review PBI’s contained in the next sprint and verify correct priority order.  Sprint Review minutes published via email to all stakeholders.
12. Sprint Retrospective.  What are we doing well?  What could we do better?  Pick and actionable item for improvement during the next Sprint. How will we measure our improvement?  How did we do on our last item?
13. Ready for Release?  If yes, go to #14, if not go back to #6.
14. Software released to production.  Release notes sent to all stakeholders including version number, release CVE, de-scoped features, added features, impediments and any open discussion items.
15. Is the dollar value (revenue potential) for the next release greater than the cost?  If not, the project is ended or put on hold.
16. Does this project have the highest IRR of all the potential projects for this team?  If not, change projects.
17. Begin next release, go to #5.

 

While I hope to go into more detail on this technique in future posts, but for now, here are some great primer books to get you started:

Agile Software Development with Scrum (Series in Agile Software Development)

Agile Estimating and Planning (Robert C. Martin Series)

Lean Software Development: An Agile Toolkit (Agile Software Development Series)

Scrumban - Essays on Kanban Systems for Lean Software Development

Agile Retrospectives: Making Good Teams Great

Kaizen and the Art of Creative Thinking - The Scientific Thinking Mechanism

The Kaizen Pocket Handbook

I read Peter Senge's book The Fifth Discipline a number of years ago and loved it.  I recently reread it and realized it is still as relevant today as it was then. (if not more so).  While the five disciplines discussed in this book are extremely useful when managing teams, the one that always seems to shed some light on tough problems is systems thinking.  Watching for a balancing process with a delay, investment in the wrong part of the organization and fixes that cause problems instead of fixing them are but a few of the tools that have been helpful.  Grounded in Systems Theory, there is tons of really good information on the web on Systems Thinking.  If this is the first time you are hearing about it, I highly recommend doing some reading.

In my last article I established that we have a shot at using PMBOK tools in Agile Management.  Today I want to take a look at how the PMBOK Process Groups map to Agile. As any PMP will tell you the five phases of a project (according to PMI) are:

1. Initiating
2. Planning
3. Executing
4. Controlling
5. Closing

While I will examine each in detail, let’s take a high level look at the above and compare it to one of the more prevalent Agile methodologies, Scrum.

Figure 1 - PMBOK Project Management Process Groups

Figure 2 - Simplified Scrum Process

From Figures 1&2 you the correlation between the PMBOK Process Groups and the steps of Scrum should be obvious.  For clarity, I am defining a project in terms of Scrum as a Release.  Some organizations may choose to define the project as the Sprint itself for the purpose of controlling products or services that don’t have the concept of a Release.

Here is the Process Group alignment matrix for some of the Agile Methodologies:

	Scrum	XP	FDD
Initiating	Release Planning & Product Backlog	Release Planning & User Stories	Develop Overall Model & Build Feature List
Planning	Sprint Planning	Iteration Planning	Plan by Feature
Executing	Sprint	Development	Design & Build by Feature
Controlling	Sprint Backlog & Sprint Burndown	Project Velocity	Milestones
Closing	Release	Release	Release (Build)

So again we see that PMBOK concepts hold up as we examine Agile in more detail.