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
Software Process Mentor