Beginnings

How everything began? The roots of “Reliable Scrum” are reaching far into history. I myself was long the head of the project office of the 1&1 Internet AG. In this time I enjoyed to be responsible for more than 500 projects. After so many projects there is no “one truth” any more – it’s not the question of scrum versus classical or Kanban versus Critical Chain. The only question left is – which is the best systemic approach in the current situation and how can all these good ideas be combined.

My “first contact” (yes I’m a trekki by heart :-) was somewhere in the year 2008. Suddenly a Scrum-Master (Alexander Kriegisch – www.scrum-master.de ) occurred in the company and everyone wanted to work agile. On the other side we had this more classical project process to fulfill the transparency and security needs of the company. Together with Alexander we found out, that there is no conflict at all! That was my first learning. In classical and in agile you need a goal to reach – that has to be clear and described (not in detail) – that results in a backlog. You have to have resources, you need a business case – for that you need a sign off from the management. After a while you need to state was will be delivered and when – that’s the same in agile and in classical. The rest are mere details – we added some paragraphs to the existing project management process and the way was clear for agile projects.

But something went awfully wrong! The most important scrum projects failed. Yes something was delivered but far too late and with much more effort ever expected. Something was missing – it took far too long to see the problems!

2010

Independently from agile/scrum/Kanban we decided to implement Critical Chain Project Management as multi project management system. We concentrated on the aspect of bringing and keeping the work-in-progress (WIP) under control. Furthermore we implemented the operational status of projects according progress to buffer consumption and resource shift toward the worst performing projects. That was a major breakthrough! Reducing the WIP resulted in a massive increase in throughput (flow). The new status reporting helped us to concentrate on the critical projects, made the problems transparent and helped to shift the resource to where they were needed.

And there were also scrum projects. They had their own resources, their own schedule and managing – so why bother with them? But they were not as successful as expected.

2011

The first mixed projects occur! I was responsible for a long term strategic project. In this project there was one part that was developed by a scrum organized team. This part was not on the critical chain but if it would have been delivered late the critical chain would have been raped.
The solution was easy. We just inserted two buffer-sprints at the end of the scrum part where it lead into the critical chain. And we just monitored the product burn down chart where the current estimated end was dated. If it was inside the buffer – everything was good. If it consumed too much of the buffer the team was eager to regain some buffer to be ready when the critical chain came along.

Eureka! That was enlightening. Buffers at the end to protect the due date and help the team to focus – the base for “reliable Scrum” was laid.

“Between the years” (the days between Christmas and New Year) I finally wrote everything down. “Reliable Scrum” was born.

If you want to know how it works in real live ... just read here



p.s.: 2008 was not my first contact to agil. Until 2002 I worked as programmer for my own company and for the 1&1. In the year 2001/2002 I read a lot about this XP stuff - I was really amazed. And I was one of the first guys who used JUnit - I had for all of my code tests and click-streams :-)