Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated May 22, 2007 — Enterprise Agile Planning expert

This Page Intentionally Left Blank

Enterprise Agile Planning

People are often uncomfortable with the fact Scrum doesn’t prescribe how to deal with everything else you need to know to do your job. Scrum prescribes three roles, four meetings, 30-day Sprints (often two weeks in practice), timeboxes, demonstrable product increment every Sprint, small teams, and that’s about it.

Reluctance to try these practices is evidence of organizational impediments. The one that’s hardest to do is probably the one you have the most to gain from.

Just about every month some methodologist tries to reduce this discomfort by proposing various “improvements”, often derived from failed approaches such as RUP or waterfall. These blind prescriptions are a bit like stock market schemes: They’ll appear to work 90% of the time, then betray you the 10% of the time that really counts. Even common XP habits (such as overemphasis on unit tests rather than system tests, and mock objects) may drift into this category when the retrospective practice is shortchanged.

Not to knock defined processes unfairly … they work well when both requirements and applied technologies are well known. In these cases, experienced methodologists prescribe canned solutions to inexperienced practitioners, increasing efficiency for repeatable problems.

Scrum differs from more defined processes by insisting the practitioners discover more about their domain than methodologists can predict. Granted, there are some repeatable aspects to software development. But creating new software products is also one of the most complex endeavors humans attempt. The failure rate is much higher than, say, rocket science (which has become a fairly repeatable problem except at the fringes). As soon as we rely on any methodology to solve our complex problems, we can expect to go splat.

What shall we use to fill the empty spaces where we used to talk? Let’s ask Ken Schwaber:

We specifically leave off the guidance or prescription to leave the people free and responsible for managing for value, Sprint by Sprint. We break the management role into three parts:

1. The team is responsible for managing itself.
2. The Scrum Master is responsible for managing the Process
3. The Product Owner is responsible for managing the Product Backlog,
or "What" to maximize value. The PO tells the team what to do, the team
figures out how to do it.

In the matrix, you give a lot of responsibility to the ScrumMaster that they
don't own. They aren't a replacement project manager. They are simply a
process manager and change agent.

Scrum doesn't leave out project management methodological details to have
them filled in by other methodologies. It relies on the above three groups
to fill them in based on their knowledge, the circumstances, and their
intelligence. Scrum relies on a feedback loop for them to improve, not
external directions.


Michael James
Software Process Mentor

More from the Blog

View more
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Contact Us