Hi, welcome to this lesson where we will be looking at Scrumban.

What content is covered in this lesson?

We’ll talk about in the next few minutes:

• the differences as well as advantages and disadvantages of Scrum and Kanban,
• the KPIs of the two methods,
• and the hybrid Scrumban derived from both methods.
• We also take into account the issue of budget pressure,
• and finally draw our conclusion from the knowledge gained.

But now to the content of this lesson:

How does Scrum differ from Kanban?

I have already announced in the previous lesson that I would dedicate myself to the contentious topic of Scrum in a little more depth.

But first the question, what is the difference between Scrum and Kanban?

From the Scrum point of view

• Kanban has no time-bound iterations (among others the sprints)
• Kanban does not require story stimulation
• Kanban does not know the principle of the “Commitment” (that means: the obligation to the temporal supply of defined contents)
• Kanban works with completely different metrics than Scrum

and Kanban does not require a Scrum Master

Feel free to pause this video for a detailed look at the differences between Scrum and Kanban. When looking at this comparison of Scrum and Kanban, we quickly notice that Scrum principles and events can be mapped in Kanban, but are not elementarily necessary for the implementation. This circumstance gives us, with a mixed form of Scrum and Kanban, the flexibility to avoid the weaknesses, criticisms and points of contention of Scrum. And it is precisely this flexibility gained from the mixed form that promotes a sense of responsibility within the team. Scrumban focuses accountability on meeting and improving team metrics. And basically, for a project manager and Scrum Master, both Scrum and Kanban are not only about achieving project or sprint goals, but also about achieving performance and quality driven metrics. So where is the difference in the metrics?

What is the Velocity?

For Scrum, velocity is a very important metric that indicates the Story Points delivered per Sprint. And the Story Points are paid for, after all. So the goal is to deliver at least that many Story Points to cover the team’s costs. At least!

The charts themselves can be displayed in different ways – here are just 2 examples.

What is Commited vs. Delivered?

In Scrum, the relationship between “Committed” and “Delivered” is very important for sprint goal achievement. The goal is that all confirmed stories of a sprint are also delivered. The shortfall in the form of the Estimation Errors line shown here is a flaw and failure that must be addressed by appropriate means. The measurement of estimation errors in % enables comparable results even in the start-up phase of a project and with team size changes.

What is a Burn Down Chart?

And then there is the well-known burn-down chart in Scrum, which shows the team whether the processing within a sprint is within the planned scope, whether there is a delay or perhaps even a head start. The burn-down is the graphical cue to the team to raise the stakes to meet sprint goals if they are behind schedule – whether by spending more time, focusing on key requirements, or optimizing staffing. When looking at these key figures, it quickly becomes clear that all of them together cannot contribute to the optimization of workflows. They are solely financially driven. Velocity does not indicate real delivery performance, only delivery of Story Points (the financial value generated). If a story causes more effort than planned, then this is not captured with the velocity. Commitment vs. Done only leads to stories and tasks being set to Done in the team despite being unfinished and having to be reopened at the review after the Sprint. In practice, this key figure says nothing at all. Quality definitely does not play a role here. And that is also the big point of criticism.

The manual burn-down on the brown paper or whiteboard practiced in hardcore Scrum is completely impracticable in practice, especially with distributed teams, because in reality not every single team member keeps their task notes up-to-date and the Scrum Master cannot move the associated stories to the appropriate status in a timely manner either. The typical curve always looks like this and has no added value for the team.

Now let’s move on to the Kanban metrics, which in my opinion are one of the greatest strengths of Kanban and contribute a lot to the successful use and strong spread of Scrumban.

What is the Throughput?

First of all, there is the throughput, which indicates the number of stories in a freely definable period of time. Of course, as a team member, I am also interested in what revenue we generate with which “tasks”. However, I am primarily interested in what yield we generate with what “effort”! If the Story Points are set too low through commercial negotiation, the Estimation results from the team have been revised downward after the story sizing for order placement, then the team has very limited ability to correct and meet that. In this case, it is just as presumptuous to look for fault with the team as it is to expect remedial action from the team. The throughput per effort is therefore a suitable key figure to measure the real team performance and to exploit optimization potentials based on it. Story points as a result of negotiations with the client are therefore not included in this graphic and this key figure.

What does the Cycle Time mean?

A second good metric in Kanban is cycle time, which is the number of days a user story takes from requirements gathering to delivery to the customer. The special feature here is that really all phases are covered and thus optimization potentials are revealed to keep the cycle time as short as possible. The goal here is to stay within an agreed percentile of, say, 85%. 15% are therefore deferred due to intended deferrals. If the percentage above the agreed percentile is too high, then this indicates that the requirement determination has not worked purposefully enough, i.e. requirements are tipped in that do not yet have given dependencies. This, of course, must be avoided. Requirements elicitation must be well managed by the product owner so that the elicited requirements can be implemented smoothly.

What is a Cumulative Flowchart?

And then Kanban also has the Cumulative Flowchart, which covers all project phases over the entire project period, showing the number of requirements and the time it takes to process them. The number of completed requirements naturally continues to increase over the course of the project (shown here in blue). Requirements identification is usually very high at the start of the project, then levels off over the duration and ebbs away completely towards the end. Analysis, development and testing should be relatively constant after an acceptable phasing-in of the dev team until the end, if the team strength is not changed significantly during the course of the project. This diagram also shows undesirable developments as a basis for correction.

So, what is left for us to say aside from the key figures?

What are the characteristics of Scrum?

