As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

• An overview of Kanban
• An overview of Scrum
• Stacking them side by side
• The Power of Index Card Systems and Task Orientation
• Can one reduce or evolve from one to the other?
• Why do we repeat ourselves so often?

• Are your sprints time-boxed to less than 4 weeks?
     Very good teams can vary the length from sprint to sprint but, only do so when the product has a clear and compelling need. Exceeding 4 weeks is just a bad idea for people since our memories are not the good. Your efforts can always be broken down to 4 weeks or less and it is always worth the effort to do so. If it is 5 weeks then to 4 weeks and 1 week or some patter like that but, keep it time boxed and less than a month.
• Have software features been tested and shown to be working at the end of each sprint?
     It is so easy to call something done that is not quite done. Finishing is a challenge. Great teams and excellent products are built by those teams that develop an ability to finish. 
• Are you causing paralysis by over analyzing instead of moving?
     When you find an opportunity to proceed you should move. Great teams avoid analysis paralysis by moving when the opportunity presents itself. Even if nothing is clear movement in any direction will reveal more information about the problem.
• Is there a product owner available to answer questions and prioritize?
     When this position is vacant or absent the team’s movements are erratic and often in the wrong direction. Moral becomes an issue and quality suffers.
• Is a product backlog prioritized by business value?
     Teams will work on what seems important to them first. Even if it is not what the business needs next. No surprises there. Without an engaged product owner the needs fo the product are not championed and efforts are often mis applied.
• Does your team create estimates for items in the sprint backlog?
     Your team should own the estimates in the sprint backlog the product owner should budget for items in the product backlog. Read Dan’s work on estimating vs. budgeting to clarify this concept.
• Does the team express their work so that a burn-down chart can be created?
• Does the team know their velocity?
• Are others like project managers (or anyone else) disrupting the work of the team?

The Nokia test is broken down into two parts. Often we see teams doing the 1st part but, not the second.

Part I: Test for iterative development:

• Iterations must be timeboxed to less than 4 weeks
• Software features must be tested and working at the end of each iteration
• The Iteration must start before specification is complete

Part II: The next part of the test checks whether you are doing Scrum (in Nokia’s opinion):

• You know who the product owner is
• There is a product backlog prioritized by business value
• The product backlog has estimates created by the team
• The team generates burndown charts and knows their velocity
• There are no project managers (or anyone else) disrupting the work of the team

I first heard of this test from Bas Vodde who worked at Nokia to develop this test.