Agile, project management

Scale down, not up

During the 10 years I’ve been working as a software developer I have participated in both
successful and unsuccessful projects. When a project is stumbling and failing to deliver
what is expected, it is natural to look for changes to make and when pressure from managemenent above gets too intense and time to market is crucial, the project manager’s weapon nearly always seems to be:

“Let’s bring in some more resources to ensure the delivery date will be met.

This way, when the project fails, the project manager can stand tall and state:

“Well, at least I did what I could….”

This urge to scale up whenever things slip, is kind of fascinating. But in some projects scaling up may actually slow the project down. In my opinion, scaling up is NOT a good idea if:

  1. The complexity of the domain is high
  2. The time span of the project is short
  3. If the project already consists of team(s) with 6 or more members

In projects where the landscape is as a above, it actually might be more beneficial to scale down instead. Why is this so? First of all, when adding more members to the project you also increase the communication needed in the project. When the amount of communication increases you also increase the chance of misunderstandings and mis-interpretation. Second, unless the new team members added are experts in domain and technology (which is rare to come by these days), you will need to invest time in training and knowledge transfer. This will almost certainly tie up key resources with questions, work shops and so forth which could acually lead to less velocity. Thirdly, two developers aren’t alike, a common misunderstanding by managers. A developer with poor skills might infact produce a negative velocity if other resources need to clean up their poor work. Finally, research has shown that small teams in general have a better team sprit then large teams. And as we all know, great team spirit is needed when producing high quality software.

To conclude: It is my opinion that project managers sometimes chooses the “scale up strategy” way too easily. This sometimes misjudged action gives them an alibi to show management. Way to often this strategy, along with the project, fails. What we instead need is skilled, brawe project managers who do not walk into the that “Scale up trap” whenever a project fails to deliver.

Mythical man month

Advertisements

2 thoughts on “Scale down, not up

  1. Scaling up (in my opinion), is rarely a good idea. Allocating more resources later in the project is usually a recipe for failure. Nevertheless, if you have some very experienced resources that were allocated on the project before and know exactly what’s going on, then the risk of adapting them to the project is low. Even in this case, the team morale will be affected. The solution to this problem is to reschedule.

    You mentioned the problem but you did not mention the solution.

  2. “Scaling up (in my opinion), is rarely a good idea.”

    I agree that late in projects it is never a good idea to scale up late in projects. I do however think that for some projects, with independent and easily partitionable tasks, scaling up is an option. Sadly though, these projects are rare to come by.

    “You mentioned the problem but you did not mention the solution.”

    My focus in this post was to shed light over a misconception among many managers and also propose that for some projects, scaling down the number of resources may actually give an increase in progress.

    I do agree, if we are to discuss possible actions to take for projects in trouble, that re-scheduling is one solution. But I don’t think it is the only solution. Since we agree that scaling up is not a good option (at least late in projects), the third possible solution is to scope out functionality.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s