Scrum is now well over 10 years old and enjoys growing popularity, at least in public discussions.

So it is surprising that most companies, when they start new projects, have to introduce Scrum again and again, because neither teams nor project management are very experienced in it.

Thus, many projects start with making the team and the Product Owner, maybe even the whole project organization in which the project is embedded, fit for the methodology.

With Scrum as an implementation methodology being a compromise in dealing with an imperfect world, ignorance of the methodology is another heavy burden and reason why many projects fail.

In such a situation Scrum coaches, Scrum masters and Agile project managers face the challenge to make teams and stakeholders fit for the effective use of Scrum as quickly as possible. It is crucial to set the right course and to compromise in exactly the right way.

In this article, I will introduce an approach that has worked well in my own work, and that shows significant improvements after very few Sprints.

Rarely has the saying ‘If you’re in a hurry, walk slowly’ been as appropriate as in this situation.

The challenge is to quickly and sustainably introduce a team into Scrum in an ongoing project – regardless if the project has just started or the first Scrum implementation attempt has failed. The prerequisite for the fast and successful introduction of Scrum is patience – something we will come back to later.

The approach I’II describe here works so well because the problems in previously failed Scrum implementations or in new, inexperienced teams are almost always the same.

This in turn is caused by the fact that a Scrum Master certificate can be ‘shot’ in two days; in other words, it is often due to the fact that Scrum is not very complex, requires fewer roles, knows only a few processes, defines manageable artefacts and is based on very few paradigms.

At first glance, Scrum looks seductively simple, which in practice often leads to Scrum being – let’s say – introduced rather mechanically. The challenge itself remains underestimated.

We miss how perfectly these few things have to fit together to get a highly effective process going. In other words, it takes a genius to create a work of art with just one brush and two colors. And when it’s done, it looks absolutely simplistic to the viewer, yet they’ll never be able to do it. Just ask Picasso.

The second reason why this approach works almost always is that it presses the Reset button and re-introduces Scrum independently and unconditionally.

This is only possible because Scrum is indeed not very complex; you just have to do it right, then it can be done quickly. But that’s not easy.

1. Knowing what matters: making the right compromises

If something has to be done quickly in a difficult environment, then it is clear that certain compromises have to be made.

By definition, a compromise is neither good nor bad. Compromising is never efficient; compromises are usually aimed at achieving a certain goal, so that they are more on the side of effectiveness, just as Scrum shifts the focus from efficient software development to effective software development.

I certainly don’t have to explain what happens when you rush into making the wrong compromises: what always happens, will happen. That’s why the beautiful phrase ‘make things worse’ was so aptly invented.

The question now is: how can you find out which compromises are good and which are not? Because you will have to compromise.

Fortunately, this question can be answered without ambiguity: Scrum is essentially based on only two basic principles, commitment and completion. Because Scrum is essentially based on these two paradigms – there could have been more, like quality, velocity or teamwork – it should be clear to everyone that neither of them is really negotiable and therefore suitable for a compromise.

If you compromise on one of the two, then you are already compromising 50% of the entire basis of your methodology. That can’t be good. So if you are thinking about which compromises you are allowed to make and which you cannot make at all, then ask yourself the following question:

Will my team stay capable of commitment and completion when I change what I want to change?

If you cannot answer this question with a resounding ‘yes’, then what you have in mind is definitely not a good compromise.

Anything that negatively affects the commitment or completion ability of a team in its entirety or in a Sprint should be avoided. Everything else you can continue to consider.

2. How to practice getting ‘done’

The first thing I train with teams is getting things done, which is directly derived from what I said before about the essence of Scrum.

No offense: Software developers use about as many definitions of ‘done’ as Eskimos use of ‘snow’.

And we’ve all heard them many times in our daily practice:

• ‘I’m done, but I haven’t tested yet.’
• ‘I’m almost done.’
• ‘Yesterday it still worked.’
• ‘I’m done, but we might have to do it again later.’
• ‘Actually, I’m done.’

