The Gist of the Story

We believe in Agile software development for teams. From small teams to a 4000 person development group, our clients have enjoyed success with Agile. They have been able to deliver more value to customers at a more sustainable pace and with greater employee satisfaction than ever they were before. That is what keeps us going.

Students in my Kanban training classes ask great questions. Many of these questions come up so often that I have started a list of my "Top 10 (or so) things I wish people knew about Lean-Kanban."

Here is my list and I'd like to know what you think should be added. I will be filling in more information about these over the next few weeks, so keep checking in with me.

What is the rationale for a maximum sprint length of 30 days?

This was a question that someone on the LinkedIn Certified ScrumMasters group recently asked.

There are three reasons. Two are explicitly part of Scrum. The other isn't mentioned but is one of the foundations on which Scrum is based. The explicit ones are feedback and enforced view of reality. The second is removing delays.

In the business of software development, things change rapidly. Computers get faster, development platforms, languages, and paradigms shift year to year, even month to month at times. The shelf life of the average technical book can be measured with an egg-timer (anybody want a copy of the VB4 bible?).

It is seductive to think about scaling Agile up from teams to the enterprise. It seems the correct path to take because you can almost always find a team or two where Agile methods lead to great improvements over Waterfall methods. But what works for a few teams at the local level often obscures the bigger picture: creating enterprise agility. Enterprise agility is the ability for an organization to deliver value quickly when needed. Sadly, I have seen many organizations achieve many successes locally – team agility – and move even further away from enterprise agility.

"If you are in a shipwreck and all the boats are gone, a piano top buoyant enough to keep you afloat that comes along makes a fortuitous life preserver. But this is not to say that the best way to design a life preserver is in the form of a piano top. I think that we are clinging to a great many piano tops in accepting yesterday's fortuitous contrivings as constituting the only means for solving a given problem. Our brains deal exclusively with special-case experiences.  read more »

I saw an interesting blog today by Mike Dwyer called "Scrum is a Silver WHAT and you want to put it WHERE?" where he makes the pithy statement that "Scrum is not a silver bullet – it's a silver mirror." Now I definitely think this is a good blog and recommend you read it. However, I must admit to having had two simultaneous reactions to it – and realized it epitomized my concerns about how Scrum is promoted. My first reaction was – pretty cool.  read more »

Update to this blog 2/3/2012. When I wrote this two years ago, Scrum was pretty much positioned in the manner I have described. However, since then, Net Objectives, and several others, have started promoting Scrum with a Lean mindset.  This has had several names - Scrumban, Scrum# and Lean-Scrum.  Taught this way - Scrum practices within the context of Lean-Thinking - Scrum actually is not like your mother in law anymore, because you understand the underlying principles behind it. Unfortunately, in my experience, it is still not taught this way often enough.

Original blog:

I recently tweeted that I was sometimes irritated that when I've stated something about Scrum that I consider a shortcoming, I usually get called a "Scrum Basher". I would much prefer people engage me on what I have designated as a short-coming of Scrum. If, in fact, my assessment is right, I would be helping those who would be running into a problem. If, in fact, my assessment is wrong, it would be better to engage in a conversation with me to let both myself and others, that my opinion was wrong.

I had an interesting conversation with Masa Maeda of Shojiki Solutions a few days ago. Somewhere in the conversation the observation that a kanban board was a value stream map (VSM) was mentioned. A value stream map shows your workflow as well as the time it takes to do the work. Here is a simple example: