«    »

Scaling Up From One Developer

I have noticed a common problem afflicting small development teams formed to make significant enhancements to an application that was previously maintained by just one developer. Both the original maintenance developer and their management are accustomed to essentially solo development and this culture spills into the enhancement work. Development is treated as individual efforts rather than a combined team, which results in issues like the following:

  • Highly variable quality - some of it very poor - in delivered work.
  • Budget and schedule overruns due to inaccurate estimates and lack of scope control.
  • Communication breakdowns.
  • Insufficient monitoring and risk mitigation by management.

These issues are all symptoms of the underlying problem of failing to adjust development practices to scale up from one developer to a team. One developer working alone on minor enhancements to an application can typically get by on their own ability, without explicit use of any development practices. The enhancements are often simple enough to fall within the developer’s zone of competence so issues are infrequent. Tackling a larger enhancement with a small team of three or more developers introduces the following scaling factors:

  • Higher complexity of the changes (in addition to the larger magnitude of change).
  • Higher likelihood of requirement changes, additions, and refinements by the business.
  • Communication and coordination among the developers.
  • Dealing with variations in practices or abilities between the developers.
  • Ramp up needed for new developers to become familiar with the application and the business domain.
  • Less flexibility to recover from issues due to larger budgets, longer schedules, more people, and more management visibility.

So what can these teams do to successfully scale? One idea that I often hear mentioned is to turn the work into a formal project and assign a project manager. However, this is seldom a viable option due to considerations like the following:

  • Starting a formal project within the organization is a lengthy endeavor that the business wants to avoid since they want their changes made as soon as possible.
  • Adding a full-time project manager to a team of three developers represents too much overhead that the business (or I.T., depending on the organization) does not want to pay for.
  • The I.T. organization does not have sufficiently skilled project managers to staff these 'mini' projects full-time. (I have been burned by overly-junior project managers making things worse, rather than better.)

So what options are available to teams needing to scale up? Based on some recent experiences, I believe that the Scrum development method has a number of ways it can help. And I am not even talking about fully adopting Scrum (although that is an option).

I will start with the role of ScrumMaster which I have explored in a recent article titled The Mindset of a ScrumMaster. The role of the ScrumMaster is to help grow a high performance team. Some people view ScrumMasters as process coaches, which is part of what they do, but they are really team coaches. For small teams, ScrumMasters can help on a part-time basis, which helps mitigate concerns about high budget overhead or staffing. And rather than trying to directly manage the work as a traditional project manager would, a ScrumMaster helps the team learn how to self-manage, providing guidance when necessary. What exactly would the ScrumMaster help the team with? This is where some of the practices used in Scrum can help deal with scaling factors.

The first Scrum practice that can help a team scale is the daily standup, which develops communication between developers (which is surprisingly hard if they are used to working alone) and helps focus their efforts. Speaking of tasks, the next Scrum practice that can help a team scale is to use a task board which helps visualize tasks queued in the backlog versus in progress versus done. This provides a focus for the daily standup discussions and helps provide a basic structure for the team to track their current progress. To forecast future progress the next Scrum practice that can help is the use of velocity and burndown charts to predict when milestone targets will be achieved. These practices help with scaling factors relating to communication and monitoring, but do not really help with quality issues. For that, the Scrum practice of definition of done is helpful, although the team will likely need coaching in how to adopt the way they work in order to achieve what they have defined as done.

The combination of these four practices is synergistic, imposes limited overhead, and is simple enough that developers can learn to do these practices on their own with some coaching from a ScrumMaster. Small teams of developers using these practices can therefore significantly mitigate the scaling factors that would otherwise cause issues.

If you find this article helpful, please make a donation.

«    »