Tom Breur
26 April 2015
Scrum has been around
since the nineties, “invented” by Ken
Schwaber and Jeff Sutherland. Back in
the days, they worked together to create (“formalize”) the Scrum development
process, and presented this at the OOPSLA conference in 1995.
From years of experience,
several Scrum rules have been established. During implementation, when the
rubber meets the road, questions often arise whether you “have” to obey these rules. Obviously, there is no Scrum police
running around in the office, and self-organization means, well, self organization. Teams are empowered,
decide for themselves how to take ownership and run their own process.
Scrum, if we buy into an
early text by Schwaber & Beedle (2001), is a process geared towards empirical process control. Instead of elaborate advance planning,
you rely on experimentation. Observation and measurement should then clarify
(“after the fact”, looking back at every Sprint
cycle) what “works” and what
doesn’t. Testing and verifying what contributes to productivity, and what
doesn’t, is one of the cornerstones of Agile methods. That’s why Retrospectives are an integral part of Scrum.
Scrum rules come from
experience, not from the Scrum police. Some things have shown to “work”, others
not so much. If you understand why these rules exist, you will
quickly understand which hypotheses you might want to test to find out if
straying from the (commonly agreed) Scrum rules works better for you. Make your
hypotheses explicit and measurable, and … test them in your next Sprint. It
shouldn’t take more than one or a few Sprints to find out if your Scrum rules
are really required, or not.
No comments:
Post a Comment