Get certified - Transform your world of work today


Beyond Scrum: Lean Enterprise - "Agile R&D Stream"

A New Idea Inspired by Scrum

2 August 2013

Mirko Kleiner

The topic "beyond Scrum -- lean enterprise" inspired me in an area of research and development (R&D). May I present to you my idea below, which we have already implemented and tested successfully at

Smaller and mid-size companies usually don't have their own R&D department, nor someone who takes care of planning and controlling R&D. On the other hand, companies that are delivery driven (I mean here not only software development companies) often have "spare time," e.g., time in between projects that needs to be filled with valuable tasks.

Lean enterprise: Agile R&D stream
Scrum gives a structured style of task definition, review, and control within a defined time frame. That led me to this setup idea:

  1. R&D backlog
  2. R&D team
  3. R&D sprint
  4. R&D meetings (planning/review/retrospective)
The management,  business representives, line managers, and so on, as well as "regular" employees, act as one team and, together, define and prioritize the R&D backlog items that give value to employees but also to the whole company. This team is more the supporting line than the project organization of a company. By which I mean that there will be the most participants in this team, acting most of the time in delivery and project organization. This means the sprint length has to be longer than usual, e.g., one month at minimum. This is needed to ensure output during those "spare" times. 

If a team member has some spare time, he can serve himself from the R&D sprint backlog with a story that he's interested in personally and that matches his timing. If somebody has taken on a story in this way, he has to document it and present results in the appropriate sprint review meeting. Otherwise everything is handled just as in a normal Scrum sprint. 

Advantages of the Agile R&D stream
  • Authority but also accountability is given to everybody in the company regarding R&D  (top down and bottom up)
  • Tasks for spare times are planned in advance and generate business value
  • R&D is established in a structured way, but without any conflict to delivery.

Our first experiences were satisfaction on management's part, but also on the employee level. This method supports self-organization, everybody can decide for himself about a project to take on, we didn't lose any time in finding good topics to research, and all employees profited from the results -- and ultimately the company did, too.
For more about personal field experiences in Scrum, visit my blog at

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 0 (0 ratings)


Bhoodev Singh, CSP,CSM,CSPO, 8/2/2013 1:38:06 AM
Good one, but team does not really know upfront what tasks might be involved during the course of research. So, how do you handle estimation?
Mirko Kleiner, CSP,CSM,CSPO, 8/2/2013 4:34:53 AM
it's that simple like usual planning meeting. The stories are added and described to product backlog in advance, together priorized and put to sprint backlog. Team gives initial estimation based on description and po decides if story has to be break down to be more precise.
Bhoodev Singh, CSP,CSM,CSPO, 8/4/2013 1:38:46 AM
Mirko, I think either you're misunderstood or missing my point. In any research product, particularly in core research areas, it's not that easy to predict the tasks upfront as you're interpreting here. It's because of lots of uncertainty teams go through w/ before reaching to the prototype stage. Life get more easier after we've the prototype ready,then we know what to build and how the product should be looking like. Btw, I'm not talking any web based projects here and I assume that's what you're referring to.
Mirko Kleiner, CSP,CSM,CSPO, 8/4/2013 3:23:20 AM
I got your point, thx for clarification. Note it's not that different to normal planning meeting. We also got sometimes very unspecific epics, that have to be breakdown into stories, etc. However, let me visualize that based on an example.
An employee has a new idea on epic level. He adds a new epic to R&D Product Backlog, where he's describing his idea. In first planning meeting the R&D team, does the the refinement of epic into stories, there priorization and definition of goals. These goals are important, cause they have to be reachable withing given timeframe, until end of sprint. According the story goals and refinements R&D team reestimates time needed to achive those goals. This estimation is then like the time budget, that could be investmented. This should help the researcher not to loose himselfs in too much detail.
With that approach you create a top-down funel from unspecific to detail as well known in R&D. Hope I could answer your question now?
Bhoodev Singh, CSP,CSM,CSPO, 8/4/2013 6:10:02 PM
Two bits advice...let PO defines the "Why" and the boundaries of the ideas before deriving the "What"(user stories), otherwise it would be worthless spending money and time.
Glen Wang, CSM, 8/4/2013 11:58:43 PM
Self-organizing is beautiful!
Dave Spooner, CSM, 8/5/2013 6:32:35 AM
I can see how this could work, however it appears to rely on an environment where there is regularly downtime. I worry that this approach could lead to both less focus on the current sprint, as well as less focus on the R&D task while working on it. Personally, I would be applying pressure to the business to experiment with running an R&D focused sprint and analyse the results, to potentially be incorporated every 'X' sprints.

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up