I could continue this list for another hour, because the creativity of the developers seems almost unlimited.

But if SCRUM is based on only two paradigms and one of them is ‘Completion’, then of course we have to find a clear definition of the term ‘done’ and practice this process of getting things done.

The term Done, which is used in SCRUM, is derived from the Definition of Done and is non-negotiable.

My golf instructor told me at the beginning of my career: ‘The essence of golf is to get the ball in the air. The fact that it also flies far and in the right direction is secondary in the beginning, that comes later all by itself’. And that’ s exactly what happened.

When you get your team to finish a Story, you’re halfway there.

In the first Sprint I always tell the team that it doesn’t matter how long it takes to implement a Story, I don’t care if they make four, two or just one Story in the Sprint.

Velocity is not an issue. Velocity is the first big compromise I make to achieve the Completion goal.

Yes, I motivate the (often astonished) teams to appreciate the individual tasks as pessimistically and as hard as possible. So that they can always cope with the Story, even if it’s just a small Story.

They should get used to committing in such a way that they can keep it under all circumstances.

As a Scrum Coach or Project Manager you have to be patient. Once a team has gotten used to getting things done, the velocity happens all by itself.

If you do it consistently, it won’t take longer than 2 to 3 Sprints. I know that two Sprints can be very expensive and it’s hard to have patience for two Sprints; you have to bite your tongue.

But keep in mind, Scrum only looks so simple at first sight – while it is not, and with two Sprints you are not that bad off.

Practicing getting done involves the process of creating a commitment, which is done in Sprint Planning 2 by estimating the technical subtasks for a Story. Software developers are usually too optimistic. There are three main reasons for this:

When estimating a Story, a number of tasks are repeatedly forgotten; generally just the implementation is estimated and tasks such as unit tests, code documentation, code review, continuous integration, code refactoring, preparing presentations, know-how transfer, workshops, drinking coffee, and chatting with friends on Facebook are regularly simply forgotten.

After all, developers are superheroes in their own mind, and no one wants to be a loser when it comes to their own estimates.

And finally, developers always appreciate the happy path. They always assume that everything will go smoothly and that they can write their code immediately after the planning and until the review without any interruption and disturbance and that it will be perfect immediately.

This is the moment of the Scrum Master, who has to make sure that enough subtasks are created for all the things mentioned above, that enough buffers are taken into account, and that fair estimates are made.

Suddenly a simple Story which should display only one user profile in one window can mean 4 days of work.

Scrum does not slow down the development. Scrum is like testing for caries – ‘oh, everything is red’. Scrum makes the process transparent and gives you the possibility to work on the velocity later.

To make use of this, make sure right from the start that individual subtasks for individual developers never last longer than 8 hours. Bear in mind that a two-hour workshop with 3 participants doesn’t take 2 hours but 6, and that a Story must never last longer than a Sprint.

3. Changing Communication

In order to support the process of getting ready and to find a transition quickly in order to increase the velocity, it is necessary to work on the communication in the next step.

It is not so much about how to communicate, but more about what to communicate and what the communication refers to.

Let’s take the Daily Standup as the best and simplest example.

Many Scrum Masters do this very mechanically and ask the three textbook questions: ‘What did you do yesterday?’, ‘What are you planning to do today?’ and ‘What prevented you from doing your job yesterday?

This may seem very communicative, because you’re talking about the work in the current Sprint, but you often miss the core of the meeting.

Again, we do take serious what Scrum is actually based on: commitment and completion. And this is exactly what we have to check in the Daily Standup.

The only thing that really interests me as a Scrum Master in the Daily is if the commitment is still valid.

And I therefore ask the team members this very question:

Is our commitment to this Sprint still valid today?

First of all, this question can be answered with a clear yes or no. With a ‘yes’, the meeting will also be quite short, i.e. it will end immediately.

