There has been a lot of debate about which is better, Scrum or Kanban.  See The Real Differences between Kanban and Scrum for a start.  While that blog talks more about mindset, one of the biggest differences is the base level of where to start.  Scrum prides itself on being a framework – with very little in it.  The idea offered is that Scrum will help you find your impediments and then it is up to you to solve them.  I have often wondered if either of these parts is true.  First, who says you won't interpret your impediments as "just the way things are" and not do anything about them?  Second, even if you see you have an impediment, knowing that doesn't necessarily give you the ability the fix it (I know an impediment I have in my finances is I buy high and sell low - but knowing this doesn't help me turn it around). 

Lean/Kanban takes a different attitude.  It believes there are certain things you should know right up front. I tend to call these “the laws of the wood.”  By this I mean, that while our skills and creativity matter quite a lot, there are also rules that the work we follow obey.  Just like a carpenter has a lot of skill, the wood she works on obeys certain rules.  Her skill needs to address those rules or she will not be as efficient or effective. 

The following are things that we’ve found virtually all teams will find useful .  As teams find themselves in larger organizations or working with other teams, these things become essential.

Competencies that are Work In Progress Related

Certain delays literally create new work to do (see Eliminate Delays to Avoid Creating Waste).  When work in progress (WIP) exceeds team capacity, these delays go up significantly – thereby causing more of this unnecessary work.  Managing Work in Progress (WIP) can therefore help teams efficiency  Focusing on productivity by keeping people busy actually lower productivity because it tends to have people do too many things.  Little’s Law as it relates to software – given the same amount of resource, he longer your projects are and the more of them you have, the greater your WIP (and therefore delays and therefore the work you have to do).

Miscellaneous

Managing your product portfolio properly can vastly assist your teams.

Value stream mapping can show you things you should know, but possibly don’t know. Most every time I’ve done a value stream mapping exercise

Explicit Policies Speed Learning.  I talk a little bit about this at my Lean Kanban 2009 – Wow! Blog. Also, see Chris Shinkle’s Embracing Kanban that made me realize this.

Use cycle time to help you make decisions.  In complex situations there are many principles and/or practices which appear to conflict.  It’s been my experience that if you make decisions based on reducing cycle time for your standard approach (there are always expedient circumstances which you may have to optimize occasionally) you will be doing well.

Planning poker is often not the best way to do estimation.  See the Team Estimation Game (Appendix A) from our Lean-Agile Software Development: Achieving Enterprise Agility book.

Development Practices

Acceptance test-driven development may greatly improve your team’s efficiency, effectiveness and quality. This is the best trim tab I know of.  See ‘The Role of Quality Assurance in Lean-Agile Software Development” from our Lean-Agile Software Development: Achieving Enterprise Agility book.

The Bottom Line

If you are looking to start a transition to Agile methods, consider what you need to know.  Many people tend to think an empty framework is best - but I think that's an over-reaction to when we put too much in our frameworks. The above concepts are virtually always useful.