My Brother-in-Law Says Scrum Doesn't Work

The question inevitably comes up at my internal, or more often, at my public Scrum classes. "Does this really work? My brother-in-law worked over that Barf-o Software, and it was all messed up over there."

Deciding whether Scrum, or any other agile methodology, really works based solely or your or someone else's personal experience is anecdotal. It's the person who doesn't want kids because his brother's kids are out-of-control mini monsters, or doesn't like wiener dogs because one bit him when he was seven. For me, it was football. I didn't play because my brother said the coaches were mean to him when he was in 7th grade. I finally tried out my senior year and loved it. And the coaches weren't mean to me. Well, not very. I did have to run extra laps for talking to David Stewart when coach was talking to us.

Scrum works (better in some in contexts than others), but when it's going poorly, it's often because of 1) people doing Scrum wrong, 2) bad company culture, or 3) difficult team and project structure.

I've seen ScrumMasters (the role that should know Scrum the best, and therefore educating others) let the daily 15 minute Scrum go over 45 minutes, do planning poker estimating for each person's task for every story in the sprint, post a formula that showed the ratio of story points to developer and QA (it was 1 and .5, just so we all finally have the answer to that secret recipe), tell the team what their tasks would be, make every decision, lie to the team (FYI - that's bad), and more. Of course, this has an impact on the team. They don't do as well as the could, maybe even poorly. But that doesn't mean Scrum doesn't work. It means the ScrumMaster isn't doing it right. And worse, the team isn't owning the principle of continuous improve to work through these, and other, issues and get past them.

Secondly, bad company culture will make Scrum, and any other process, go poorly. Management that sets unrealistic deadlines on a project with fixed scope without asking the team for estimates will be bad for the team whether they do Scrum or traditional waterfall (although it won't be as bad with Scrum because at least you can tell management within two weeks that it looks like it's not all going to get done when they asked for it). Project managers who let every new change or request pass right through to the team without asking good questions or request priority or feature trade-offs when new, valid  needs are discovered will cause problems on any type of project. Some company cultures simply don't value the project teams, but hold to Theory X and see them solely as resources who need the whip cracked in order to get results. These executives will try Scrum because they hear it will get more results faster. But when they find out that these improvements (and others) come in part through self-organized and self-managing teams (who expect to be supported and empowered), senior management won't let go and trust, but instead tries to implement the Scrum practices without the Scrum and agile values. The results are predictably bad (and the teams upset, too boot).

Last, Scrum works best with cross-functional teams of people sitting together, and preferably kept together long term and fed different project. Once, a ScrumMaster was saying he felt his team wasn't gelling and collaborating well together. It turned out that every one of his team members lived in a different country. In Scrum, we work better and more efficiently in part because we move away from our functional team silos and heavier-than-needed process and towards individuals and interactions (just simply talking to each other more in order to solve problems and get stuff done). If you don't have that, it won't work as well. And that's not Scrum, that's your organizational structure. I've seem team members on a team matrixed on 17 different projects. How effective can you be, really, with 10% of your time on a given project? On paper, with some resourcing tool splitting everyone's time up, the math deceptively looks good. But in reality, ramping up and down daily on different projects and activities thrashes productivity. That's not a Scrum problem, that's someone somewhere not wanting to prioritize and say, "Really, these three initiatives are the most important. The other 14 will have to wait."

These, and other, challenges are some of the problems covered in the Certified ScrumMaster class. Scrum doesn't solve these people or culture problems for you. It simply makes the problems you have clear, and gives you great tools to show, if you change, how good things can be right away.

Should the ScrumMaster be Telling the Team How to Do our Work?

In a word, no. The Scrum Master is a servant to the team, not managing the team or their tasks. The Scrum Master should facilitate the team meetings, not tell people what to do. The Scrum Master should encourage and empower the team to solve their problems themselves, not inflicting their help by solving all real and perceived problems. The Scrum Master is the shepherd and guardian of the process - more of an evangelist and trustee than the Scrum Police or Scrum Boss.

The more the Scrum Master can back away from making sure work gets done, control things so that there are no problems or failures, or coordinate all the orchestration details of how things get done, the more the team can step in, step up and own the execution and delivery. One linchpin seems to be allowing the team to fail - giving them the freedom in a safe-to-fail environment (culturally and the framework of short sprints of small, shared stories), and trusting them to learn from it and get better.

In the end, no matter how smart and hard working one person is, nothing beats the power and smarts of a committed team working together and focused on a clear, shared goal.

Who Should Be the ScrumMaster?

Who should be or become the ScrumMaster for your new team? That is, which role: project manager, lead developer, functional manager, or anyone but one of these roles?

Although, understandably, most management wants a standard answer for who they should select to be the ScrumMaster in this new work paradigm, there is not a one-size-fits-all answer. And the reason is because it depends on the person, the team and the environment.

Before I walk through some of the roles, I think it's a good question to ask "Who is deciding who becomes ScrumMaster?" I see management decide often times, but they make the decision without knowing what Scrum is and, more importantly, how it works. The decision on who the ScrumMaster will be does not need to be made months, or even weeks, in advance. I've seen teams decide hours before their sprint begins. If at all possible, take this important decision to the team to see what they think. There needs to be prudence in this, certainly, but I'd rather lean towards making this statement of empowerment and trust of the team from the very start of adopting Scrum.

I commonly see Project Managers given the role of ScrumMaster, but there's a trade-off. What makes a great project manager may not make a great ScrumMaster. In fact, it might be counter. Often, management wants project managers who "get things done." That is, they drive performance. They push the team. They may even micro-manage for results and visibility by tracking every task, status, risk, change and deviation from the plan. And management might love this (or, more truthfully perhaps, love the results). On the other hand, I've also seen Project Managers who provide management what they want (helping get more productivity and more visibility to progress, issues and options) by serving, empowering and trusting the team. If you are currently a Project Manager, which type are you? My experience has been about 50% of project managers are on each side, with very few changing. For some, their "driver" approach impacted the team so badly that management was considering removing the person from the team.

I've seen managers also take on the ScrumMaster role. This, more often then project managers, has negative consequences, only the consequences are not so obvious, but these can be corrected more often and more easily than I've seen with project managers. Some managers, due to their company's culture and expectations, carry the responsibility of getting results from their people (for the projects their people are on). Along with this, many more are expected to make sure their direct reports are busy (that management is getting their money's worth from the employees). For these managers, even if they wanted to embrace the transformative qualities of the ScrumMaster, the company culture will push back, and most often win. For managers in these tough positions, I'd rather see them find someone else to be the ScrumMaster, and then the manager can focus more time and energy towards the bigger need of being a heat shield, organizational impediment remover and management mindset and company cultural change agent. Truthfully, that is the great need and value immediately and long term. For those managers not in culture or carrying those "busyness" mandates, and who have the right attitude towards their role and their team, I have seen great things happen. For these managers, this new role in the business and IT world of ScrumMaster opens new pathways to work with their team, provides new tools to let their people learn and grow, and fosters collaboration between their people. In many ways, this is what these managers were looking for in terms of moving away from needing to make sure things got done (which now the team commits to and owns getting things done), and wanting to focus on growing their people. For those managers wanting some book recommendations specifically for this new "Agile Manager" aspect of their work, take a look at my Agile Management and Leadership book list on Amazon.