With a ‘no’, the discussion immediately moves towards completion. In addition to recording the impediments, we now need to clarify which of the Stories still have the chance to be completed and how the Sprint goal can still be achieved.

Secondly, the team is clearly taught how to relate to the essence of the methodology. This should be practiced as long and as persistently as possible, until the reflection on commitment and completion is as self-evident as brushing teeth in the morning and evening. We were taught this a long time ago through permanent, daily and above all uncompromising repetition.

The second aspect of communication, which must also be introduced at the very beginning, is the perspective in communication.

Scrum projects often fail because teams want to press the familiar waterfall technical perspective into the Scrum process.

Scrum introduces a radically vertical, feature-oriented software development, while the familiar waterfall relies on a horizontal, layer-oriented development (see Waterfall vs. Scrum). The teams have to be made fully aware of what this means right from the start.

Most teams do not see the methodology under this aspect at all. They think that it’s just their work that’s organized a little differently, but everything else stays the same. So they start as usual with creating a data model and thinking about a data access, business logic and representation layer instead of designing a small prototype for the first function through all layers.

Consequently, we hear again and again the arguments of developers that they cannot build a prototype without an architectural model or that everything has to be refactored later without a mature data model.

Scrum introduces a feature-oriented perspective, the Product Owner describes the Stories from a purely functional perspective, there are no technical Stories, the language in Planning 1 is purely functional and exclusively represents the user perspective.

The earlier you get your team to see things from the Product Owner’s perspective in Planning 1, the sooner you will be able to understand not only the requirements of the Stories but also the vision of the product; based on this, you will be able to make important technological and architectural decisions at a very early stage.

You do this by banning all technical discussions from Planning 1. Only the functional requirements are discussed until the brains of the developers are aligned with that of the Product Owner.

As functional as the language in Planning 1 is, as technical it will then become in Planning 2, because here it is only a question of creating a technical implementation plan – as concrete and detailed as possible – for the technical requirement that has just been discussed.

The subtasks created in this plan can only deal with the technical ‘how’. Most Sprint backlogs are not technical enough on the Story level or even too technical ( to the point of purely technical Stories) and at the same time not technical enough on the subtask level – they still describe the ‘what’, but not the ‘how’ (e.g. implementing a function, testing a function, documenting a function, etc., instead of class XY, adding method Z with the following properties).

4. Using the retrospective

Everything that has been said earlier triggers an improvement process.

You can and should use the velocity calculated from Story Points as a measure for improvement.

Even though we focused on commitment and completion in the first steps while learning to get things done and explicitly dropped Velocity as the focus topic, it remains the measure of the learning curve.

Velocity automatically adapts when the prerequisites have been successfully met. In order to achieve this, one final step is still missing.

Becoming better should be institutionalized, and you need an explicit forum in which you can deal with becoming better, a forum where becoming better is the only topic and not an afterthought.

In practice, this forum is the Sprint retrospective, which tends to be completely overlooked. In a waterfall process, you pass through the software development cycle of specification, implementation, test, documentation, rollout only once.

A lesson learned at the end of the project (very popular with management) makes no sense at all, because the next project could be completely different: different item, different team, different environment, etc.

In Scrum you go through the whole process in every Sprint, and there are many Sprints, so there are many opportunities to improve things in the current project.

The Sprint retrospective is the institutionalized instance for creating a learning curve.

This is the only place where you can manage the most important thing in Scrum: how can we optimize our process and ultimately increase velocity?

Apart from pointing out what others could do better (Project Managers, Product Owners, the Pope or who else), the Scrum Master should make sure that the team identifies at least one thing per Sprint that the team wants to do better on.

In the next Sprint, this one thing should be approached consciously, included as a Sprint goal, and evaluated at the end in the same way as the Stories.

This is the only way to get them into a routine process in which success won’t be a long time coming.

---