How can a team working on research based items work in an Agile project?

Question

My R&D organization is following an Agile (Scrum) development methodology. One of the development teams is working mostly on items that are really problematic in terms of the certainty during the sprint planning. It means they mostly deal with performance issues that need to be researched and resolved.

This team is expected to work in collaboration with the other teams, while following the Agile methodology. The manager of the team finds it hard since during sprint planning there is very low certainty around his team's tasks. Moreover, during the sprint, hot issues arise and require the team's prompt response.

What would be a proper way for this team to work in this context? How should they plan their work? Should they allocate buckets of time for the unexpected issues? Should they split their work to research and resolution parts and plan for them separately? Any other ideas?

Answer 1

First, Agile is a good fit to research projects because of the amount of uncertainty and the potential of requirements to change.

Agile is more like a set of guidelines than a rigorous methodology full of rules. Custom-fit it to your project and process tolerance. I would suggest you adopt the following practices (some of which you mentioned already):

• Tackle the most uncertain items first.
• Tackle the riskiest items first.
• Don't pick up tasks mid-sprint; sprints are short enough that you can "wait" for the 1-2 weeks remaining to take it on. Or, if you DO take something on mid-sprint, drop something else so that you can still get everything done.
• Track your velocity (points complete per story) and use that to plan future sprints.
• Estimate tasks relative to each other. Task X was vague and took, say, 8 points; task Y is similarly vague, so let's estimate at 8 points too. (This works best if you have typical story samples that represent a good 1, 2, 3, 5, 8, etc. point story.)
• Consider re-pointing if stories are too big.
• Try to break stories down as much as possible.

Again, agile is about vague estimates of work relative to past work complete. It's not about nailing down the number of hours, minutes, or seconds something will take. As long as you can say "this past task X was similar and was Y points, so this task is Y points too," your velocity will be consistent, regardless of the precise numbers you point tasks with.

Split work however seems natural and best fits the teams.

Answer 2

We work on a week-long iterations. Whenever there is a task which needs some research (which means that team don't have a clue on how to solve a problem and the level of uncertainty is high) we decide how many hours we want to spend on a task in iteration, ie. 4h. It means that during the iteration someone takes such a task and spends no more than 4 hours on research. After finishing, whatever the results are, they are presented on demonstration meeting and the outcome is used on next planning session.

Of course, sometimes first couple hours spent on research bring too little knowledge, so the research is continued in subsequent iteration. Also with time-limit. However in our team this situation is rare. Usually first couple hours is enough to tell what's task about and how to deal with it.

Of course the amount of hours needed for first-step-research depends on business domain. Maybe it would be day or longer. Or maybe an hour. However please keep in mind, that good-enough results are visible quite fast.

Answer 3

One idea is to use historical data and try to plan for such things, so like we have such a number of maintenance issues, such a number of fires to extinguish and some "normal" work to do. You can also plan for such things, so no matter what happens we don't work on maintenance more than 50% of time, since we want to have new features done as well.

Another idea is to use Kanban which is really a method which suits such situations very well. In this case you don't really try to plan some kind of iteration or however you call a couple of weeks-long period. You just react for whatever is top priority at the moment.

Actually such approach works pretty well for maintenance teams. You can also tweak your own solution so you have things lie priority lane, where super-duper high priority tasks are dealt with and such. So it's pretty easy react for changing environment.