This Page Intentionally Left Blank

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.

Ken

–mj
Michael James
Software Process Mentor

Michael James

Michael James is a software process mentor, team coach, and Scrum Trainer with a focus on the engineering practices (TDD, refactoring, continuous integration, pair programming) that allow Agile project management practices. He is also a software developer (a recovering "software architect" who still loves good design).

Posted in Agile
One comment on “This Page Intentionally Left Blank
  1. Michael James says:

    Ken’s attempt to keep someone from muddying the waters:

    [xxxx methodologist prescribing a complex process cocktail]

    Not true, xxxx. I’ve had a lot of experience working with enterprises that manage all development using a Scrum model, from CEO down. This requires consistent engineering, integration, management, and people practices. I wrote about the techniques in an upcoming book, “The Enterprise and Scrum.” Using Scrum practices throughout the enterprise provides a uniform set of thought patterns and terminology that provide cohesion. Learning lean to provide another way of viewing the results of Scrum is tremendously helpful. However, introducing lean as another set of practices that is unbound just increases confusion.

    I expect that we’ll see more service offerings around Lean as consulting companies attempt to differentiate themselves. The thing to watch out for is whether this builds on previous efforts or adds another completely new effort.

    Ken

    –mj
    Michael James
    Software Process Mentor

Leave a Reply

Your email address will not be published. Required fields are marked *

*