Skip to main content
Enterprise Agile Planning icon with arrows

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 Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us