declan bright

Software Research & Development Sprints

sprinter

Do you work in or manage a software development team and feel that the team never gets a chance to catch its breath, to innovate and explore new ideas? Are there strong members of the team who never get a chance to contribute to the design process? If this sounds familiar then you might be interested in Software Research & Development Sprints.

For a busy team, conducting research, if it happens at all is often carried out by individuals, working in isolation for short bursts in between regular development work. There is nothing wrong with this per se but the approach is usually unstructured and undocumented and therefore does not always deliver as much value as it could.

Aristotle said (allegedly) that "the whole is greater than the sum of its parts" so instead of individuals carrying out R&D in isolation it is better to create an environment where people can brainstorm, innovate and design together.

The primary objectives of an R&D sprint are to get more people involved in the design process and to investigate new technologies, frameworks, methodologies and patterns in a short timeboxed period with minimal impact on day to day business.

Deciding on a Research Subject Area

Ideas for subject areas to research can come from anywhere. Some will come from management and the senior developers but everyone should be encouraged to make suggestions.

How is the sprint structured?

The suggested structure is 1 day a week for 2 to 4 weeks with 3 to 5 developers, this will vary depending on the subject area and developer availability. This structure has minimal impact on day to day business and gives everyone involved some time to think in between the weekly sessions. Running the sessions on a Monday (hopefully) ensures that everyone involved is well rested and motivated.

All participants should work together in a separate meeting / conference room to foster creativity, ideally with access to several whiteboards or flipcharts. Pair programming is also encouraged. The sessions are intended to be very focused and therefore should not be disrupted other than for emergencies (working closely with project managers during the planning phase is important here). In general, developers are only allowed to work on the project during normal business hours on the allocated days, extra time can be spent outside of normal business hours if desired.

Who needs to be involved?

The people involved will vary depending on the subject area but the following people will generally be involved in a sprint:

Inputs to a Sprint

Once a subject area has been chosen for a sprint, it must be scoped to ensure that the sprint is focused and does not deviate from the initial objectives. Basic source code should be setup and any required test data should be identified etc prior to the sprint to ensure that the first session gets off to a productive start.

Outputs from a Sprint

Recruitment Process

The recruitment process should be open to all developer's, a description of the sprint should be published to the team and there should be enough time for people to discuss it with their managers. If too many participants apply then names should be pulled from a hat to ensure that everyone knows that the process is fair. For certain sprints it may make sense to hand pick certain individuals for their expertise, when this is the case it should be explained to the team.

Benefits

There are several benefits for everyone involved:

For developers:

For the architect:

For the company:

Summary

This approach is very productive if managed correctly and experience has shown that it generally delivers a number of interesting surprises. Ideas come together in unexpected ways and sometimes totally new ideas come out of nowhere. It's good to give people a chance to be creative from time to time and since this approach has such a low impact on day to day business everyone benefits.

View Comments