BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News When is Scrum Not Scrum?

When is Scrum Not Scrum?

Tobias Mayer has written a new piece describing the ways in which Scrum teams should sometimes diverge from standard practice. Specifically, Tobias lists eight areas where he prefers to work differently than most Scrum teams:

  • Product owners are part of the team
Having a hard separation between PO and team is unhelpful; it causes rifts and exacerbates the “them and us” culture. I discarded the distasteful “pigs and chickens” terminology a long time ago...
  • Two-week sprints
Thirty days for a sprint may have been appropriate twelve years ago when Scrum was developed. Today it is far too long.
  • Tasks are not measured in hours
Insisting on hours breakdown and having each team member continually update hours remaining on a task is often perceived as a sneaky, micro-management approach. In my experience team members find this practice frustrating and meaningless.
  • Use of taskboards rather than spreadsheets
The best way to create transparency is to display everything on Big Visible Charts. The interactive, collaborative nature of taskboards lends itself to the Scrum process, like no electronic tool ever can.
  • Backlogs on the wall
At least the next 3-4 sprints worth of stuff should be displayed on 3×5 cards on the wall of the team room so the team can get look-ahead time.
  • Estimation meetings
I have found that a 1-2 hour meeting about 2-3 days before the end of a sprint is the ideal time. Estimates are done in Story Points, as described in Mike Cohn’s books...
  • Insistence on agile engineering practices
Scrum itself says nothing about such practices, and that tends to give organizations a sense that Scrum is easy to do, and can simply (as many of it’s proponents state) wrap around existing engineering practices. I have seen this approach fail too often to have any faith that it is true.
  • The Scrum Master role is not always necessary
An effective self-organizing team is exactly that: self-organizing... The Scrum Master role becomes superfluous in a healthy Agile organization.

None of this is too surprising. Healthy agile development teams have always sought ways to improve, and those improvements are often driven by the uniqueness of each team and their environment, leading teams away from the base set of practices with which they began. All the more surprising, then, is the last paragraph:

On 30 January 2007 I was fired from the Scrum Alliance for challenging the leadership on issues of integrity and transparency. I no longer teach CSM classes. The official reason for the termination: “…the effort to sustain you has exceeded the benefit you bring to the ScrumAlliance over the last year” is a little unclear to me, but it was my time to move on, so there are no hard feelings there, and it does allow me to begin to explore Scrum and Agile in new ways. If we don’t press for change, as context of place and time dictate, then we are in danger of becoming that which we set out to challenge: another silver bullet with fixed solutions to fit every problem. And the Scrum Alliance is in danger of becoming another command and control organization, shot through with rules and contracts to control the course of this new silver bullet. I reject that approach: I embrace chaos, and I embrace holistic, context-sensitive approaches to creating essential change.

Ignoring the specifics of any conflict between Tobias and the Scrum Alliance, agilistas everywhere - and their critics - will certainly appreciate the irony of a Certified Scrum Trainer being ejected from the Scrum Alliance for coloring outside the lines. With apologies to Joseph Campbell, perhaps the agile snake is beginning to eat its own tail?

Rate this Article

Adoption
Style

BT