2

Several of my team members do Research&Development work, which by nature involves a lot of exploration and uncertainty, and requirements are not always clear since we don't know what is out there.

For those reasons our R&D cards typically stay on the board for 2+ weeks, whereas our average cycle time from Priority to Done tends to be around 7 days. Those cards are also particularly vulnerable to scope creep.

How can we address this and make those cards flow faster? I have read Managing scope creep in Agile and How to minimize scope creep?, but I felt the answers to those questions didn't address contexts where uncertainty is much higher than in regular feature development.

  • 2
    "Scrum is a framework for developing and sustaining complex products" (from the Scrum Guide). Kanban has its roots in manufacturing and product development. I think that both can give a useful foundation for managing research efforts, but are you sure that you're using the right tools? It seems like you're trying to speed up research. If you're doing something closer to pure research, should you be trying to speed it up? – Thomas Owens Oct 16 '17 at 15:23
  • Which is most valuable, speed or outcomes? (a bit rhetorical) – Alan Larimer Oct 16 '17 at 15:31
  • Thanks for your comments. I guess I don't mean to speed up research as much as I want to reduce card size. We're just finding it a bit hard to decompose those cards into smaller chunks, which as @CodeGnome suggests should be possible most of the time. – Balala Oct 17 '17 at 19:42
3

TL;DR

If you're doing commercial R&D, then you should focus on directed development and manage the project around the research methodology chosen. Less directed research should simply be time boxed (financially or otherwise) so that the necessary reporting deliverables are handled appropriately.

If your research is directed, it should then be decomposable into manageable chunks. Whether those chunks are on Kanban cards or not, a structured methodology inherently combats story size and scope creep.

Analysis

Research is exploratory. However, good research is directed exploration. Consider some examples:

  1. Take ice core samples from the Arctic to test for carbon levels.
  2. Mapping a portion of the sea floor.
  3. Vaccine development for a new disease.

All of these things are experimental or exploratory in nature, but they can still be decomposed into steps, phases, tasks, and time boxes. While pure research is generally less constrained to deliver rapid results, research should still be designed to eventually yield results, even if the result is an affirmation of the null hypothesis.

While you can use Scrum or Kanban to manage R&D, I think it's likely to be the wrong approach because the business goal of R&D is neither to improve cycle times nor throughput, but to identify the success or failure of a hypothesis as rapidly as practicable.

Even in areas like pure mathematics where some problems aren't well-aligned to typical project management approaches, the researchers should have a defined methodology or plan of attack for the problem. If not, then you simply can't measure progress or deviation from a plan, which is pretty much the point of project management as a discipline.

There's Always an Artifact

Even the most esoteric, non-results driven research is expected to produce some sort of artifact within a time box. That may be a research paper, a monograph, a scholarly article, or a symposium talk. Whatever that deliverable is, that's what you manage towards.

Imagine an endowment where an academic is given a $100,000 endowment to spend a year thinking about a math problem like P versus NP. Assuming no formal methodology, the patron probably still expects regular updates on the process, or on how the money is being spent (unless it's simply a stipend). They are also likely expecting a report on the results or lack thereof at the end of the funding period.

If you truly can't manage a given set of research goals as a project, then at least manage the research as a set of artifacts and time boxes to be effectively managed. Paid research always has deliverables; you might just have to work a bit harder to identify what those deliverables are, and how best to track them.

  • Thanks for your reply. Any idea as to the kind of meta questions we should be asking to break down our research projects into more manageable chunks? – Balala Oct 17 '17 at 19:43
  • 1
    @elChovo You need to get the researchers to identify their methdology, and a work breakdown of how they plan to implement the various phases of the research. The scientific method is not ad hoc. – Todd A. Jacobs Oct 17 '17 at 22:22
1

I think the very nature of R&D projects means there is no such thing as scope creep. You are trying to control that which does not exist. At least, not the way we define scope in other types of projects. In R&D, scope is controlled by the simple mechanism of running out of time and / or money or the patience of whoever is cutting the checks.

So if you are trying to better your seven-day average, then you have an artificial stop of work that starts to climb over that seven days or maybe 10 days, then redirect your staff to the next R&D task. Then @ThomasOwens' question remains: should you try to speed things up?

  • As you move further from product development and closer to research, is there an advantage to timeboxing research efforts? Spikes exist to address work that requires research time. But Spikes (like many things in many agile approaches) are timeboxed. If you are building a product, it makes sense to eventually stop research and make a decision with some level of increased knowledge. But if you're doing research, maximizing knowledge is likely to be your goal. So is moving onto the next task after a timebox appropriate for something closer to research? I think that the answer may be "no". – Thomas Owens Oct 16 '17 at 15:35
  • I would say, no, too, but I have never cut checks for an R&D project that was "going nowhere." At some stage, you have to stop throwing good $ after bad. But that is different than a timebox. I think you're right, a timebox would be inconsistent with what you are trying to do in R&D. Time is already constrained simply by the $$ you have available. I think the OP is chasing the wrong issue. – David Espina Oct 16 '17 at 15:42

Your Answer

By clicking "Post Your Answer", you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.