Vortrag auf der internationalen Konferenz der Durchsatzmanager (TOCICO 2013) am 06.06. in Bad Nauheim

English version can be found directly below the german text ...

NEU auf Leanpub.com

Tame the Flow - Zähme den Fluß

eine Anleitung wie höchste Produktivität in Organisationen erreicht wird. Hier finden sich auch alle Details zu den "advance Agile"-Methoden wie Reliable/Ultimate-Scrum und wie man diese am schnellsten einführt.

300 Seiten - Englisch - jetzt downloaden ...

und hie geht's zu Tame the Flow Blog ...

advanced Agile und Critical Chain = agile Enterprise

Agiles Projektmanagement hat eine große Verbreitung gefunden. Seine extrem leichtgewichtige Steuerung hat Vorteile - ist aber am Schluss eine lokale Optimierung und nutzt daher nicht das volle Potential. Auf der anderen Seite bewährt sich Critical Chain als voll ausgeprägtes Multi- und Einzelprojektmanagement - aber manchmal (z.B. in Arbeitspaketen oder Teilprojekten) reicht eine agile Steuerung vollkommen aus - sprich weder Critical Chain noch die agilen Methoden nutzen das gesamte Potential.

Der Vortrag zeigt einen zweistufigen Ansatz zum einen die agilen Methoden kompatibel zum Projektmanagement (bevorzug Critical Chain) zu machen und im zweiten Schritt die agilen Methoden selbst optimieren. Beides basiert auf den Denkprozessen der Theory of Constraints und der zugehörigen Drum-Buffer-Rope-Steuerung. Dieser Ansatz ist bei mehreren Unternehmen im Einsatz (u.a. ein international tätiger Internet Service Provider und ein weltweit tätiger Elektronikkonzern).

Die Ergebnisse sind äußerst positiv. die verbesserten agilen Methoden eignen sich hervorragend, ganz leichtgewichtig die Teilprojekte zu steuern. Der Work-In-Progress (Einlastung) ist und bleibt unter Kontrolle. Der Termin ist durch einen Puffer abgesichert. Durch die Drum-Buffer-Rope-Steuerung und den Projektpuffer gewinnt das Team Sicherheit was es mit erhöhtem Durchsatz belohnt.

Informationen zum Thema

English version


Agile project management gets broad propagation. Its extreme lightweight steering has advantages – but are local optimizations and do not use the full potential. On the other hand Critical Chain is a full blown project steering – but sometimes e.g. in sub projects agile methods can be absolutely sufficient. So Critical Chain doesn’t use the benefits of the agile methods.

The presentation shows a two phase approach to first make the agile methods compatible to Critical Chain and in the second step to improve the agile methods itself. All this is based on the thinking processes of the TOC and ideas based on Drum-Buffer-Rope. The approach is validated in real projects and real teams’ part of a worldwide active internet provider.

As result agile methods can be used to steer sub projects more lightweight. With small adjustments it’s possible to get some buffer at the end to initially control the WIP. With the buffer at the end you can use progress-buffer-consumption monitoring. That makes agile compatible with CCPM. You do not need protection of sprints any more, therefore continuous flow is possible. The focus moves to reduce the inventory of open tasks. Maximum throughput and minimum lead time are now realistic reachable.

More information:


Critical Chain is an appropriate way to manage projects and project portfolios. Mainly in software development (but also in other domains) there are parts of projects that have very less outer dependencies and can be broken down into small comparable tasks. Since ten years, based on the agile manifesto, some agile methods to manage “projects” occurred and gained a broad propagation (more than Critical Chain). Nearly all Critical Chain Implementations (especially in IT) now face the situation, that there are agile methods already in place with more or less success.

Agile methods are very effective local optimizations – so they are mainly successful. On the other hand they are just partial solutions and many problems are unsolved:

  • To secure the throughput they limit the work-in-progress hard in a team - but they cannot deal with uncertainties and therefore they cannot commit on a specific scope to a specific time. There is no work-in-progress control over the whole “project”.
  • Without an explicit buffer and committed due date there is no operational relevant monitoring possible – an equivalent to the fever curve status is missing.
  • There are still negative social group dynamic effects. Due to the lack of a project due date and buffer the only steering possibility are the small work packages (stories). Especially in Scrum the team has to commit on an amount of stories to deliver in some small time. If something goes wrong (and of course it does) the team is punished (in very subtle ways). As a result they buffer the stories and cause auf Parkinson they lose throughput.
  • Agile methods are, in the core, production systems. They deal with many small independent parts (stories in a backlog) and very short touch times. To get a good flow (Kanban) or to protect the team from outside (Scrum) they accept more open work in progress than necessary and a result the lead times are higher than necessary and the throughput is less then possible.

