By Angela Druckman
When introducing the concept of Scrum to an organization for the first time, I try to give a reasonably unbiased view of what to expect. I warn the new Product Owner that at first he may feel overwhelmed and struggle to articulate requirements in a clear and actionable fashion. I tell the new ScrumMaster that the innocuous duty assignment “ensure everyone follows the Scrum process” may make her wildly unpopular for a while. I also like to be clear with everyone which problems I think Scrum can fix—and which it cannot.
The Scrum framework brings a structure to projects that can right many wrongs, but it is not a silver bullet, and it certainly won’t make all problems disappear.
First, let’s look at three of the most challenging problems Scrum can not fix:
Endemic Organizational Problems
If you have long-standing organizational problems—passive aggressive behavior, people who are masters of “working around” the system, team members who don’t like or respect each other—Scrum will not fix this. On the contrary, Scrum will bring these tensions to the surface right away, probably in the first Sprint. I have had developers storm out of Sprint planning sessions, holding spirited shouting matches and just generally exude hostility at each other and at me.
And you know what? This is a good thing. It’s not like Scrum created these problems. Far from it, they were there festering under the surface, interfering with productivity all along. And while those are problems Scrum can’t solve, it does bring these issues to the light of day, where people can deal with them in a rational and actionable manner.
While resolution doesn’t happen over night, it usually comes about fairly quickly. However, as ScrumMaster, you should prepare your team and your management that some feathers are likely to be ruffled in the beginning.
Unwilling Team Members
Rest assured, if your team says to you as ScrumMaste,r “We think this Scrum thing is a stupid fad and we’re going to do everything we can to make it fail,” your Scrum project most certainly will fail. You need team members who are willing to give Scrum an honest try. I personally would take a team of enthusiastic newbies any day over seasoned veterans who won’t make an honest effort. Healthy skepticism is fine, but setting out to “prove” Scrum doesn’t work is a bit like the person who starts a diet but never manages to change his eating or exercise habits and then claims he “can’t lose weight.”
Along the same lines are the team members who fundamentally do not have an interest in improvement of any kind. Most of us have bumped into these souls at one time or another: maybe they are a year or two away from retirement, maybe the highlight of their job is a short commute and the actual work itself ranks a distant second. For whatever reason, they are very happy with the status quo, thank you very much, and do not need Scrum upsetting the boat. Trying to prod these people into action is like trying to get a turtle to gallop. Your time would be much better spent selecting a different team member who has the desire to learn and grow.
The Disengaged Product Owner
Finally, a true kiss of death for Scrum projects is the disengaged Product Owner. The reasons for this disinterest may vary. Maybe the Product Owner is too high up the food chain, such as a division head. These individuals have too many demands on their time already. Additionally, they are usually broad thinkers and used to delegating detailed work—not the person you want outlining the specifics of a Product Backlog. Perhaps the product owner is just not available on a regular basis. A Product Owner that you, as ScrumMaster, can’t get regular audience with is also going to have a hard time being successful. If you are building sales software, a sales executive that is out of the office twenty days a month is not going to make an ideal Product Owner. Choosing the right product owner is something only the team can fix. Scrum can’t fix it for you.
A good Product Owner has a vested interest in getting the Product Backlog right. They can tell you, in their own words, why the first item on the list is more important than, say, the fifth item. They worry about getting the backlog right—they don’t want to misstate the requirements and make their boss, their employees, and everyone in the division mad. In short, they have skin in the game. For this reason, in larger organizations, middle managers make great Product Owners. Their behavior is motivated by a high “pain factor” (life will be very unpleasant if they get the backlog wrong), so they have a vested interest in spending the time and effort to get it right
These are just a few of the most vexing issues Scrum itself cannot directly solve. You may be thinking “But wait – my organization has all those problems! What I can do about it?” Use the Sprint Retrospectives to lay it on the line: if you have team tensions, deal with it. If it appears the wrong person has been selected as Product Owner, state that you think this is true. In these cases, Scrum is best used as a means to facilitate an end: it may not solve all your problems but it can make them appear big and painful enough that everyone will agree they need some immediate attention.
What Scrum Can Fix
So if there are so many endemic problems Scrum can’t make go away, what problems will it help? This is a reasonable question and one I get from developers, business sponsors, and management all the time. Their basic question is: “This is going to take a considerable investment of time and effort to implement – what can I expect to get in return?”
There are a myriad of problems, small and large, that Scrum seems to clear almost magically. Here are a few that can yield wonderful results in a short amount of time.
Poorly Thought Out Requirements
A good business analyst is both a blessing and a curse. She is a blessing because she knows the finer points of business process and when to dig into details and get customers to think through their requests. But when a BA is too good, the customers may grow lazy. Their attitude becomes “Oh, you know what I need” and they no longer think carefully through their requirements or their prioritization.
Cut to a new Product Owner’s first experience at creating a Product Backlog. There’s no more semi-psychic BA to intuit his every need; he actually has to articulate what he is expecting. Saying, “The Add New Account screen is hard to use,” doesn’t cut it anymore. Why is the screen hard to use? What would make it easier to use? How would those changes affect downstream business processes? These are important questions for a Product Owner to think through. While I certainly don’t expect Product Owners to state requirements at the level a BA might and a BA may still be involved, I do expect them to be very clear on what they are asking for. Having this expectation vastly reduces the number of unpleasant surprises downstream.
Role Bleeding
Role bleeding is my affectionate term for what happens when a coworker doesn’t find her own job engaging or interesting enough so she decides she would like to help you do yours. These individuals end up assuming, or trying to assume, responsibility for decisions which they have neither the authority nor knowledge to make. This may take the form of business owners giving detailed “advice” about middleware tools. Or developers who change business requirements because they “know what the customer really wants.” In my pre-Scrum days, I once had a graphic artist responsible for website content maintenance who occupied long sections of meetings wanting detailed descriptions of server layouts.
Scrum puts all that to bed pretty much right from the start. The ground rules are clear: Product Owner, you are responsible for the backlog, the “what.” The team is responsible for the “how much” and the “how.” The ScrumMaster is responsible for keeping the whole process humming along, removing impediments and non-Scrum behaviors. And no one else has any in-Sprint role. Period.
Lack of Accountability
If you haven’t time-boxed projects before, as a first-time ScrumMaster you are going to be in for a breath of fresh air. So many project methodologies from the 1990s focused on scheduling to deliverables. We managed projects so as to complete “all” the requirements (though what exactly “all” meant had a strange way of flexing over time). As a result, schedule remained somewhat divorced from the project plan and its tasks. How each team member’s daily activities were contributing to a given feature being completed was something of a mystery. Not only that but, with an understanding that requirements were more important than schedule, developers often could not resist the urge to “gild the lily,” adding little features and extras that were never part of the original work statement in an effort to wow the customer and make up for all the delays.
For such team members, Scrum can be a wake-up call. It might take a while for it to sink in that the Sprint backlog represents a commitment but, once it does, I guarantee you will see a difference in attitude and actions. There is almost always an “Oh no!” moment when they realize 1) the Sprint is ending in 3 days 2) the demo with the customer is already scheduled and confirmed and 3) there is still have a heck of a lot of work they said they could complete that is undone. My experience is that teams improve their ability to estimate very quickly with Scrum—they want to avoid that “Oh no!” moment and the stress it brings more than you can imagine. There is no more time for gold-plating activities. Each team member needs to be able to come into the Daily Scrum and explain what they are working on and which backlog item that work is fulfilling. If you are hearing, “Well I worked on Activity X but I don’t know which backlog item it ‘goes with,’” you know you have some coaching to do.
The effect of this heightened sense of commitment is that you create a high-performing team that can quickly become a force of nature. Within just a few Sprints they are like a well-oiled machine: they estimate well, they develop efficiently, and they appreciate and trust each other. In essence, Scrum removes the “static” of project management such that the talent and experience that was there all the time can shine its brightest. I can’t fathom why, once experiencing this, anyone would want to work any other way.
If you are currently trying to “sell” Scrum to your organization, or to a client organization, I think it is important to give decision-makers a balanced view of the benefits of Scrum and a good idea of the fallout likely to come from implementation. I believe this balanced approach gives your pitch credibility, and will go a long way toward pre-empting overreactions when problems arise. At the end of the day, Scrum is about building high performing teams. And, as with all success stories, it is the good and the bad that shapes the final result.