My preferred option for whom should be the ScrumMaster is to look to those who are individual contributors (developer, lead developer, business analyst, QA). Ideally, the ScrumMaster is a fulltime role, which has the downside of giving up a fulltime employee. Again, this is contextual. The ScrumMaster will certainly need to be fulltime if the team (and/or company) is starting with agile, or if the project or product that the team is working on is fraught with challenges outside the scope of the basic context taught in my Certified ScrumMaster classes of a "single, co-located, cross-functional team." That is, if there are challenges of having multiple Scrum teams, or using offshore or remote team members, or a larger team, than the need of a ScrumMaster's time and help will be greater. On the other side of the scale, in a simple context, supportive environment, and/or experience ScrumMaster, I've seen the ScrumMaster still do 50% of his or her time doing development (or other tasks) as a player and coach. The biggest trade-off there is that the ScrumMaster needs to know their personal limits on commitment to tasks and stories they take on, as well as balancing personal and team focus. Not easy. 

I'll end with my favorite stories that illustrates what I'm really after when thinking of who should be the ScrumMaster on team. First, I was at a company that was deciding how much to grow their agile adoption. They had one team doing Scrum for six months with great results and a second team had just finished their fourth two-week iteration and was also doing well. The conversation among the executives came to a seemingly trivial point of who the ScrumMaster happened to be on the six month team. When a manager informed the executives that the ScrumMaster also happend to be the most junior developer on the team, there was unanimous appreciation and excitement about how this was exactly what the company wanted for it's culture - that anyone could make very significant contributions! 

My second story is from when I was working with a team that had a working agreement that included rotating the ScrumMaster every two months or so. After finishing their second rotation, at the meeting to decide whom would be next, the team unanimously, and quite noisily, voted to keep their current ScrumMaster. Forever. They loved her and how she helped them. She had grown to love the role and the team as well. And this was a person who was had a fair bit of self-doubt about even trying out the ScrumMaster role the first time, only agreeing to do it because of the guarantee of the ending (surely in failure, she assumed). 

It's stories like these that show how Scrum can help individuals, teams and companies thrive.

Scott recently posted an updated version of this post on the Rocket Nine Solutions blog: http://rocketninesolutions.com/implementing-the-scrummaster/

He also posted a companion piece: Who Should Be the Product Owner, http://rocketninesolutions.com/who-should-be-the-product-owner/

And you can find a video about it on http://rocketninesolutions.com/ as well.
http://youtu.be/4hqywLT0mWM

Common Scrum Questions

I recently did an agile overview for a company's IT group, and was again surprised by the number of questions that could be answered by someone attending a Certified ScrumMaster class and, living out the role as educator, lets the team and others know how and why Scrum works. I'll go through the more common questions on my blog over the next few weeks.

Here's a few questions I see commonly.

1. Who should be or become a ScrumMaster? That is, which role: project manager, lead developer, functional manager, anyone but one of these roles?

2. Should the ScrumMaster be telling us how to do our work?

3. Does Scrum really work? I had a friend that worked over that Company X, and it was all messed up over there.

4. What's the right way to do Scrum? I worked at Company Y where they did Scrum, and my friend at Company Z does it a different way.

5. What about budget?

6. Our teams are distributed and remote. Can Scrum work for us?

7. How long until we start to see improvement?

8. Should we still have project managers and a PMO (project management office)?

9. I'm in QA, and this Scrum stuff stinks for me. I'd rather have it the old waterfall way.

10. Do we still need to do requirements in agile?

11. We don't have a Product Owner, but we know what needs to be done. Can we still do Scrum?

12. Management says we still have to hit deadlines that were set 15 years ago. Isn't that not really agile?

13. Is the ScrumMaster a fulltime role? What about what I used to do?

14. What if some of our work is dependent on people in other departments, like Operations (and they don't care that we're in two week sprints!)?

15. What if there are dependencies on other Scrum teams, and our commitment is dependent on them getting their stories done?

16. How do we do good architecture without doing some sort of good (or good enough) design upfront?

17. What do we do if our stories aren't complete at the end of our sprint?

I'll answer these, and more, over the next few weeks.