Scrum is not a Silver Bullet

Introduction

A writer and consultant, not particularly interested in Scrum, wanted to discuss Scrum's shortcomings.

It was obvious he had a self-interest in talking this way. But let's not attack the man (ad hominem), but rather in a simple manner address some of the key issues.

Scrum is a bare framework. That is all. It is not trying to be a full methodology or address all the problems of every situation.

Why?

• It is not possible to cover every situation
• People can only implement something that is small. They can make small incremental changes. A big bang is not useful
• It is much easier to test a small thing. Fewer variables

One problem: people want a full solution, straight from a book or even an article. They want a simple and correct and complete and an easy-to-implement answer. (You see the near impossibility of being all 4 of these at the same time.)

But, as much as they desire that, I think no one can give them that.

What is possible is to have a group of small patterns, that then each person (or each Team) in their own specific situation, can assemble or implement. Pick and choose from. And slowly, see if the patterns will help that specific situation, or how they may need to be modified to make them (together) workable, helpful.

Let's agree. It is possible that one thing, if not addressed, might stop the group of things recommended (eg, all the patterns in the Scrum Guide) from working. Yes, there is that risk. This may be a problem sometimes, but from my experience and the experience of many others, while this might happen, it is not common.

What we do say in Scrum is: "Common sense is not very common." Not to accuse people, but to accept the reality, much as Lean does, that we must rid ourselves of the old way of looking at things, because that stops us from seeing things as they truly are (or more closely to what they truly are).

Some issues

The Bigger Organization

One issue is how to organize things so that the Team fits in with the rest of the organization. This is indeed an important issue. And commonly, confusing and important that we soon get it right.

Lots of "scaling" approaches give some answers. The Scrum community and ScrumPLOP.org have patterns (answers in the form of patterns) for this problem.

In fact, this particular issue is complex, and can have different good solutions, depending on the specifics of your company or organization.

This issue, like many others, is importantly constrained by people. That is, the people involved each have biases, points of view, ideas about what will work. The question is not always - what is the best solution. The question often is what is the best solution that people can agree to do, and then implement effectively.

Fun and Happiness

Another issue is the well-being, fun and happiness of the Team.

This, to me, seems something that the Team must work out. And are best positioned to work that out themselves.

Jeff Sutherland has two quotes that are relevant here: "Fun is essential." "If they are not having more fun, they aren't doing Scrum right." So, while it is true that Scrum is done wrongly in many cases, sometimes quite wrongly indeed, real Scrum is working on the "work-life balance" issue, or however you prefer to phrase it. "Fun is essential" works well for me.

Another angle to this issue is stress and overworking. For example, some feel that the word Sprint means that the Team should be out of breath (figuratively) at the end of each Sprint.

This is just wrong. For example, I have never heard Schwaber or Sutherland (or any good Scrum person) say that the point of the Sprint is to get people stressed out or to work beyond a sustainable pace. ("Sustainable development" is explicitly part of the Agile Principles, and Scrum subscribes to the Agile Manifesto and Agile Principles.)

So, this is not an issue with Scrum (although one might argue that the Scrum Guide might take some words to argue against over-stress and the like). So, if people are over-stressed or overworked, this is an issue with how some people are understanding Scrum, and implementing it.

It is fair to say: If over-stress and overwork are happening a lot, then Scrum advocates should talk about this more. I do (eg, in my courses). I know others do. Perhaps we need to talk about it more or find a more successful way to discuss it. Still, every conservation is both the speaker and the listener. Those who have ears to hear, let them hear.

Conclusion

As the Scrum Guide says, Scrum can be a wrapper of things "inside" Scrum (or inside the Team). And things (eg, patterns) can be added to Scrum, in fact must be added to Scrum. This is good and necessary, and not contrary to Scrum. (Although it is often not done well.)

What is far less clear is what to add in your specific situation. And how soon to add it. As suggested above, any person or organization can only digest so much change at a time.

Our basic recommendations are these:

• Identify and prioritize your concerns (problems, impediments) with your Team for now. You might organize some as goals (a basic example: "We want to do agile-scrum to support and increase business agility" - which of course begs the question of what you mean by business agility)
• Learn about all sorts of patterns and other possible solutions
• Make small changes, and check if they have helped and how much they have helped
• If a small change has not worked, at least consider whether something else is a prerequisite (eg, something in Scrum you are not doing yet, a pattern in A Scrum Book, or some other thing) -- so that, when that prerequisite is addressed, then that small change will then work. I think there is a large number of these "prerequisites" -- it is impossible to write a book big enough to discuss all the varieties of situations humans can be in.
• And then prioritize and attack your next impediment (next change)