• Home
• News
• Resources
• Books
• Glossary
• Archives
• Blog
• About
• Contact

When is Scrum not Scrum?

February 22, 2007 @ Agile Thoughts from Tobias

(No Ratings Yet)

 Loading ...

In teaching Scrum during the past year, and working with organizations in a consulting/training capacity I have found more and more that some of the principles as outlined in the two Scrum books are out-dated and unhelpful. I teach what I know works and what I see as being appropriate; there are slight differences in each context of course, but there are certain practices I have found to be effective, all of which differ from standard Scrum practices; some would be considered radically different, which leads to the difficult question, the title of this essay: when is Scrum not Scrum?

1. 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, and now encourage teams to incorporate the Product representative (not owner) into the daily meetings and the retrospective as well as the planning and review meetings. To do this successfully requires a different mindset from everyone involved, so the style of training and adoption needs to change accordingly. This is not trivial.

2. 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. It is also true (from my experience) that teams are incapable of planning a thirty-day sprint effectively. It is overwhelming. Most teams I have tried it with nail the first part of the sprint, but allow the second part to be vague and muddy. They get exhausted by the eight-hour meeting, and simply find the time frame too long to plan effectively. A thirty day time frame also means a customer change request can take up to 60 days to be completed; that is far too long.

3. 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. Long ago I moved towards encouraging team members to break all tasks down as small as possible. A task must be completed in a single working day or it is considered an impediment, and should be marked as such. This approach serves two purposes: firstly, ease and accuracy of burndown (burndown on tasks rather than hours, making the whole process binary: a task is done or it is not done) and secondly it raises impediments which developers themselves may not see. For example, an incomplete task may be in that state because a developer was called off into some long and meaningless meeting, but because “that is the way we work around here” this is not seen as an impediment. Physical markers on tasks (e.g. stickers on task cards) show the truth of what is happening.

4. Use of Taskboards rather than spreadsheets
The Scrum books, and many CSM courses promote the use of spreadsheets to track the sprint. This is really horrible. Spreadsheets hide information, and they lie. 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. Taskboards can work with distributed teams too, by having proxy updates (via telephone) and sharing photographs of the board on a wiki — every day.

5. Backlogs on the wall
Again, moving away from spreadsheets. 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. Backlogs much longer than that, containing anything more than placeholder items (reminders) can be thought of as wasteful, in any case. The less time we give to thinking ahead in detail on features that may never see the light of day the better.

6. Estimation Meetings
Estimation is done before the first sprint, and then on a regular basis during each sprint. 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 (not “ideal developer days” as described in the Scrum books). The estimation meeting is an integral part of a successful cycle. Having the backlog on the wall ensures developers have continual look-ahead time, thus keeping the estimation meetings short.

7. Insistence on Agile Engineering practices
It isn’t enough to assume because a team is “doing Scrum” that engineering practices will begin to change. They won’t. And they don’t. It is essential to introduce some core practices such as unit testing, early acceptance test specification, componentized design, continuous refactoring and pairing from the start. This doesn’t mean the practices will all be undertaken immediately, but the importance of such practices must be stressed. 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. Intuitively even, it seems likely to not be true.

8. The Scrum Master role is not always necessary
An effective self-organizing team is exactly that: self-organizing. Leadership emerges from the team when the key Agile principles are adhered to. The Scrum Master role becomes superfluous in a healthy Agile organization. There is a role for Agile leadership at all levels in an organization, but Scrum Mastering so often becomes a pointless role, and many organizations see it as another type of project management role, driving people. Coaching should be appropriate to the context. I have seen a lot of lousy Scrum Masters, falling into old PM habits, and having teams simply accept it, because that is how they are used to working. I also have issues with the term Scrum Master; language often dictates how we behave, and this term doesn’t help to break paradigms.

So is what I do Scrum? Perhaps it is; there is enough of the original flow there to claim so: planning meeting, daily meetings, delivery of working software each sprint, retrospective, but ultimately the name itself is superfluous. The Agility inherent in the principles I teach and coach to allows fundamental change to take place in organizations. That is what I am after. If it helps to call it Scrum, we can call it Scrum. It offends to call it Scrum we can call it something else. Eventually, it will simply be “what we do”.

Scrum is a useful framework to get started down an Agile pathway, but if the framework becomes a rigid way of thinking it destroys its own purpose. The reason so many organizations struggle with Agility is because they want a quick fix. Scrum purports to offer that through its two-day “Certified Scrum Master” course. It is a superficial and ultimately unhelpful approach, and one that I am glad, finally to be disassociated with.

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.

Comments

Copyright © 2007 PMToolbox :: Tools and Resources for Project Management