Scrum is not a Silver Bullet
Joe Little
Owner, LeanAgileTraining.com, Kitty Hawk Consulting, Agile Coach & Trainer, MBA, CST (Certified Scrum Trainer)
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?
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:
Software Engineer
1 年Scrum is a bare framework. - yes.