This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
The ScrumMaster’s biggest headaches
We often say that the ScrumMaster‘s job is to facilitate the Team’s in its self-organization, impediment removal, and process improvement. This is a pretty simple, and simplistic, statement. What does the ScrumMaster actually worry about? What should he ScrumMaster actually worry about? Well, here’s what I think the ScrumMaster’s three biggest worries are:
First, the ScrumMaster must get good technical development skills into the Team. If the Team can’t produce Quality Code, then it’s going to have a tough time being effective. And by Quality Code I mean code that is extensible, modifiable, maintainable, and can be quickly integrated and verified with extensive unit, functional, and performance regression tests. Basically, it’s code the Team is not afraid to change… it’s code that has little or no Technical Debt.
This means that the Team must have good development, testing, and integration environments, practice strong configuration management, and (most probably) use something like the eXtreme Programming (XP) practices for actually designing and building the code. Personally, I think that Test Driven Development (TDD), relentless refactoring, and all the rest of the XP practices are brilliant stuff. In any case, the specifics of what the Team does in order to achieve Quality Code for a particular Story is captured in the Doneness Definition of either a Story’s Agreement or in the Agreement section of the Story’s Storyotype.
The ScrumMaster must do whatever it takes so that the Team is not afraid to modify its code. If there is fear of changing the code it will be a major impediment to agility. In my opinion, a Team that writes software must write Quality Code in order to call itself a functional Scrum Team.
Second, the ScrumMaster must help manage Product Ownership issues. I believe that these issues extend outside the team – it’s not just about the Team’s Product Owner. The Organization should value accountability and give people the authority they need; it is hard to imagine a Scrum team thriving in an environment that does not do so. The Organization needs to provide safety and a nurturing environment for the Team, and it is the ScrumMaster Community’s job to work with the Organization to foster this environment. As a member of this ScrumMaster community, your Team’s ScrumMaster is instrumental in having the Organization provide this safe, nurturing environment.
Within the Team, the ScrumMaster must assure that there actually is a Product Owner – a single, identifiable, Team Member who is accountable to the Business for the value of the Team’s results. There must be nobody with authority between the Product Owner and the Team – not even somebody appointed by the Product Owner – as this would make the Product Owner actually be (at best) the Business Owner. If these things aren’t true, the ScrumMaster must work with the Business Owner and others outside the Team to make sure it becomes true.
Finally, the ScrumMaster must manage the Team’s relationship with its Product Owner. This can be particularly difficult, because the Product Owner, as a person, really plays two distinct roles on the Team: The Product Owner is a Team Member, but is also the Team’s ‘single, wringable, neck.’ As the Team’s single, wringable, neck, he or she may be tempted to be bossy, to control, or micro-manage, the Team.
In fact, an argument could be made that the PO has the moral right to micro-manage the Team, as it his or her neck on the line. However, the PO has an obligation not to micro-manage, and the ScrumMaster must work closely with the PO to help maintain the proper balance in the working relationship.
The Product Owner must also respect the Team and the Team Members. For example, assume that the Product Owner is really upset at the Team – it’s not performing very well – and the PO is tempted to say some harsh words to the Team. What the PO should say is something like: ‘I know you guys are doing the best you can, but it looks like this problem has gotten the better of you. What can we do about that?’ Of course, asking the PO do be this reasonable may be an unreasonable request, and that leads to the PO and SM playing ‘good cop – bad cop’ with the Team – with the ScrumMaster being the good cop. The PO will be harsh to the Team, and the SM will have a respectful discussion with the Team about how the Team can improve.
Third, the ScrumMaster must facilitate the Team’s self-organization. This will be difficult to do if the Organization has not provided a safe environment for the Team. Therefore, I recommend that the ScrumMaster focus on Product Ownership issues until this safety is assured; and then the ScrumMaster can focus on the Team’s self-organization.
Self-organization has two aspects: the first is that the Team changes its work patterns based on the work being done, and the second is that the Team modifies its practices and procedures in order to get better at doing its work.
The first aspect of self-organization says that the Team should organize and manage itself differently based on the work that it’s doing – based on the Stories being worked on – this is also called ‘task orientation.’ The main purpose of the Daily Scrum is to provide information about how the work is progressing, which includes progress on the Product and impediments that arise. Based on the state of the work, and what the Stories need, the Team will rearrange itself to optimize its efforts for the day. One common pattern is for the Team to Swarm on the work that is available. Additionally, the Team (often assisted by the ScrumMaster) will remove or work around the impediments that are obstructing the work in progress.
The second form of self-organization is longer-lasting, and normally happens though the use of retrospectives and intraspectives. This process consists of the Team Members modifying their practices and procedures in order to get better at what they do, while conforming to whatever constraints the Organization has placed on them. To put it simply, the Team must adapt to Organizational realities and constraints without compromising its ‘scrummish’ personality.
There are many other specific things the ScrumMaster needs to worry about, but these are my big three. If your ScrumMaster is actively working on these three things, the Team will do well.
Note: This blog is an adaptation of information in Dan’s new book, ” Exploring Scrum: the Fundamentals” that will be out in a few months.