By Nathan Donaldson
This case study looks at how well Scrum works when you have a Development Team of two.
A Scrum developer team is made up of 5-9 people. But what if the Development Team is only 2? Is Scrum still the right choice?
I’ve recently shadowed a project where there was 1 developer and 1 designer. We were asked to recreate a website that had taken a year to build with another organisation. We recommended the client start from scratch. The catch was that we only had a budget that would cover us for just five weeks.
With the short timeframe and an existing product (albeit a disliked one) to compare against, Scrum certainly seemed like the right choice. It would allow us to deliver the highest value features to the client first, and quickly. The trick was how to adjust Scrum for 2 workers and avoid becoming a Scrum, but.
The team agreed that one week sprints with the PO coming in three times a week (Monday, Wednesday, Friday) for the morning standups would be a good place to start.
All in all Scrum worked well for us in this situation but with the time pressure and the small team there were a number of issues we had to address.
Our developers are used to two week sprints or more, plus they usually have a number of other developers to help size user stories. For these two reasons they sized the one story they had for the first sprint too small and failed to deliver. The good news was that they weren’t far off and on the day of the first review (in which we couldn’t show anything) they had closed that story.
The team quickly learned from this. They took the time we had set aside for the review to break down the user stories in the backlog into more manageable chunks. The retro went well and all of the bumps of the first sprint were addressed. Going forward, the team’s productivity increased with each sprint. At the end of five weeks they delivered a product the client could use in production and that addressed their most pressing requirements.
With only one developer you do not get the benefit of multiple minds to find a solution. After all, the reason we work in teams is to benefit from more than one perspective. This was eventually addressed by opening up conversations between other developers in Boost to share solutions to “unknowns” in our team’s user stories.
After sprint 2, the developer and the designer decided that they should work side by side to optimize communication. This definitely improved their performance. This need was recognised primarily due to the time frame in this project, in addition to increasing performance it also lead to better sizing of the stories going forward.
This wasn’t a problem, just an observation. I was coming from a larger project (6 developers/2 week sprints/indefinite time) to this quick one and it made me feel like the daily stand-ups, reviews and retros went too quickly. The rapid speed in which choices were being made and actions executed left me worried that maybe we going too fast and not discussing enough. Of course the team took just the amount of time they needed with only two people and such a short timeframe to work in. It wasn’t long until I understood this and was able to enjoy the rapid pace.
In the end, Scrum worked great with a Development Team of two. It was particularly important in respect to the constraints on time/budget. That’s because it forced our Product Owner to organize the backlog by the value of the features. For example, they were always asking “so if you ran out of budget on this sprint, which story/feature could you not live without?”.
The quick sprints and retros allowed us to address issues with design and expectations as they appeared. The outcome was a site very different from the one originally built, but one that worked exactly the way the client needed it to.
It was a pleasure to be allowed to participate in this project as it really demonstrated to me the power of the Scrum methodology while working with motivated, open and creative people.
What is Scrum? — The framework in a nutshell