Scrum is extremely structured. And that’s a good thing. But also very strict. Experience has shown that especially higher-ranking team members have a hard time with this and as a result always initiate discussions about sense, which, however, have no raison d’être in Scrum for the basic principles. Scrum involves constant time pressure, which is implemented through time boxing (we’ll go into this in more detail in a follow-up lesson). However, events are also strictly delimited, which means that any event content that is planned but not achieved is equivalent to a real failure. Unfinished content cannot simply be finished after an event expires. No, they are reset and then need to be rescheduled and approached again. Be it in Sprint, in Refinement or anywhere else. Scrum uncovers any weaknesses in the team and requires the team to take appropriate action to avoid these weaknesses in the future. The strictness of Scrum leads directly to the exclusion of convenient ways out or a muddle around it. Scrum is merciless and requires an extremely high willingness to change and humility. With the hard cut at the end of the sprint, sprint planning, the necessary story estimation and a clean refinement become success-relevant factors for sprint goal achievement. But also within the refinement the solution time is limited by a time boxing. The goal and flexibility again subordinate to planning, as in the waterfall model. And the quality suffers as well.

This circumstance then also leads to the criticism that Scrum is no longer really agile in some areas, but time and finance driven. As a result, not only the quality of implementation suffers, but also the creativity for new approaches to solutions, which is after all the goal of agility. Please remember the Agile Manifesto here. But venturing something new is hardly possible under these circumstances – too risky. And then with pure Scrum we are in the situation that the method no longer guides us, but limits us and prevents important goals of agility.

Add to that the extreme workload of a Scrum team. The team is constantly under pressure to achieve maximum output. What initially sounds positive for the commercial goal, however, usually results in high fluctuation – and this at a time when expertise does not necessarily fall ripe from the trees. The pure Scrum simply makes you all and requires a very special kind of person who combines the necessary expertise, extreme discipline and reliability with the ability to suffer, humility and self-responsibility. I don’t want to say that there is no such one. Sure, there are high-end scrum teams out there. But they celebrate the very high school of agility. This certainly does not reach the masses, and the projects with such a radical approach subsequently go down the drain, fail to achieve their goals, disintegrate, end up in group depression.

What is Scrumban?

Scrumban has evolved for this good reason. Scrumban uses all events and tools of Scrum, and is therefore perfectly compatible with other Scrum projects. Instead of hard-core boundaries in events and time-boxing, Scrumban uses Kanban boards for task tracking, where tasks are actively picked up from the previous swim lane and moved to the following swim lane after completion. Hardcore Scrum coaches then call such a thing a petting zoo. This allows for much more individual task tracking than with fixed-limit events or time-boxing. Other positive effects include better compliance with quality requirements and the injection of creativity for innovative solutions. When an event such as a sprint is finished, then a task that has not yet been completed is finished after the sprint or in the follow-up sprint, depending on the requirements – without hiccups and pressure.

If you hear today that a project works according to Scrum, there is almost always Scrumban behind it. You will hardly find pure Scrum today – and it is also realistically only possible within a software company for the development of internal products with internal staff that must constantly work together in person on site. Hardcore Scrum is hardly usable for distributed teams and there are virtually no ALM solutions that support pure Scrum. Almost all ALM solutions basically work with Kanban boards, only a few provide add-ons for the implementation of Scrum boards – and these then do not even meet the necessary requirements for the hardcore Scrum masters. Pure Scrum is a paper economy that takes you back to the age before typewriters. Handwritten note-typing always presents team members with unfamiliar challenges due to a lack of proofreading options, and the legibility of the content is sometimes hair-raising to impossible. In addition, the sticky notes regularly fall off the wall and the subsequent assignment to the appropriate process is, to put it mildly, somewhat difficult for many processes. The archiving of processes is just as hair-raising – from literally non-existent to eternally long rows of cardboard folders from which you will never find anything again. This is why there are so many opportunities for error in all areas. I am only thinking of the attempts to interpret illegible note contents. You just don’t always run to the author after all, especially not on the customer side. All in all, therefore, not a real option for the mass of projects.

When is hardcore Scrum practiced today?

Today, pure Scrum is actually only unpacked when the budget pressure in the project is extremely high and the commercial side is therefore trying to drive up efficiency in the project with the extreme pressure of Scrum. Personally, I can only warn against such an attempt, because it is very likely to fail. Much more purposeful would be to be aware of an impending minus margin, define clear limits for a strategic commitment and, in case of falling below them, freeze the project until a suitable budget with appropriate targets and sourcing is available. Only this approach is professional in the agile sense.

Personally, I think it’s quite good that something like Scrumban has evolved from the archaic Scrum. Scrumban is simply practical, takes into account the frameworks that exist today such as distributed teams, remote work, involving experts from around the world, and working with software solutions instead of illegible pieces of paper that don’t want to stick to the walls. When I think of all the travel and room costs for team members carted together, it makes me sick as a budget manager. These costs all come out of the scarce project budget. No, Scrumban meets today’s requirements much better – and is also fun. This aspect is also important for the achievement of objectives.

Does Scrumban exist as a method or framework?

Yes, and it is also clear: Scrumban as a method or framework does not exist! This is a self-evolving hybrid without a fixed definition. Everyone can mix Scrum and Kanban according to their own needs and inclinations. The fact that this is then called Scrumban is a pure neologism. Because the mixed form practiced then is neither pure Scrum nor pure Kanban.

Now let’s summarize what we have covered in this lesson:

• we have looked at the differences as well as advantages and disadvantages of Scrum and Kanban,
• scrutinized the metrics of both methods and determined which metrics are actually relevant and practical for team performance,
• from this we have derived a hybrid form called Scrumban,
• we talked about how we should act professionally when there is very high budget pressure,
• and drew a conclusion from it for the application of Scrumban.

Since this is the last lesson in this course, I will use that to say goodbye. Scrum versus Kanban – this is always a reason for intense arguments. Maybe it’s already burning under your nails? So, now on me with roar (laughter). I’m off then …