Dark SCRUM and what about it?

During our engagement in various companies or during discussions on our courses, we are increasingly discovering that there is such an inconvenience here in the Czech Republic … In English speaking countries they call it Dark SCRUM or also Technical SCRUM. These phenomena very often lead to the failure of an agile approach and subsequent resistance to anything that begins with the word agile. What is it about and how to stay on the bright side of SCRUM?

What is a Dark SCRUM?

In short, it is a misunderstanding of the agile approach and SCRUM itself. The traditional approach to project management and related activities in strong corporate thinking focuses its attention on things like:

• Processes,
• Tools,
• Deliverables,
• Estimates
• Individuals,
• Bonuses,
• Individual performance KPIs, etc.

Imagine that with this mindset, we begin to implement (!) Agile … but without changing the way of thinking and still focusing on individual performance, specific deliveries in a clearly estimated time, etc. Just another way to deliver, produce. And we have a Dark SCRUM!

How the Dark SCRUM manifests itself

Usually not all at once, but often (in a slight exaggeration) appear situations and conditions such as:

• We command people that they must deliver in sprints. That they must attend at a daily SCRUM meeting. And that this particular scope (this WBS) must be delivered in this way in 4 months in the prescribed form with the given acceptance criteria.
• If not, there will be no annual rewards that cannot be talked about because their amount is individual and terribly secret… so that people may not envy or even want more (It is known anyway, because in our country everything is going to talk anyway … or at least to guess and to deduce 😉).
• None of the direct users or customers go to the Review because: not interested,  have no time, too often, they don’t know why they should be there, after all, it was solved in the assignment, they have nothing to talk about and nobody invited them.
• They are not surprised either, because the team “demonstrates” things such as converting DB from 3.2 to 3.21, or creating the about_nothing.dll library, etc. – that both sound Cantonese to users and have no value for them.
• The team is therefore doing a de facto Review for itself or possibly for a person called a Product Owner, who has not been seen the entire sprint and who only collects requests from all sides and sends them without major modifications to the team.
• Or the Review is actually just called a control day, to which senior management will come to see how each product progresses.
• The team has never seen real customer because management is terrified of the idea that the customer would see that bunch of hippies. Or perhaps they should even talk! So the customer is represented to the team by the salesman or the project manager or another mediator of the customer’s thinking (he says that the customer exists and he saw him!).
• Some of the WBS items are large, so we’ll stretch them to more sprints and create a de facto Gantt chart with delivery dates.
• Management thinks that it is uneconomical to have a SCRUM Master for each new team So think of, say, one agile coach for 15 teams could be a good and efficient. YEAH! This is immediate cost savings and that counts! Bonuses for that!
• etc. – there is a lot of another scary stories.

 Results…

It is quite obvious that something like this simply cannot work well. And it doesn’t work either. SCRUM is directly based on a self-organized, competent team that receives as much and as direct feedback from the customer as possible, and in cooperation with the Product Owner adjusts its next steps – as transparent as possible, in the form of sprints. The above approaches are in stark contrast to these basic SCRUM principles. So the recommendation is not to try SCRUM in such an environment at all. Until the thinking or understanding of what SCRUM is based on has changed.

 The Dark SCRUM and Shu-ha-ri concept

It is actually also a failure to respect how to learn something well. The Japanese have their Shu-ha-ri concept:

SHU

Follow the rules

• Beginner level. A drill that requires sticking to the rules and not changing them. The goal is to perform tasks correctly and in full quality.
• Do not invent deviations, adjustments or why it is not possible.
• It can be months or years until the “basic forms” just get into your blood. It’s a lot of work that requires patience.
• Eg. Follow the basic rules for stand-up meeting – max. 15 minutes, only three basic questions: What was done yesterday, what I want to do today, what blocks me.

HA

Break the rules

• You already have the basics, so you can start experimenting, innovate. However, you still adhere primarily to the basic framework.
• Eg. you will add a fourth part to the stand-up: “I could use some help with that and that.”

RI

Bet he rule

• Master level (including Scrum “master” 😉).
• You create your own, even completely new forms. You learn from your own practice and experience.
• Eg. you will turn the stand-up into a free discussion about reaching the sprint goal, but at this stage, effective, concentrated, and factual (if you were to do this with a Shu team, it would be just a messy meeting without much results).

We don’t even have to go to Japan … a model of apprentice, journeyman, master of crafts … has worked here in Europe for a long time … and it’s actually the same thing.

So if we are talking about agile and it is new for us, it is simply advisable to follow the SCRUM guide as it is written. We are apprentices. Start doing SCRUM and throw something out of it right away and start doing it differently, because “we don’t like / we don’t believe / we are used to something different” is often the way to… hell and the result is very often a dark SCRUM.

