Non-Developers on a Scrum Team

I received another e-mail this week on a different topic in Scrum. How do you incorporate some of the traditional non-developer roles into a Scrum team? For example, your Business Analysts?

From: MN
Sent: Tuesday, February 26, 2008 7:26 AM
To: Santiago, John
Subject: Question about SCRUM

How do you handle non-development activities assigned to business analysts in SCRUM?

During our product backlog planning, we identified two non-development activities that we assigned to business analysts. The business analysts have told me that they would prefer to have these tasks managed outside the iteration backlog because they're not development activities.

What do you think?

MN

My response:

The team correctly identified one of the challenges you can run into with Scrum when you introduce non-development staff. Your BA’s are not directly contributing to the current Sprint (they are thinking ahead for future Sprints) and so they don’t really belong on this Sprint’s backlog. Intuitively we know that they are a part of the team, so what to do? Here are a couple of ideas / workarounds:

1) Remove your BA’s from this Product Backlog and all future Sprints altogether. Create a separate backlog just for them and have them organize into Sprints. They are Developers, but they are Developing requirements documents instead of software. This might be a good team for 1 week Sprints since they don’t have builds and such, plus BA’s sometimes need a little extra drive so they don’t get caught in the weeds. The downside here is that they become somewhat disconnected from the rest of the team.

2) Another option is to keep the BA’s work items on your Product Backlog and your current Sprint, but don’t count their hours in any of the Burndowns since they aren’t directly contributing development time to “potentially shippable product.” This keeps them in your status meetings, and you can still check their progress with the rest of the team.

Since Scrum is all about “self-directing teams,” you might take 15 minutes for a team discussion where you lay out the challenges, posit these two solutions, solicit other ideas and have a team vote as to the best idea to try. Your team might have some really good thoughts.

Question About Scrum Velocity

A peer of mine is working on a major software development effort. He is a Software Architect in the role of "ScrumMaster" and is just learning the ropes of Scrum. He works for a very major consulting organization. He sent me this e-mail (excerpt):

From: MN
Sent: Monday, February 25, 2008 8:21 AM
To: Santiago, John
Subject: Question about SCRUM velocity

We've been measuring velocity for three days and, as you suggested, the numbers are relatively low. They are heading in the right direction. Now that we're moving, do you think velocity will improve naturally or do you think I should be doing things to encourage increased performance? If so, what sorts of things might help? The team isn't reporting much in the way of barriers; its more like we underestimated things.

MN

After reviewing his backlog, I had some suggestions about individual challenges some folks might be having, and I also suggested that he check out this great post about Sprint Retrospectives so that he can examine in more detail the Sprint with his team:

http://pragmaticintegration.blogspot.com/2007/01/first-scrum-sprint-retrospective.html

He responded back with the following:

I'm not stuck but vastly underestimated the amount of work. I thought my estimate was pessimistic when I originally made it. Sometimes when you turn over a rock, you find something you wish you hadn't found. As far as I can tell, it absolutely needed to be dealt with and I can't think of a good way to cut the work short.

I think that acknowledgment is critical to understanding how Scrum operates so I sent him the following e-mail:

From: Santiago, John [mailto:John.Santiago@emc.com]
Sent: Wednesday, February 27, 2008 10:52 AM
To: MN
Subject: RE: Question about SCRUM velocity

“There are known knowns. These are things we know that we know.

There are known unknowns. That is to say, there are things we know we don't know. But, there are also unknown unknowns. These are things we don't know we don't know.”

-- Donald Rumsfeld, befuddling the press at a Pentagon briefing

A huge part of software development is learning to recognize what you don’t know. What you will find is that your velocity will tend to account for this over the course of the project… allowing you to fairly accurately predict the impact of the unknown. Assuming that there aren’t monumental roadblocks in your way of course, which is why project managers still need to actively do aggressive risk identification and management even in a Scrum environment to steer around potential roadblocks.

What you must be doing right now to maximize your team’s velocity is to be very aggressive about removing any gold-plating from the project and to make sure the team is focused only on the minimum functionality needed to go-live.