I'm in Australia right now. I've been keynoting, paneling, and talking at Software Education's SDC conference. One of the participants asked the panel of speakers, "My management thinks I should be able to do the BA work and the Scrum Master work on my project. What do you think?" The other speakers were reasonable, explaining that because BAs are collaborative, they are a natural for the Scrum Master role.
I just about exploded out of my chair. "What is your management thinking? Do they want to do Scrum or do they want the project to fail? Or, maybe they want you to fail?" I ranted and raved a little more, but I'll save you from that. Here are the ideas behind my ranting and raving.
If you are new to agile and you want to do Scrum, then follow Scrum. There is a reason for the role of Scrum Master. That reason is that when you are new to agile, you need someone who advocate for the team to remove impediments at all levels of the organization, someone who can facilitate the process for the team. This person serves the team. This person, if serving the team, will spend all of their time serving their team. They will nudge the product owner into grooming the backlog. They will help people understand the acceptance criteria. They will facilitate the standup meetings and make sure those meetings occur, that the team collects the data and does not last longer than 15 minutes. That person ensures that the other problem-solving meetings occur. That person will solve problems on behalf of the team. In my experience, a new Scrum Master, for a new team spends a ton of time away from the team doing things like fighting the furniture police, fighting the network police, fighting the management police, so that the team can work. If this person also has deliverables to the team guess what? No one resolves the impediments. The team's velocity never settles into a rhythm. The team and the organization never sees the benefits of agile.
Someone says "Agile (or Scrum) doesn't work." Nope, that's not the problem. You're not doing agile or Scrum if you don't follow the directions. Don't adapt it if you don't first adopt it, lock, stock, and barrel.
When you try to play more than one role on an agile project, you are not adopting agile. You are adapting agile without understanding how to adopt it.
Multitasking on an agile project is just as bad as multitasking on any other project. You have to make it transparent. If you are asked to multitask, make it an obstacle. Show your lack of progress on the board. Consider using a kanban board inside a timebox if a number of people on the project are supposed to be multitasking. Ask your managers to start managing the project portfolio.
Because remember, it's not about the projects you start; it's about the projects you complete. It's not about the roles you take on; it's about the projects you complete. If you can successfully complete projects with multiple roles, great. That's a rare capability for rare projects.
Keep your eye on the goal: finishing projects. Then you'll know what to do about this business of multiple roles.
