Recently we had a Kanban info session with my team and it was great.
In order to make this Kanban thing look less of a disruptive and crazy idea for our team, I asked colleagues from the German headquarters of our company to give us this short introductory training. There’s quite some enthusiasm around Kanban within SAP already, as you may see from this Lean Kanban Central Europe speech video from earlier. It’s not hard to introduce the Kanban concept, as our centrally encouraged software engineering and project management process is not pure Scrum but something called Lean Development Model, so Lean ideas in general sound familiar to lots of people. However, Kanban is far from being mainstream. Having this training session remotely was not an issue and using video conference helped a lot to make it even better.
Here comes the interesting part.
To my surprise the hardest things for the audience to understand were not limiting work in progress (I guess because everyone feels that too much multitasking is bad) or the lack of the sprint rhythm (because we have to re-plan our sprints very frequently anyway as the world around us is so dynamic that sprints cannot be short enough).
The hardest nut to crack was the lack of concepts such as detailed upfront planning and estimations. Of course you can do this in a Kanban environment, and Kanban itself has some elements addressing this need (for example “Fixed Delivery Date” class of service), but it’s not a core concept. In our environment and company culture, it is (still) a very strong expectation to plan releases upfront and give commitments well ahead.
We should learn how much of this planning and estimation addiction is a true must (external requirements, constraints, dependencies to other teams etc.), and how much of it is simply an old bad habit of the team. How much should we keep and how much of it can we transform to something more agile?