Agile methods are a valid idea to easily steer production like sub projects. Currently Critical Chain is not really able to use this advantage on a broad scale. The agile methods are just partially solutions – so they do not user their full potential either. So potential in project management is lost!

The solution should be to find a way to make agile methods compatible to critical chain, so they can be easily used when applicable. Additionally one has to find a way to define a project buffer and to get the progress to buffer consumption monitoring. Further on it will be important to improve agile methods to the theoretical optimal throughput and minimum lead time by reducing the inventory (open stories/task) to minimum and get rid of the unnatural batch sizes.

The presentation shows, based on the TOC thinking processes and the knowledge of Drum-Buffer-Rope, how improve the agile methods. All these improvements are validated in practice in real projects and teams. The presentation shows evidence and examples out of this practical experience (s. Reliable Scrum in Practice Blog ).

The Change is undertaken in two Phases. First make Scrum/Kanban reliable (Reliable Scrum) and Second to apply Drum-Buffer-Rope like steering on the agile Teams (Ultimate Scrum).

Reliable Scrum - the Idea is to initially control the work-in-progress for the projects (release). To do this you need explicit information about the amount of work (story points) you have to do and your capacity (velocity). You have to calculate the chance of success and negotiate with the stakeholder an appropriate amount of work compared to the time and resources you have.

First you qualify you backlog. All stories needed for a specific release (project) are tagged. Missing stories are added. The stories are estimated (story points) and big stories have to be broken down into smaller ones. Together with the main stake holder (product owner) the team estimates a quota of additionally occurring story points in realistic and a pessimistic case. As a result you’ll get the probability curve of the backlog.

After that you estimate the velocity (story points per week) until the end of the release. Normally you have some experience data out of former sprints – this will be the realistic case. So you just have to estimate the optimistic and the pessimistic value. That gives you the probability of the velocity.

These two curves can be used to calculate the absolute probability of success over the time (s. Reliable Scrum Full Description ). Together with the stakeholders it’s now up to the team to negotiate a reasonable scope/due-date or resources to get a realistic chance of success. This will be something around 80% (the upper turning point of the s-curve).

As a result you get some buffer at the end of the release. So you are now able to use the known product-burndown-chart with the negotiated due-date to monitor the progress and the buffer consumption in a critical chain compatible way. This can be used to keep the work-in-progress under control.

Ultimate Scrum - after having Reliable Scrum as an appropriate steering for the release in place, the focus changes to the inner management of the tasks in the team. The goal here is to have the minimum amount of open tasks.

On side effect of Reliable Scrum is that there is no need of the sprints to protect the team from the management any more. So the team can easily switch from batch mode (sprints) to continuous mode (drum-buffer-rope).

To achieve this, the process is divided into two stages. First stage is to break down stories into tasks. A task is defined as work with duration of about ½ a day. To do this breaking down into task takes typically something around ½ a day too. So the steering is easy (not even a drum-buffer-rope). The team has a task buffer. If there are less than one or two task in the buffer one team member gets the next story from the backlogs and starts to break it into tasks and refills the buffer.

The next stage is to transform the tasks into delivered results. This is normally done in one, two or more stages. The steering of the inventory is mainly done based on the output of finished tasks. If one task is finished one new task is allowed to start. If there is the suspicion that there are too much open tasks then the rule is two tasks out – one task in. If a developer has nothing to do it’s a strong indicator for a problem (impediment) that should be solved (before opening a new task). This is a “one stage” Drum-Buffer-Rope-Steering. If there are more than one dedicated skill group it develops to a real Drum-Buffer-Rope steering.

As a result the impediments are solved quickly. The amount of open tasks goes down to the amount of developer or resources in the team. The flow and throughput increases and the lead time reduce to the minimum. With Reliable/Ultimate Scrum you can integrate both worlds agile and Critical Chain. Both can gain advantages from each other and use their complete potential.

As a result the focus of management goes away from the process – everybody knows that its operation on the theoretical optimum. The motivation of the team members increases dramatically. Quality reaches optimum. The new focus is on doing the right things and on the people itself. The new capacity is uses to develop educate, exchange best practices. The true leadership gets more and more effective.

Outlook - if you now look at the project management as a whole, you see the three layers. Portfolio or multi project management looks like a production. The projects are staggered according to real or virtual drum. It’s more or less a Drum-Buffer-Rope steering. The single projects are managed by the critical chain. The deviations are buffered and the steering is done by progress and buffer consumption. Sub-Projects, that have sometimes (not always) again the production character are again managed in a Drum-Buffer-Rope style.

Based on the type of complexity and situation the best possible steering method is used. The Optimum in Throughput can be reached!