How to Screw Up Your Scrum
When it’s done right, a scrum-based environment can turn a stagnant, slow-producing development process into an iterative wonder. Unlike waterfall or XP that is linear and more like a relay race, scrum depends on team dynamics as well as individual commitment.
Effective software development is more about the team and its commitment to the process and not the framework being adopted. You can have the best scrum implementation plan in place and it won’t do you any good if the teams and individuals involved choose not to follow the rules or constantly challenge the process. Adoption of a process meant to improve and drive development in an iterative way can be challenging; but the end result is that all involved and committed parties work together and produce a high quality product.
However, scrum is not an easy framework to work with, especially when your team is used to the traditional software development process. Development teams that are new to scrum can derail their process without realizing it. The following are the most common and insidious ways to screw up your scrum.
Let Someone with Little Management Experience Act as the Scrum Master
Great scrum mastery requires experience working with development teams in general. You can’t fake that or attempt to learn it on the job. An inexperienced scrum master can demotivate and derail a project unintentionally just because he doesn’t have the background to guide the team.
The scrum master doesn’t have to be a technical genius but should be someone who understands which roles need to be filled (Business Analyst, UX, Developer) and how to find help for any impediments team members may encounter. Effective scrum masters act as both servants and leaders. Their job is to do everything in their power to make sure that the project moves forward. They need to motivate, inspire, and help the individually committed team member deal with any impediments to completing their tasks. The scrum master is not there to tell the team how to do their jobs, but to help them with whatever the team members need to make sure the job gets done.
Either scrum or don't scrum. Don't scrum haphazardly.
Originally designed for small teams, the agile nature of scrum lulls people into thinking it’s acceptable to skip a process here or there. One reason that scrum adoption succumbs to inconsistency is that newly minted teams tend to jump in with both feet and expect all the elements to be perfectly executed from day one.
Perfectionism works against agility. Even if you don’t feel like “scrum” is being done exactly right, continuing to push through the process builds confidence across the team. Attending daily stand ups and weekly sprint planning and retrospectives should not be negotiable. Attendance and engagement is most important for consistency.
My friend Laura Klemme is a certified ScrumMaster. Her biggest issues with guiding scrum teams is that Product Owners are so busy they don’t really iterate across sprints as they should. Once a sprint is completed, the Product Owner should bring the results back to the stakeholders for feedback; then that feedback is rolled into the next sprint. However, she found, in most cases the Product Owner (a user representative) meets with the stakeholders/users at the beginning of the project but does not go back to them again until the project is done. This introduces the possibility of dissatisfaction with the end result because no one confirmed that the features being built are what the end user asked for in the first place. One way to relieve an overtaxed Product Owner, she suggests, is bringing on a UX manager who can coordinate the product backlog (or have the coordination included as part of the sprint).
Skip Daily Stand Up Meetings (or Sit During a Stand Up)
It's a sinister thing; you don't realize that you are skipping meetings until it's too late. That’s especially true for those of us who tend to be self-directed. We put our head down and dig into a code base; the next time we look up it's hours later.
If you have the usual 5-7 member scrum team then a daily 15 minute standup meeting should become second nature. What did you do yesterday? What are you doing today? And what, if any, impediments got in the way? It may seem like this is of no intrinsic value and get easily bypassed but this daily round of questions can make the difference between successfully meeting sprint guidelines and having to explain why you didn’t get things done during the retrospective.
The daily stand up provides a number of things, beginning with the positive “yay team” of acknowledging we are in fact going in the right direction. But it’s even more important to respond to changes and problems. Because of the iterative nature of scrum a simple statement from a stakeholder can change the requirements in a heartbeat. If you don't stop to take stock in where you are and what has been accomplished, on a daily basis, time and money could be wasted on unwanted or unnecessary features.
Sadly I’ve been in stand ups that looked just like this parody:
Establish Sprints with No Clear End Goals
“What is not started today is never finished tomorrow.” -- Johan Wolfgang von Goethe
Determining what can get done during a sprint takes a lot of experimentation. You’ll overestimate and underestimate on a regular basis until your team recognizes how long it takes to get things done. It’s better to set a goal and not quite reach it then to not set a goal at all.
What is considered done? That’s the first thing you need to decide on as a team. Is “done” releasable code? Is it code that’s gone through testing? Whether you strive to complete an entire story or certain tasks within that story, know what your deliverable will be at the end of the sprint. The sense of accomplishment will encourage you and your team to take on a bit more (or reduce your work load!) depending on results. You must establish that goal each and every time or you’ll find yourself unable to track whether progress is being made. Lack of progress ultimately leads to frustration and indecision.
Rule with an Iron Hand
With scrum – and any Agile process – you want your team to work in a quick iterative manner, but you have to give the team members the room to work within their own comfort zone. As scrum master you are not really "in charge" of your project in the traditional sense, as decisions are made by the team. Unfortunately, this introduces issues with unproductiveness and failure because there is no clear direction.
The other end of the spectrum is running the project so tightly it frustrates the team and they stop producing. “Management will end run the Scrum process by asking for special work to be done by individuals on the team,” says Laura Klemme. “This is 'unplanned' work and is off the board. Totally disruptive. But, management has the mentality that the higher ups don't need to follow the process; they can ask for things and everyone will jump for them. Most of the time, the work was known about in advance but the management just didn't ask for it when the sprint backlog was being created.” The bottom line is that management can be the worst offender for a team trying to stick to a scrum process, she says, since managers are used to managing by demand.
Scrum, when implemented correctly, feels good, not painful or an exercise in drudgery. If the process feels wrong than it probably is being done wrong.
All hope is not lost even if you do fall into a pattern that is leading the team to a methodological implosion. The immediate solution is to gather your team and determine if any of the aforementioned issues are throwing a wrench into your progress. If they are, then step back and evaluate how to fix it. Fix it as a team, and you’ll encourage ownership of the scrum implementation by everyone involved.