Reliable and Ultimate Scrum - agile Softwaredevelopment in Practice
Here you can find some kind of a blog where I write down the experiences of current "Reliable Scrum" and "Ultimate Scrum" implementations.
2014-03-03 some examples to show
a) a typical sDBR-(Kanban)-Board:
Every story has one row/lane for its own and there are just a few stages "columns": planned (the buffer) - in progress and in review - done. As described below (2012-10-26) Ultimate Scrum concentrates on optimally using the constraint (Developer) by opening a less as possible in progress or in review tasks.
So the rules are like this: #1 if you put a task in don then you have to take one from review, #2 if there is nothing to review you can pull one from planned, #3 if you cannot work on a task solve the impediment first … #4 if there is no task in planned any more then open an new story – break it into tasks, talk with the team about the tasks (planning II for just one story) and start with the first task.
- Concentrate on "as less as possible open tasks!"
- The golden rule is – less open tasks then developers!
- Concentrate on "as less as possible open stories!"
b) then you'll get a CFD (Continous Flow Diagram) like this - with a very small "inventory area" between accumulated in- and out-flow.
2014-01-20 some more information about the full scale Product and Project Framework ...
- a google translated version of the full scale product and project framework ...
- a description of Reliabe Scrum in englisch ...
- more about how portfolios, projects and agile works together ...
2013-07-27 full scalable Agile and Project Framework ...
... becomes concrete. Everyone knows SAFe (c) D. Leffingwell - that's somehow fine for production (generating products) but not for projects. If you have projects than you have to do a little more and something different to get a perfect flow for both production and project(ion). It's all about Drum-Buffer-Rope, Critical Chain combined with Reliable and Ultimate Scum - more information will follow :-)
2013-07-23 The Tame the Flow blog ...
... has started - with a lot testimonals and new additonal information!
2013-06-14 The book "Tame the Flow" is published on leanpub.org
Together with Steve Tendon we compiled 300 pages full of ideas how to bring organizations to hyper productivity. Part IV is all about Reliable and Ultimate Scrum and how to establish it in an organization. It's available on leanpub.org as pdf, epub and mobi - DRM free ...
2013-06-06 TOCICO 2013
I presented Reliable and Ultimate Scrum on the international conference of the throughput manager (TOCICO in Bad Nauheim). But not just Reliable/Ultimate Scrum even more - the lecture was about how to combine it with a full blown Critical Chain Project Management to get the best of both worlds - an agile Enterprise. More details s. the blog article about the lecture of Jack Vinson or just get in contact with me ...
Here another graph of a Reliable/Ultimate Scrum Project - this time a long runner. Unfortunately the team started with 30% buffer consumption - we found on the first day the first missing stories. After that it developed quite normal (typical for the first phase in a project). After eight weeks we got in some troubles - we had to deal with legacy and we had to learn how the legacy system works. That costed us buffer every week and we got in red. And very typical - being in red activates the "buffer regain" energy. With real effort and concentration the team worked itself back into yellow and then green. Caution - the last jump was not one week it were three weeks. I was on holidays. So the real reason for the progress was - the boss was not around ;-)
For more details (in german) see the page on the speed4projects.net
And further more my speech was selected as one of 5 "new knowledge" sessions on the TOCICO international world congress for 03. to 06. Juni 2013 in Bad Nauheim :-)
New Version of the WIP- & Execution Control Excel is available ... faster, more accurate and some minor bugs fixed ... download
2013-01-20The interest in Reliable Scrum is growing every day. This website alone has more than 1500 visitors per month and lot of downloads :-)
Every year I offer one or two Critical Chain VIP-Seminars in Germany/German. This year I extended this seminar by on day especially for Reliable/Ultimate Scrum. This day can be booked individually or of course together with the critical chain parts. Sorry the seminar is typically held in German - but if you are interested feel free to get in contact - we'll find a solution.
Here you can find more Details - to register just send me an e-Mail.
Reliable and Ultimate Scrum is just one part of the game. It's perfect if you can produce production like in a dedicated team. Nothing better than that.
But sometimes (i think very often) this will happen embedded in projects or even in multi project environments. To manage these Critical Chain (Multi) Project Management is the state of the art.
If you wan't to use both (and that makes very often really sense) you have to map agil/production to Critical Chain. Thats easy but it is necessary. In this document you'll see how we do this mapping for one of my customers.
- The descripton of the mapping from agile to Critical Chain
- The wikipedia description of Critical Chain English and German
Now the "Ultimate Scrum Scribble" is available as fully readable graphic :-)
After switching from Scrum (classic) to "Ultimate Scrum" with Drum-Buffer-Rope steering s. below, the team concentrates even more on getting things done - especially to have the least amount of tasks open and bashing all impediments away that hinders them.
The cumulated flow diagram was pretty good - even before the change ... but afterwards it's getting even better. The number of tasks is melted down from something around 10 to now 2 open tasks. Now it's getting dangerous - I think we have to buffer some more tasks to avoid "starving". But the lead times of the task are pretty good - just ONE DAY!
p.s.: if you look into the diagram you can see Little's Law - on day 4 there were some more tasks open and who wonders - the lead time doubled.
Here the fever curve of jet another reliable scrum project. It's a huge infrastructure project with milestones and something around 2000 story points.
Perhaps you can see the difference to the other fever curves below? There is no such big gain in velocity after switching to reliable scrum. And one other thing - there are far more "measure points"! The reason is easy - this project is not scrum any more - and it's even not Kanban. It's steered by a "third generation production steering method" called "Drum-Buffer-Rope" (DBR on Wikipedia - in the TOC article or in German DBR). DBR is known for the lowest possible inventory (open tasks), therefore the best possible lead time and on top the maximum throughput. Therefore I call it "ultimate Scrum" or "continuous Scrum".
This is the scribble of "ultimate Scrum" on a A7 index card. I try it to describe it in as few words as possible:
- The goal is to get rid of the unnatural breaks at the end of the sprints. Sprints are like batch sizes and elongates the lead times and blow up the inventory.
- Don't panic - many things from scrum survive (most of it is very useful) - just the steering is adjusted. We do every 14 days a retrospective - fine with that. We had this planning 1 - but to do "reliable scrum" you have to do it, even roughly, in the first sprints. So after an "affinity estimation" you have one complete backlog (that can vary of occurs) but you have it - so the grooming/planning 1 is mainly done. Reviews we do too - but not in a defined cadence - but every 5-10 finished stories when it's really worth to show something. No discussion about half finished stories any more. Stand-ups, impediment logs and so do all stays the same.
- So what changed? There are no sprints anymore! It's all a continuous flow with the goal to have as less as possible stories and tasks open.
- To achieve that - the process is divided in to independent parts a) breaking down stories into tasks - on the left side of the task buffer and b) processing tasks to deliveries - on the right side.
- The steering on the left (story) side is easy. It takes something around 4h for one person to break a story into tasks. So everything is steered by the amount of task in the task buffer (sometimes called planned tasks). If there are just 2 Tasks left - one of the developers has to take the next story from the backlog and breaks it into tasks. It can happen that waiting until just two tasks left - is too risky. You see that - when a buffer whole occurs - no task in the task buffer left. If you see that phenomenon than just increase the alarm threshold by one until no buffer holes occur any more. The alarm threshold should not exceed the number of developer divided by two.
- To monitor to story burn down - the product burn down chart and the fever curve, as shown in "reliable scrum", are the best way. These diagrams are updated after every story finished > that's the reason why there are more measure points in the fever curve. By the way this is not a Drum-Buffer-Rope steering this is called "Vendor Managed Inventory" or "Just-In-Time-replenishment". The vendor (backlog) looks at the stock before the production and refills this autonomously.
- And now to the right side - the Drum-Buffer-Rope. O.k. this is not a classical Drum-Buffer-Rope. Normally you have many process stages as in Kanban. We have a two stage continuous integration process with "developing" and "review/test". But if you have just one type of resources - we have flexible developers which do all - then it is like one stage. The developers have assistance by QA members, who write the tests - but in the end the constraint is the developer - one constraint = one stage. Then it makes no sense to distinguish between the process stages. Both are constrained by the availability of the developers.
- Drum Buffer Rope consists out of the three parts. There is a drum - this is the constraint resource in this case the developers. The drum is like the heartbeat of the production chain. Then you need some Buffer (normally in Front of the Drum) but in this case if you have just one constrained stage - so the inventory (amount of open tasks) itself is the buffer - so what! And the rope (that is the signal line to start new tasks) is triggered by the buffer. In this case very easy - if one task is finished a new task can be started.
- The right side is monitored by an "aggregated in/out-diagram" or sometimes called "flow-diagram". The goal is to keep the inventory (difference between in and out line) as low as possible.
- This can be achieved in a very easy way. No new tasks were started until the first "buffer holes" occur. If the first developer runs out of work you have to increase the buffer by one. But this should be an exception and had to be analyzed. Buffer holes are full of information about impediments or process problems. But finally if everything possible is done - and buffer holes occur you have to increase (slightly) the buffer/inventory to secure the throughput.
- If the buffer/inventory is stable for a long time - you can reduce the inventory step by step again e.g. by defining the rule 5 tasks out 1 task in or something like that.
So that's it - now you have:
- continuous flow
- with the least possible open tasks
- and the shortest possible lead time
- and the best possible throughput
and that's called "ulitimate scrum" :-)
p.s.: it's mathematically proved that DBR is the optimum - there will be no fourth generation scrum any more > that's the reason why there is no velocity gain any more - sorry about that - but the optimum is the optimum!
The interest in Reliable Scrum is very intensive. I'm often asked about trainings and speeches. The next event is on the PM-Forum 2012 in Nürnberg (23.10.)
That is the most important project management congress in Germany - therefore i'm really happy that I can show the positive effects of Reliable Scrum - to make Scrum even more attractive for more organizations.
In the projektmagazin.de a complete article with examples and all the necessary tools has been published. The reaction of the community is pretty positive - 7 times in a row the best ranking *****. Unfortunately the article is in German - if you want more information in english just ask. You can get the article by using a temporary test abonement for free ... or asking me via e-mail. By the way - the article is now on rank #1 of the top ten articles of the Projektmagazin :-)
The first feedback from one of the Reliable-Scrum projects came in today: "In any case, the discussion with stakeholders went really better, because it was clearly stated, what is inside and also what is NOT done in the project. The uncertainty principle and the hopes were eliminated- which alone has helped to set the correct Prios!"
Same in German: "Auf jeden Fall ist die Diskussion mit den stakeholdern schon mal besser gelaufen, weil hier bereits in der Planungsphase klar gesagt wurde, was gemacht wird und speziell auch was NICHT gemacht wird. Die Unsicherheit oder das Prinzip Hoffnung sind damit raus aus dem Projekt - allein das hat schon geholfen, die Prios richtig zu setzen!"
I found an excellent blog article about TOC and software engineering. Especially the part about Throughput Accounting (TA) is very interesting. I really think TA is very important for agile Enterprises and the base for the next evolution step in business.
Two more Reliable-Scrum-Projects started. One within 1&1 Internat AG and one for a strategig platform development for manufacturing control systems. At the time new fever curves are ready i'll show them :-)
And it's not me alone, who had the idea to combine Critical Chain and Scrum. Ansgar Knipschild from mgm in Köln did something similar. He used more or less a Cricital Chain container to manage the Scrum underneeth. Instead of Excel he uses CC-Puls as management tool.
The first reliable scrum seminar is available and I'm very glad that Boris Kneisel joined as co-referent. Boris Kneisel is associate professor at the KIT, he has 15 years project experience amongst others as ScrumMaster for SAP AG Walldorf. He coaches and counsels DAX30 / Euro-Stoxx50 Hightech-Enterprises how to implement Lean & Agile (Scrum) and innovation management doing Design Thinking. You can’t get more experience in one seminar!
The first reliable scrum "project" is finished :-) and with an extraordinary success. After the seventh sprint it was clear, that the progress is much better than expected and the project duration was reduced by 37 days or 13% (*1 in the diagram). After this you sea a steady progress and buffer consumption - everything was under control. That is the best thing you can show to a stakeholder #1 reduce the duration and #2 steady progress. That builds the trust needed for the next project.
I worked the whole day - an now it's ready. The first version of the "reliable scrum guideline" - probably with lot of orthographic mistakes in it. But this version is consistent to the excel files and a good start :-)
Today I programmed the last missing pice in the realiabl-scrum framework. The "Portfolio Overview". If you have a lot of scrum teams to manage it's hard to get the overview. If you have reliable scrum in place you have for each a fiber curve - the biggest part is already done. But in the end you are just interested in one question - which of my scrums need my attention?
What about this diagram?
This diagram just shows one arrow for each scrum team. It shows the last and the current status - the arrow points in the direction of the development. And now it's easy for you (and all the stakeholder) to see immediately which scrum team needs the attention (in this example it's the "bad" scrum team) that turned from yellow to red! Here you can see an example report with additional information below.
Within the next days there will be a real example of a big portfolio of scrum teams - i'm looking forward hat the diagram looks like :-)
The Excel-File to generate the diagram can be found in the download section.
At the 11.05.2012 I was on the InterPM an had a speech about Reliable Scrum. There I'll refer from the praxis and I will be available for any questions.
Click here to download the presentation (in German - sorry).
On the InterPM it was very obvious, that the polarization between agil and classic makes no sens any more. Moste of the speeches were about combining both. There are situations were agile is perfect and some were classic (not waterfall) projectmanagement is necessary. We now see more and more "projects" with classic and many scrum teams mixed with scrum masters and project managers working hand in hand :-)
A whole portfolio of scrum teams (more than 10) started with reliable scrum :-) Within the next 3 weeks we expect that the backlogs are cleaned up and the first fever curves will occur. That would be interesting - cause than i can show the portfolio view of the fever curve - just be prepared.
In the kick-off there were a lot of questions - based on this input there will be a new execution control excel. It's now all based on weeks to avoid the velocity-time-base discussion. Both excel are now integrated in one.
Next Sprints next look at the fever curves. Now they are two - and a lot more will follow.
The first scrum release shows now a significant buffer consumption. Why that? There was another more urgent issue to solve and therefore it was decided that one developer has to help out in the other team. And as a result the velocity drops. But it's obvious that it still fits. Besides of that two sprints befor the team decided to adjust the due-date! They reduced the lead time by six weeks - 14% of the original commited lead time. That is a strong sing to the stakeholder - that the team can handle the situation and performes very well.
The second scrum release is also very interesting. It shows a continous increase in velocity. They started in deep red and worked themselves into the deep green with continous "buffer regain". Our explanation is easy - if the team knows that it has buffer, it plays up freely. It pulls new stories as much as possible (very optimistic) - the feel secure. Buit if this goes on like this - i strongly suggest to change the due-date or put some more stories in the backlog - just to prevent student syndrom and parkinson. Just as much that the curve goes into yellow again.
2012-04-16Not just the interPM is interested i got also the invitation from the PM-Forum 2012 23./24.10.2012 in Nürnberg/Germany. It's the most important project management congress in the German speaking region of Europe. I'm really proud of that the project management community finds this reliable scrum stuff so interesting. It's my fourth time I can present something on the PM-Forum:
- "4-6-4-Method to set Strategic Priorities in a Very Easy an Practical Way" - to reach the optimal benefit for a company - 2006
- "Behavior beats Methods" - four simple behavior principle which makes the difference between normal and high-speed teams - 2008
- "Critical Chain" as a key to agile enterprises (not just scrum - even projects can be agile ;-) - 2010
- "Reliable Scrum" - take the best of both worlds an make them compatible to reach next level of performance - project management 3.0 – 2012
Now the results of sprint 8 are available. The team performance is unbr oken on a high level - therefore the release goes deeper into the green. The scrum masters and mine explanation is that this performance is triggered because the team knows it has a lot of buffer and therefore it feels completely safe - and feeling safe is one key to estimate aggres sive an put as much as possible stories into one sprint.
But why is there no buffer consumption at all? Obviously we overestimat ed the problems that will occur - or they will occur in the next sprints. Who knows?
I now strongly recommend to put some additional stories into the backlog of the sprint or to adjust the due-date (set it to an earlier date). And it’s easy for the product owner to find the correct amount of stories to be drawn or the correct due date to set. Just pull enough stories to bring the release at the edge of green-yellow – so the team has enough buffer left. We learned that the fever curve is mostly a tool for the product owner and the stakeholder – the team itself just wants to know that it has enough buffers.
Together with the scrum master I had a longer talk about the effects of reliable scrum. One finding was that, besides ot the buffers, there is another value for the team.
In the fever curve you just see the status of the release. If it’s in green – everything is fine. But what happens when it goes into the red? Who will be made responsible? The team has here a great concern – if they are performing well (stable burn down) but the product owner pulls more and more stories into the release or a lot of technical problems (legacy) occur – no one will see that – everyone just looks at the team – and that will not be fair!
But the solution for that is very easy to find. Besides the fever curve we also have the classical burn down chart. If you put both together then you can easily see where the problem is. Is the burn down stable it’s definitely not the team (performance). Then you have to look at the release backlog what happened there. I will suggest to make it mandatory for the product owner to comment everything that is done on the backlog - just to make it transparent what happend.
I were on the ASK@IS24 in Berlin. It's one day of intensive exchange of companies (XING, Immoscout24, Sipgate, 1&1) that really live agile and that for a longer time. I presented "Reliable Scrum" and it was absorbed with great interest :-) There is a huge need of transparency for the product owner and the stakeholder where the scrum team stands.
The results of sprint 7 of the pilot release/project is available. Obviously the burn down was a lot better than expected. Significant progress was achieved and as a result the team regained buffer.
And you wont belive what happens now. The product owner wants more stories to be included. Thats absolutely fine - but how many? This question is easy to answer - just include as many stories that the "fever curve" hits the line between green and yellow. In this case something around 50 story points (the curve is drawn for two scrum teams together) - that makes sens. After including these "should"-stories the progress is once again balanced with the buffer consumption.
Today is a good day. Based on the reliability calculations the stakeholder board accepted the due-date for the release with the entire calculated buffer. Therefore the team has now enough resources to manage the release (and the buffer) completely independent.
The other good thing is that the product owner board (it’s a platform development and because of this there are more than one product owner) requested to use the fiber curve as a regular indicator whether the backlog and velocity are under control.
This week the 6th sprint was finished and we started with the second part of "Reliable Scrum" the execution control. The goal is to draw this "fiver curve" - means buffer consumption drawn over the progress. "et voila" here it is:
this example the buffer is set to 35% of the duration from start to
due-date. As a result the buffer consumption is in the same range like
the progress. Everythings fine.
But - the is danger ahead! If you look at the curve you see that the buffer consmption increased in the last sprint. The challenge for the team is now to get the velocity and the backlog under control. But there is buffer - therefore the team can deal with the problem itself.
The calculation of the fiber curve is done with anonther simple excel-file ... you can find in the download area.
Part I - getting a realistic due date is nearly done. The backlog is transparent, all the big stories are cut down into smaller pieces and the velocity is adjustet with the team. Now it's possible to calculate a reasonable due date and adjust this with the stakeholder. The excel file we used to do this can be found in the download area.The Program i use here as an example consist out of two big streams. The scond stream started a little later (3 Month) and uses this "Reliable Scrum" ideas right from the start. After their first three sprints they've done the affinity estimation and without any problem they estimated over 180 backlog items, qualified them into must-schould and specified to which release the items belong. The tooling get used right now and it feels really normal to do.
First of all the “should” backlog items were split
and now it’s clear what’s in the release or not. Now the Backlog for
the Release has an amount of story points that can be realistically
burned down – if the velocity is planned correctly.
another positive idea occurred. With this list of backlog items you can
go to your entire stakeholder to get acknowledged that this will be fine
to fulfill their needs. That will be done within the next days.
there was another thing – the planning of the velocity. To calculate
the absolute probability of success according to the backlog and the
velocity, you need an estimate of the velocity for the next sprints. I
just asked the scrum master – what will be an estimated velocity of the
team for the next 4 month?
The answer was 55 story points!
But is that a valid answer? O.k. there is some work to be done. Many Questions occurred. Velocity is no absolute number – it’s a probability too. There is an optimistic velocity (if the team comes into this flow state of performance). There is a realistic one (maybe this are the 55 SP). But there also may be a pessimistic one (if a team member gets ill or left the team and you go back to the forming-storming-performing cycle). Then you have to “normalize” the velocity to a time base (e.q. week). And that’s more tricky – we found out that burn down of story points is measured in different ways. What happened with not delivered stories – I learned that they are not counted as burned in the sprint. That’s no problem – but you have to find a correct way to measure and define the velocity. And last but not least, after all this theoretical thinking, you have to get the commit of the team to that velocity.
O.k. not every day it's sunshine. This time I
looked into the backlog to check the progress of WIP control and what
did I see! The amount of the must backlog items increased tremendously.
Simply there was a definition of importance of
the backlog items – the MoSCoW Scheme. But this scheme is ambiguous.
“Must” is clear – fine with it. But what means “should”? If a should
backlog item has 100 story points – how many of them count to the
current release? Just a fraction of it counts as must, to implement the
workaround, and the others can be postponed. Therefore the stories have
to split apart in a must and a should backlog item.
I was just giving a training in “how to avoid too much work-in-progress” to a group of managers at another location of 1&1. I just mentioned that there is such a thing called “Reliable Scrum”. You can imagine what happened. The next scrum team wants to use it. Now there are 18 scrum “streams” that uses “Reliable Scrum” as additional steering mechanism.
I mentioned that the platform “thing” will be
developed by three scrum teams. Within the last day’s while working on
the backlog it became clear, that there are two streams. Two teams will
work on the backend stories and on team at another location will work on
the frontend. And they are interdependent!
Something more happened! Another program found out what we’re doing here. The responsible for that program has the need to have an Overview about 15 scrum streams. Now we’re doing the same here – 15 streams – starting with getting the backlogs straight.
The goal is to have a portfolio diagram of the progress and buffer consumption of all 15 streams. It will look like this:
One new idea occurred. We can enhance that diagram by adding littler arrows where the stream status came from – so we can see the changed
The backlog stabilizes. Most of the not qualified
stories were shifted to a further release. Many of the
100-story-point-stories where broken apart and the missing MoSCoW-labels
where added. But the most valuable thing that happened was that the
team discussed with the product owner and found even some more missing
Up to now the amount of must-stories is in a
realistic range and even some of the should-stories can be included. But
how to find out what’s possible and how to communicate this with the
To do this I build up an excel sheet that works with probabilities (s. “Reliable Scrum”
). There are two probabilities involved a) the amount of story points
in the backlog and b) the velocity. For both there is not just one
estimate but a probability distribution.
For the amount of
work in progress (backlog) we set the current known amount of must and
some should-stories as the optimistic baseline. We discusses a while and
came to the conclusion, that in a realistic case there will be
additional +20% of story points we now not know about. In the
pessimistic case the will be even more – so we decided on +50%.
other important probability is the velocity. Out of the last sprints we
knew that the velocity was something between 50 and 75 story points per
sprint. That meant that a realistic velocity will be something around
30 story points per week. But I someone would be ill or left the team it
can be significant lower (20 story points per week). And if the team
comes into the flow state it could be much more maybe 50 story points.
Out of these probability curves you can calculate the absolute probability of delivering the promised result over time (s. Excel file for doing this). This will be the basis for talking to the stakeholder within the next days. But we don’t talk about something cloudy – we’re talking about facts and assumptions.
I went to the scrum master and asked for Details.
Fortunately the scrum master is very experienced and has a project
manager and a jira expert at hand. They had 3 sprints already done and
therefore the basis for “Reliable Scrum” was perfect. As I described it
is best to introduce “Reliable Scrum” when you already have some
information about the backlog and velocity at hand.
through the results of the “affinity estimations” and ooooops they were
not usable at all! One third of the stories were not qualified (MoSCoW)
and the estimates were missing. It was not clear which of the stories
count to the release (01.06). Furthermore 20% of the estimates were in
the 100-story-point-or-more-region or in other words “we don’t know what
to do!” I calculated the probability of success for the must-stories
with the current velocity and came to 3% - “Huston we have a problem!”
this has nothing to do with “Reliable Scrum” – but to implement
“Reliable Scrum” you need a properly maintained backlog. There is no way
to postpone the unavoidable. You have to fill the backlog.
provided a complete analysis of the situation to the responsible person
and the team. In the next day’s the team concentrated on filling the
“gaps” and enlighten the “blind spots”. The Team got a list of all the
- Unqualified Stories – missing MoSCoW
- Stories where the estimates are missing
- Stories where the estimates are to huge. Some “research stories” were added to break the big stories apart an get better estimates
In parallel we decided to group stories to components and find a responsible person for each component. This will be some kind of a Work-Breakdown-Structure with Responsibilities – one of the most powerful artifacts of the classical project world :-)
Now “reliable Scrum” comes alive. Sometimes I can’t keep
my fingers off – I looked at one of the most important projects in our
portfolio. It’s the core development of a platform that will enable us
to produce new applications in a quite faster and efficient way than
before. All the projects of the second part of the year will rely on the
results of this project.
And this project is managed with
scrum. There are there scrum team involved with thousands of story point
to be burned and a fix due-date (01.06.20212). The scrum evangelists
will now say: “This is not scrum! In scrum you don’t have fixed end
dates!” Yes they are right – this is not scrum – this is a real need of a
real company that has to earn money to pay their employees. So the
question is – how to fulfill this need and have all the good effects of
scrum. You need “Reliable Scrum”!