When is Scrum applicable?

Over the years, I was oftened asked the question: "Is Scrum applicable in this context?" or alternatively "When or under which circumstances can I apply Scrum?". I gave (and read) lots of more or less sophisticated answers to that question, but have a very simple approach to answer this now.

You are able to (and probably should) do Scrum if:

1. You are able to fill a Product Backlog
2. You have - or can establish - a Team (which means team - not group!)
3. You have - or can establish - a Product Owner
4. You have - or can establish - a Scrum Master

That's it.

Of course you can still use several single practices and tools of the Scrum framework if these conditions are not fullfillable - which is not a sin. But you should not call it "Scrum" then!

Value People over Techniques

Many people ask themselves: "What makes a successful organization?". And since there is so much question  and therefore much money to earn there are tons of consultancies and "simple technical" solutions to this question. So far, I did not see any of those solutions succeed. Even my personal favourite "Agile" is definitely not a solution in terms of "do it and you'll succeed". Why is that?
I think it's pretty easy: It's because the problems we have to cope with in todays environments are mostly "social" problems and only rarely technical problems. But people love to approach all kinds of problems with technical solutions, because it is the easiest and considered to be most "scientific and exact" way. It is for sure the most convenient way, since you must not bother with complex and not linearly answerable questiones.
This said, I personally believe that to align your environment to a more successful direction, you will have to focus on the more complex "social" questions first and at least become aware of these crucial factors and derive "technical" solutions later as one aspect of the way to go. Concretely this means, to focus on:

• Corporate culture before defining corporate strategies
• Values of your employees before implementing rules and guidlines
• Satisfying your customer before maximizing your profit
• Maintain the ability to change and adapt before maximizing the efficiency to produce.

Hereby I mean that everything mentioned above is absolutely important, but one should focus on the "social" items on the left first and derive adequate "technical" solutions on the right then.
Easy? Not at all. To me this evokes many serious and hard questions immediately:

• How do I know, what corporate culture I have? And how can I describe this appropriately? How can I measure this? How can I present advancements? (and many more...)
• How can I know what the values of my employees are? And how can I influence these? Is this possible at all?
• How do I meassure the satisfaction of my customer? It is sure not as simple as just implementing some simple tool (NPS, etc....).
• What is the right amount of ability to change? And what is the threshold where I must lay more value in efficiency?
• and tons of more questions ...

But after all: If you would agree, that in principle the four sentences stated above are right, the immediate consequence must be to focus on these questions first and think about the "technical" aspects later (which is, what for example the Stoos Network seems to do).

The Thing Missing in Scrum

I am working with Scrum very successfully for several years now. And it is by far the best methodology crossing my way in software development. Yet, I think there is one thing, missing in Scrum - its slack time.

Most Scrum coaches would probably say: "No, no, no... Slack is not missing. It is ...

1. ... automatically emerging, because the team is self-organized. It is in the responsibility of the team to take whatever slack is needed to accomplish their work."  
2. ... an optional add-on to Scrum. You can just implement some slack additionally as you like. But Scrum does not lack slack. Slack is not missing more in Scrum than it is in traditional work environments."

I personally think, those arguments are not valid. 

Argument 1 is questionable: Nobody knows when he "needs" some slack, to be creative and thoughtful. Slack happens to help sometimes and does not help on other occasions. Thus, slack must just be there from time to time (for every single individual - not the team as a whole), so you get a chance to let your brain defocus and accidentially stumble over some very good ideas and thoughts. The tricky thing about slack is, that you will not "miss" it at a specific point. The need for slack ist not foreseeable. Thus a even a self-organized team cannot be expected to know when to take some slack time.


Argument 2 has its flaw, too: You could similarly say that Scrum has no need to contain the role of a Product Owner, but one should implement it as an add-on to Scrum. But this is obviously wrong, since you need somebody giving input to the team, having a more global vision, and beeing responsible for creating business value. Scrum needs to define this role, since it removes the role of the project manager (who was responsible for this tasks earlier).
I think the same is true for slack: Scrum is much about focus and productivity. This is not wrong, but it lacks a necessary concept of slack. Even more, it squeezes some natural amount of - often healthy - slack out of the team that occurs in most classically organized companies from time to time. The point is: Because you are working so much more focused on creating value for the customer (which naturally comes with Scrum) and achieving Sprint goals, a certain amount of slack should be built in, too. This is why I personally think that slack is the missing thing in Scrum.

I guess it would be of great value to Scrum if the framework contained some slack space for every individual in the team (e.g. everybody has one "free" day, where he is not expected to contribute explicitly to the sprint goals).

What do you think? Is there the necessity for slack time in Scrum or are there indeed mechanisms in place substituting this need? What are good mechanisms to build slack into a Scrum team?