And what is it other than a dark SCRUM?

As a framework, SCRUM creates certain boundaries, boundaries, for self-organized teams of (competent) people. Apart from a few key events (Sprint planning, etc.), it actually does not prescribe any specific techniques, methods, etc.

There is not exactly written what the Product Backlog should look like, if and what the SCRUM board should be. In fact, only some constraints and the principles to be respected (transparency, control, adaptation) are listed. A philosophy is described in which we try to produce a piece of customer value as soon as possible and get feedback on it as soon as possible. And adapt accordingly.

The actual procedure how to achieve this, which techniques and how to use, is already set by the team. Therefore, in this context, by the way, it is nonsensical to “implement the model X or Y”. The described procedures originated in a certain context, composition of people and after many iterations, when these people changed the procedure through retrospectives (and changed themselves, their attitude, their culture). And they will keep changing. Applying their way to you without going through a similar path is likely to fail. You haven’t discussed it fifty times, you didn’t made the same mistakes, you haven’t changed… Even one of the authors of the agile manifesto likes to say, “The best way to start doing SCRUM is in your own way.” Which doesn’t mean you can’t get inspired. But the copy + paste approach is probably not the best idea.

We welcome changes also in the advanced stage of development…

… because the goal is not to deliver the originally described functionality, but to maximize value for the customer.

Instead of individual KPIs, we focus on the performance of the team as a whole (mesured as delivered value for customers). Individual members are not interesting from this point of view. It is up to all members and links between them, creating a comprehensive social system known as a team. And we understand that there is a need for someone to help the team be effective – the SCRUM Master (if you want to try it, you can visit our training to simulate an agile project with lego4scrum).

Product from our Agile and SCRUM training

Obviously, just a “mindset” alone will not suffice, but it is the basis without which it simply cannot work. How would the inhabitants of Prague from the time of Charles IV look at you if you told them about parliament and democracy? These people wouldn’t understand what you’re trying to tell them. They do not have enough iterations and retrospectives yet… Some “big bang” implementation would probably hurt very much and maybe it did not go well (the French know about it). But you can start explaining things. Trying to find flashes of understanding and to build on it with slow steps.

It is also good to realize that Agile, or SCRUM is not the goal… but the way. E.g. to more satisfied customers, a better product and a more motivated team.

The fact is that it is not possible everywhere right now

Starting to do things in an agile way, or SCRUM has its problems and points to solve. It cannot be deployed anywhere, at any time and under any circumstances. And dark scrum just doesn’t work;).

First, it is advisable to have some suitable products or projects… building a bridge with a length of 1 km with SCRUM probably does not make much sense… (more in this article on the suitability of agile approach).

Furthermore, quite often is the agile manifesto criticized by that it is not quite clearly stated that a functioning SCRUM requires relatively competent people. That is, people who have skills and discipline.

We cannot want people who do not know and / or do not want to create an effective self-organized team from day to day… we must first teach them the skills at the necessary level and also the basic level of discipline and responsibility. Again, it is the responsibility of the “line” management to make it happen (and there is still quite a lot of work left for the line 😉). We also solve how to build self-organized teams.

The environment itself can also be a big stick under your feet. If you have about ninety parallel running systems that share data with a variety of data pumps and widgets and some of it has been running for 20 years and nobody even knows how it is actually done or understands the language in which it is written, you will find difficult to deliver pieces of customer value in short sprints. Maybe you would have to spent several years rewriting everything into new versions that could make possible such iterative approach.

So how to avoid the Dark SCRUM?

But you can always start somehow. There are many elements and procedures you can adopt. There are for example some easy to apply:

Self-organization

E.g. Gradually increasing team self-organization, delegating more and more responsibilities and decisions (you don’t have to start with system architecture decisions of course). But teach them that they will make decisions on their own. It helps a lot if you are able to describe your vision, goal, direction, where it goes. To be able to make decisions from the perspective of short-term benefits or long-term benefits. What better fulfills your product / company / vision?

Retrospective

Another powerful spell is a well done retrospective. Which has very good results even in non-agile projects and teams. It is always good to be able to stop and think about how HOW we do things and not just WHAT we do.

Transparency

Greater transparency, such as some form of KANBAN (which is the Japanese word for blackboard (or whiteboard?), so we could write the blackboard… but Kanban sounds much more sophisticated;)) and depicting the workflow in the form of leaflets, whether physical or virtual. And limit the amount of work in progress, which is actually the main principle of this famous method. Again, not limited to agile or sw development of course (after all, the procedure comes from the automaker, production company …!).

Let us proceed with an open mind and do not be afraid to experiment slightly. Agile is one of the possible ways to achieve your goals. I wish you that your first steps won’t be too painful.