Scrum is an Aggressive Game

It seems that people forget that Scrum is meant to be an aggressive game.

It does not assume a world where everyone goes home smiling with a participation trophy.  It is not a game for little children. It is a game for serious (albeit usually smiling) adults.

At the same time, we are meant NOT to over-commit (eg, commit to more stories than we can do in a Sprint).  We are meant to have MORE happiness.  The product should have HIGHER quality.  And we should be PROUDER of what we are delivering to the customer (even if we have given up the “certainty” that the customer will like it). We are working smarter, not harder, each day.

Put another way, I think Scrum should have all the advantages of open and honest friendly competition and none of the disadvantages.

Is that do-able?  Well, there must be some people I wouldn’t eat Tiramisu with (and I love Tiramisu).  In general, I think quite d0-able. Although we’ll never do it perfectly.  OTOH, in some cases, some teams will hear those words and do things that I never meant or wanted… the bad stuff…that will happen a bit.  Controllable I think.

But has this message gotten to all the Teams?  To all the players?  To the managers?  To the executives?

***

What I see is a mixed bag.  Some of these messages are out there.  Some Agile coaches are talking about these things.

But there are also a LOT of bad examples.  (By “a lot” I do not mean a high percentage.)  Some examples:

• Teams routinely over-committing in the Sprint Planning Meeting
• Team members paying no attention to each other during the Daily Scrum.
• Business stakeholders showing disrespect for the Team by not showing up or having minimal feedback now (but more feedback later on these stories)
• Managers putting pressure on the Teams (although one wonders whether this “pressure” could not easily be discussed)
• The Team being pulled apart, as though its mission were unimportant
• A culture of “chaos” and “fires” above the Teams, so that the Teams never have a sense that they can win
• No estimating of stories
• Teams with no Velocity
• No clear improvement in Velocity
• Inattention to technical excellence
• Teams that have no sense of what victory would be
• Zero to low aggressiveness in attacking the impediments

***

What can we do?  Well, there are so many situations and so many possible actions.  Be careful in applying these suggestions to your situation, inappropriately.

• Remind Team members and Managers that this is an aggressive game and we are meant to win.

Apparently, this reminder is necessary.  It may raise questions.  One: how will the managers help us win? (Ans: by supporting the fixing of impediments.)

• Re-articulate the current vision of the product, and make sure all the right parties buy-in to that vision, and its relative importance

The whole team must buy in, and so also must the right business stakeholders. Perhaps others. I truly support the Lean Start-up approach to winning, so I am ok if the first release “fails” in a way that leads to lots of learning and a pivot.  Discuss how you want to achieve success.  Also: understand the relative importance of your current product. Doing this clarifies which “distracting” work you must say NO to.  Probably your Team cannot say no to all “additional small requests” if they are truly important, but equally, why is a Team working on a product if they can be disrupted for any “small additional request”?

• Re-affirm that the Team wants to win and that it can define what winning means for them.

Be clear about what winning means.  Usually, it is the next release coming out by X date and being successful (by some measures).  Then: ask the Team if they want to be successful together in winning.  (For some people, the answer might be no. Deal with that.)

Be careful NOT to ask the Team to over-commit.  Commit to attempting the difficulty, not the impossible.

• Collect a Top 20 Impediment List

And decide to work that aggressively, at least one thing per sprint.  So that we are working smarter, not harder.  You may have to explain that an impediment is anything that is slowing the Team down.  A thought, a culture issue, lack of automated testing, lack of better continuous integration, insufficient skills, egotistical team member, one manager, etc, etc, etc.  The Team gets to prioritize the list.

***

Those four steps might be a good start toward becoming a great Team.

 

« « Question: Path to — Trainer or Coach? || Let’s consider Aggressive Scrum » »