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!
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.
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.
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 :-)