We don't have a problem ... IS a problem

"Do you have a problem?" – "No, we don't have any problems around here" - "Oh, that is a problem"

What? – I have to admit, that this conversation might need some explanation.

The dialogue above depicts a typical situation that arises when groups first start to introduce continuous improvement. In our culture, problems are so tightly connected to bad things that we tend to either block them out or try to solve them as quickly as possible - even if the latter means circumventing the problem in the first place... instead of really going to the root cause of the problem and in fact solving it.

But as Jerry Weinberg once stated "Once you eliminate your number one problem, number two gets a promotion." (The Secrets of Consulting, page 15) – so the real question is "Are you aware of your current number one problem?"

To achieve continuous improvement, it is important to be aware of your problems - and to keep in mind, that under changing circumstances, yesterdays solutions tend to become todays problems – which makes it even more important to take a close look for and at each and every problem with a fresh and open mind as unbiased as possible.

Cover all the Angles

What gave planning such a bad name?
"In 'Agile' we don't do estimates!"
"We do not plan ahead - we just do what is necessary at that Moment in Time"
"We don't know what we will find out, so let's not try to plan the un-plan-able"
Guys seriously... Of course the kind of planning that emerged in the 70s, 80s and 90s of the last century, where people try to plan what other people do a year in advance down to a very detailed level does not make sense - but does that really mean that we shouldn't plan anymore?
After all, the ability to plan ahead is what made it possible to evolve from hunter-gatherers to settlers. And this planning did not include assigning "Caveman A" to sharpen the sickle on February the 20th and "Caveman B" to have a delivery relationship on his task to "fetch some sharpening stones, suitable for stone age sickles" with an end-date "not later than February 19th". But the planning still included all those things that could be addressed - plus contingencies. In a reasonable manner. With all members of the relevant community being responsible for their respective contribution.

But somehow planning really got a bad name, when responsibilities got piled up on the shoulders of "the planner" and instead of covering all the sensible angles for the problem at hand, "the planners" started to cover all the angles of attack to their backs.

And instead of planning for things that can be planned, it became more important to produce plans that seem airtight so that the poor guy who wrote it can avoid being attacked.

But don't misunderstand planning in 'Agile' or lean - it's not "no planning" it is way more planning - it is just not done by someone from outside in advance, but occurs more often and is done by the people who are best suited to make the decisions.

On a sailing boat you don't necessarily plan for the exact wind that you find on the day of the regatta, but if the race is well planned you do have the right sails on board to enable the highly trained and specialized (!) crew-members to make the best of the situation. Each and everyone responsible all by himself!

Fortunately, the lean approach brings us some of the planning back. So now the topic of planning no longer is as much of a taboo as it used to be for a while.

One place to experience some of the methods and approaches for lean planning is the hands-on workshop on agile and lean practices Tom Breur and I plan to run in the autumn of 2013

I hear and I forget; I see and I remember; I do and I understand.

Benjamin Franklin... Benjamin Franklin? Or was it Confucius? He supposedly said:

Tell me and I forget, show me and I [might] remember, involve me and I understand.

Or was it actually Xun Zi (also written as 'Hsün Tzu', but not to be confused with Sun Tzu of "The Art of War" fame), the confucian philosopher who said:

"Not hearing is not as good as hearing, hearing is not as good as seeing, seeing is not as good as mentally knowing, mentally knowing is not as good as acting; true learning continues up to the point that action comes forth"

Wether you'd like to rely on the Wikiquote rendition of the saying or not, modern behavioral science shows us that there is actually quite a big measurable difference between learning by hearing and learning by doing.
That fits well with the recommendation that can be found in 'The Toyota Way':

"Start with action in the technical systems; follow quickly with cultural change [...] Learn by doing first and training second."

Quoted from the first two 'general tips' for organizations on a transition towards lean (emphasis added)

And perhaps this also is the reason why simulations (or games if you're not too heavy on political correctness) are such an important part of 'Agile' and lean trainings.
The only thing I am still missing in most of these simulations (except for the getkanban game) is the usage of the real techniques. That is one of the reasons Tom Breur and I created the Lean and Agile hands-on training with a strong focus on all the management methods, applied in some well known simulations.

Lean is not Agile, is it?

We live in a time where project management Methods exist in abundance and traditional methods compete with Agile (with a capital A) and lean approaches which in turn compete with each other.
But do they? First of all methods hardly ever compete - it's people who do the competing. The approaches just exist and either oppose each other, complement each other or have no relationship whatsoever. The Agile movement mostly was a counter-movement against the overly structured approaches to software development that came to live in the 1980s and basically this movement re-instantiated good practices from the 1950s and 1960s as for example Craig Larman points out in his article Iterative and Incremental Development: A Brief History.
The whole lean approach in turn surfaced as the Agile movement was taken over by the same people who enforced the rigorous methods of the 1980s and more and more problems in the value chain, but outside the core development efforts, became visible. David Anderson – one of the fathers of Software Kanban – calls Kanban (which is related to lean software development) a "post-agile" approach, which doesn't really help in differentiating Agile and lean but emphasizes the fact that they are not the same.
From my experience companies that focus on agile have highly productive teams but often lack an efficient flow across the value stream while companies focusing on lean tend to have a real efficient flow but tend to lack efficiency inside the teams. To employ agile techniques inside the stations along the value stream while managing the value stream itself in a lean manner to me seams to produce the best results.
To get a first hand experience of how to integrate lean and Agile approaches you might want to come to the workshop that Tom Breur and I will run on May 28th & 29th in the Netherlands