We Can’t Maintain a Sustainable Pace with Many Small Projects


We Can’t Maintain a Sustainable Pace with Many Small Projects


people running in city

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

I prefer to think about this agile principle as: “Anyone who contributes to the success of the product should be able to maintain a constant pace indefinitely.”

The main two groups that I like to bring under the umbrella of “anyone” are subject matter experts and senior stakeholders. These groups are usually outside the development team, but need to be available for frequent conversations with the product owner and to provide timeous feedback at iteration reviews.

We often find that multiple projects are suffering because “anyone” is frequently unavailable, usually due to other priorities. 

In this post, I will highlight how starting too many projects can put an unreasonable strain on those inside and outside of the development team and lower the team’s chances of successfully delivering products.

We Often Need to Split Resources

Obviously, every project that we start needs resources and those are usually limited, meaning that new projects need to be resourced by allocating portions of people’s time.  Suppose we split someone’s time equally across three projects; that means that the person in question will be unable to work on two out of the three projects around 66 percent of the time, or 3.3 days per week.

Being unavailable for that much time is undoubtedly going to have a negative impact on velocity and quality. We can incur up to a 40 percent penalty in productivity associated with multitasking on complex tasks. A quick search on the internet shows just how widely accepted this argument is.

Our Teams Can’t Improve

Another downside of splitting resource and creating teams specifically around projects is that we lose the chance for our teams to continually improve via building relationships, knowing one another’s strengths and weaknesses and solving complex problems together.

According to Robert C. Martin in his book “The Clean Coder”, “Banks and insurance companies tried to form teams around projects. This is a foolish approach. The teams simply cannot gel.”  

He claims that we can’t even call these creations teams and that there is no such thing as half or quarter of a person and suggests that it is better to assign multiple projects to an established gelled team, who will work together to figure out the best way to get them done.

We Hinder Our Chances of Essential Engagement

Users, sponsors, subject matter experts and senior stakeholders all have jobs to do outside of our projects. Furthermore, the same people tend to be in demand for each small project that we start due to expertise or seniority. This is especially true if those smaller projects are related to a common product or strategic goal.

The more projects we start, the more demands we are making of these people, meaning that they can no longer work at a constant pace and can no longer be available for teams when required. Even when they are willing to work lots of overtime, they can’t be in two places at one time. So, through no fault of their own, they become huge blockers for all projects that depend on them. 

We Introduce Avoidable Dependencies

If we create lots of small projects that contribute to a common product or strategy, we will introduce the overhead of managing dependencies that are avoidable simply by either creating larger projects or allocating projects to an existing gelled team. It’s better to eliminate rather than manage dependencies wherever possible. 

We Risk Perpetual Change

We need to be careful to ensure that the projects we are running concurrently are not delivering changes to the same users. The success of our products will ultimately be decided by our users, so we don’t want to place them in a perpetual state of change, making it impossible for them to get their jobs done without working sustained longer hours.

We should be more concerned with significant process or cultural change here, rather than the well-managed continuous delivery of small software updates, which many users welcome.

We Cause Excessive Overtime

We have seen that starting many projects can put strain on those inside and outside of the development team. The diagram below shows the vicious cycle that we can become trapped in as the negative symptoms of sustained excessive overtime lower our quality, morale and productivity, which in turn leads to more negative symptoms. Thus, the cycle is begun anew.

cycle of excessive overtime

Choosing the Best Option When Starting Projects

Imagine for a minute that we’re property developers and have purchased two properties that we want on the rental market within 12 months. Each requires six months of dedicated renovation at a cost of $2,000. Property A will receive $2,000 per month in rent compared to the $1,500 Property B will receive. We can choose from three seemingly sensible approaches. The table below shows each approach and how it may broadly impact our profit.

 

Property A

Property B

Total

Profit (24 months)

Simultaneous: Team works on both properties an equal amount within each iteration

Time

8.4

8.4

16.8

- $8400

Cost

$16,800

$16,800

$33,600

Income

$14,400

$10,800

$25,200

Alternate Iterations: Team focuses on each property for an entire iteration alternatively

Time

6.9

6,9

13.8

$8.100

Cost

$13,800

$13,800

$27,600

Income

$20,400

$15,300

$35,700

Linear: Team finishes Property A before starting on Property B

Time

6

6

12

$30,000

Cost

$12,000

$12,000

$24,000

Income

$36,000

$18,000

$54,000


In his book “Agile Portfolio Management,” Jochen Krebs states that we could safely apply a 40 percent penalty to the “simultaneous” approach and a 15 percent penalty to the “alternate” approach, which increases our costs while reducing our income period.

Over a period of 24 months:

  • The “simultaneous” option is by far the worst and actually results in a loss of $8,400.
  • The “alternate” option is considerably better and results in a profit of $8,100.
  • The “linear” option is by far the best and yields a profit of $30,000. As we prioritize Property A over Property B in terms of pure business value, we finish on time and on budget. Even if we reject the switching penalties completely, this option remains most profitable because we can begin harvesting income from our most profitable property after six months instead of 12.

Kreb suggests that in reality the switching penalties can be much higher on complex projects and increase as the number of active projects grows, which makes the argument for the linear approach even more compelling.

Try to Be Professional

In the previous section, we saw that prioritizing and focusing based on business value offers an earlier and higher return on investment (ROI). It is the professional thing to do, so we need to at least try to be professional when making these decisions.

I say “try” because being a professional is difficult and often requires us to say no to our managers. However, just because it is difficult doesn’t mean we shouldn’t do it. Again in “The Clean Coder,” Robert C Martin agrees:

“Slaves are not allowed to say no, and laborers may be hesitant to say no. But professionals are expected to say no. Indeed, good managers crave someone who has the guts to say no.”

In my next post, I will demonstrate how to use a balanced agile portfolio, so that making professional decisions and saying no to good managers becomes easier.

In the meantime, feel free to share your thoughts on having many active small projects in the comments section below.



 

David Cassidy is an Agile Coach with over 20 years’ experience in the software industry.

Learn More
comments powered by Disqus