Scrum++, about teaming up research with productivity

If you are interested in agile software development, you probably already heard of Scrum. To explain it briefly, Scrum is a methodology for agile software development. It's focus is on working in short iterative 20 day cycles where the team takes on a specific set of functionalities (called "backlog items") and holds a daily 15-minute standing up meeting to divide the tasks amongst the team members.

At Citylive, we use the Scrum methodology. Thanks to our R&D director and "scrum master" Rafael Lefever, not only the development team is now working in the spirit of scrum, but also the marketing and operations are aligned around the scrum calendar. No walls between development and marketing in our company!

The problem of how to plan research

Since we develop software that is really on-the-edge, we are faced with a lot of software research. Scrum models the research as being part of the tasks that need to be done to implement a feature. The problem with this approach is that sometimes we need to investigate something without knowing if it will ever lead to software that will go in production. Once you know what needs to be developed, the fundamental research phase is over. Scrum doesn't model this, so the research work was a bit of an uncontrolled effort up to now. Needless to say, the plain vanilla development tasks mostly receive higher priority than the research topics, so we end up doing sloppy research, which frustrates everybody.

To the rescue: Scrum++

So we can up with a fundamental research extension to scrum. The scheme is really simple:

• each developer can spend 1 day / week on fundamental research, resulting in an "idea 1-pager"
• in the 4 days/week remaining for the sprint each developer works 1 day/week on a fundamental research feature (resulting in a prototype)
• the other 3 days/week of the sprint they work on a product feature (resulting in production quality software)

This cuts back "productive" software development time by 40%. But I am convinced that in a highly innovative environment this is actually leading to more productive outcome. When you work on the edge, it happens a lot that you need to take a step back, rethink, throw away and take a different approach. This costs time and money.

By making a funneled process (10 research questions lead to maybe 5 workable idea's, those are filtered to 2 prototypes of which we implement 1 product feature) you actually save a lot of wasted effort.

This also means that the product planning process becomes much more sensible. The product manager now has the result of the research as a tool to help determine the roadmap. This is crucial in a highly technical context. I see a lot of innovative startups taking the wrong strategic decisions, since they don't take enough time to investigate the world around them. And once they have chosen a certain path, it becomes too expensive to start all over again. Marc Andreessen's Ning has been developed from scratch 3 times in a row before they did find the right approach, and also the wonderful people at 37signals had to throw away their first version of Backpack when development was almost completed "because it just didn't feel right". Those bold decisions are hard to take, so the best is to try to avoid the situation where you have to take them. This is where we introduced the second aspect of Scrum++:

The planning process

• If anyone in the company has a research question, they write it down in 1 sentence on the dedicated poster board (and yes, the sentence has to end with a question mark :)
• At the daily scrum, a developer can indicate that he wants to take the day to do research (just like taking a day off, only more fun!)
• 1 week before the product backlog is composed by the product manager, the team has a brief meeting to decide what idea's (resulting from a 1-day research topic) they want to propose as "prototype candidates" for the backlog.
• In composing the backlog, the product manager includes those items or has a brief informal meeting to argument with the team on the prioritization of the prototype candidates
• During the estimation meeting, the scrum master ensures that 25% of the capacity of the sprint is taken up by prototype development and 75% by product development
• During the spring review meeting, the prototypes are validated just like the product features and the product manager can decide to take up a feature in the roadmap that implements the functionality that was prototyped (for inclusion in one of the next sprints)

I presented this to the team and they fancied the approach. Of course this isn't "real" scrum, so our scrum master makes the necessary reservations and I subscribe them. We'll evaluate if the approach is working. I'm not a big fan of methodologies anyways, but in case this takes off just remember: You heard it here first!