Software Development is a Team Sport! : Teams

Agile Prioritization

aridle — Sat, 28 Apr 2007 04:26:00 GMT

Joel Spolsky and Dmitri Zimine mixed it up last November over whether or not to interrupt a team in the middle of an iteration. I'm pretty late to this thread. But, I think I have something to add. So, here goes...

Dmitri started the thread by arguing on behalf of never interrupting an iteration once it starts. Basically, he's just parroting the party line from the Scrum doctrine: Management is not allowed to interfere with the operation of a team during a sprint. If they do, the team can cancel the sprint.

Joel countered that you should consider the nature of the interruption before blindly preventing it. He argues in his inimitable way that the financial independence of the individuals involved could very well be at stake. He may as well have been yelling: "Take door number 3!"

What both guys missed is that they are arguing the opposing sides of a pendulum, and that the real truth probably lies somewhere in the middle. (Ironic considering the tagline on Dmitri's blog.)

Here's my advice when faced with the decision of whether or not to accept new work after an iteration has started:

Take five minutes to estimate the newly requested work.
Communicate this estimate to the person who requested the change in scope.
Explain the concept of velocity (if necessary).
Ask them to stack rank the new work into the remaining backlog of unfinished work for the current iteration.

There, now. Everyone has visibility into the process. And, the person in the best position to make the call as to priorities - the one who knows both the benefits and (now) the costs of swapping in new work - is the one responsible for making the decision. That's what I call Agile Prioritization.

For further study, I recommend that Dmitri and Joel (and everyone else) read Mike Cohn's excellent book: Agile Estimating and Planning.

Capacity vs. Velocity

aridle — Wed, 04 Apr 2007 02:11:00 GMT

My team just completed a discussion - at times a rather passionate discussion - about what work items we should be tracking in TFS. Sanjeev, our PM, argued in favor of tracking everything we do - except meetings. I, lead dev and agile purist that I am, argued in favor of only tracking those work items that directly contributed functionality to the software we are building. But, ultimately, we decided to track both. Here's why:

The argument for tracking everything is that unless we track all activity, we might miss some task that we are required to do. For example, the development process used in Developer Division at Microsoft requires us to pass several "quality gates" (such as a security review) before we integrate our work into the central repository. This work must be done, in order to satisfy the process. And, there are several different tasks that fall out of this work. Tracking them all makes sure we don't miss any required steps.

The argument for tracking only those things that directly contribute to the software is that by tracking everything, we will not be able to accurately predict when we will be done with our backlog. Non-backlog items would be given equal weight to backlog items. So, it would be impossible to set priorities. And, it would be impossible to accurately predict when we will be "done" with our backlog.

Needless to say, both Sanjeev and I felt strongly about our positions. (We had to break out the "talking stick" in order to keep from talking over each other.) But, ultimately, we decided that we were both right. So, we're going to track everything (capacity) and flag those items that directly contribute to reducing the backlog (velocity).

Our hope is that this will give us meaningful information about the taxes our development process imposes on us, as well as a way of prioritizing work that directly relates to reducing the backlog. Once we have both numbers, we will begin trying to squeeze as much velocity into our capacity as possible. Ultimately, I would like to see a burn-down chart that looks something like this:

Where:

Total Work = All work, including features & overhead
Feature Work = All feature work (sans overhead)
Overhead Work = All non-feature work, including "infrastructure" or "process" imposed work items that do not directly contribute functionality to the resulting software.

Calling attention to the overhead (as this chart does) allows the team (and their managers) to think about how much more productive they could be without it. Some of it will be out of the team's control - like the "quality gates" here at Microsoft. But, other bits of it will be within the team's control - like sending everyone to group status meetings when a single representative might suffice.

In other words, the three trend lines could be restated as:

Projected Total = This is when we think we will finish everything.
Projected Feature = This is when we think we will finish the features.
Projected Feature without Overhead = This is the soonest we could possibly finish the backlog, assuming all overhead items were to disappear.

So, in the example chart, the team in question expects to be done in iteration 14. They also believe that they will be finished with their feature work in iteration 12. And, if they were to drop everything but the feature work, the soonest they could finish would be iteration 9. So, the overhead is costing this team a full 5 iterations!

Ultimately, what we hope to accomplish with this data is to understand what our overhead looks like, and what impact it is having on our ability to deliver. We hope this will be incredibly useful feedback to the process about the process.

Now, how do I get TFS to produce this chart?!?! Where did I put that book on on MDX?

Buckshot Brainstorming

aridle — Sun, 25 Mar 2007 09:52:00 GMT

When my team is stuck, I like to break the log jam with a bit of brainstorming. I've had good luck with this well known technique. Maybe you will, too. I call the technique "Buckshot Brainstorming." Here's how it works:

Get the team together

Pick a time and place where the team can concentrate uninterrupted on the task at hand. Invite people to check their laptops at the door. And, set the tone by welcoming everyone and explaining the goal of the session - to come up with as many ideas as possible.

Give everyone a pad of sticky notes and a pen

Individuals will use the sticky notes to capture ideas - one idea per sticky. If you can, give people brand new pads. This tells them that you expect lots of ideas. Tearing pads in half or quarters can work. But, make sure that there are an adequate number of stickies in the room. Running out of stickies sends a subtle message to the team that you aren't willing to listen to all of their ideas.

Brainstorm as individuals

Take a few minutes to jot down as many ideas as possible. Time box this effort to somewhere between five and ten minutes to keep people focused. Discourage talking, as conversation distracts others and could potentially filter out ideas. Encourage a little friendly competition to see who comes up with the most ideas (or the most unique ideas).

Group the stickies by author

Once time is up, reconvene the group and ask everyone to place their stickies on the wall. Invariably, people will place their stickies in small groups. It looks like someone shot up the wall with a giant sticky shotgun. Thus the name "Buckshot Brainstorming."

Brainstorm as a team

Now comes the fun part! Take turns presenting your stickies to the team. As you take one of your stickies off the wall and read it, explain what you meant to the team. Encourage people to ask questions to make sure they understand the idea. Often, reading one of your ideas will trigger another idea for someone else. When this happens, capture the new idea and add it to the And, allow people to add stickies to the wall throughout the meeting.

Group the stickies by category

As team members read their ideas, some will be duplicates and some will be closely related. Place similar or related ideas into groups on a different wall. Name the categories as you go. These names represent the high level concepts people were trying to communicate. The more stickies there are in a category, the more people were thinking about it. This may indicate the importance of one area, or the need for additional thought in other areas.

Give it your own twist

I recently participated in just such a brainstorming session with a team of about 12 people. We were trying to come up with things we would like to see in Visual Studio Team System that required collaboration with other teams.

The conditions were not ideal. Some people came late. Others had to leave early. But, in about 2 hours, we brainstormed, discussed and categorized about 100 ideas.

The categories we came up with at first were things like "process," "development," "test," etc. But, once we were done, we decided to matrix the ideas into three more categories - things we could do without another team, things another team could do without us, and things that required cross-group collaboration.

In the end, we produced about 15 high quality ideas that required cross-group collaboration, which was the point of the exercise. Further, these ideas were also categorized by the area of Visual Studio with which we would need to collaborate. So, the matrix of categories worked great for us.

Once we finished placing ideas into our matrix, we voted on the items in the collaboration category. Up until that point, all ideas were considered equal. After that, though, we had exactly what we wanted - a stack ranked list of opportunities for collaboration.

Why I like this approach

The best thing about this approach is that it is so inclusive. Everyone gets to share their ideas. And, no one is allowed to critique an idea. Malformed or wacky ideas may actually trigger a really good one for someone else. So, everything gets equal time.

In fact, right up until the end of the process, some pretty strange ideas were on our list. Eventually, they either didn't involve collaboration (removing them from the list entirely), or they didn't receive any votes (placing them at the bottom of our stack-ranked list right where they belonged). Even so, the authors of these particularly original ideas felt great about the fact that they had been included in the process. And, as such, they'll be more willing to work on the ideas that ended up higher on the list. That's what I call a win-win.

Drop me a line

If you are already using this technique, or you give it a try for the first time, drop me a line to let me know how it works for you...

I wish you luck. And, may all your ideas make the cut!