There Is No Side Hustle in Agile

Have you ever hired a contractor to build something for you, like a piece of furniture? They promised to have it completed by a certain time, but when the date arrived, you were told that they ran into issues and would not have it ready for another week?

You scratch your head, wondering what happened because, even as recently as the day before the work was due to be completed, the contractor told you that they had no issues and would be ready on the date promised.

One possible reason that the contractor did not have the work completed as promised is that they were doing work for other customers and did not have the time to work on your project. They overcommitted, thinking they would have time to work on your project, and did not want to tell you they were running late when you asked for the updates. I call this the “side hustle”. And just like contractors can have side hustles that delay them completing their commitments, so can Agile team members that work on tasks during the sprint that are not related to the product delivery.

Throughout my years of working with agile delivery teams, I have seen this happen many times — and on almost every team. One or more team members perform work outside of the project during the sprint, and either doesn’t say anything to the team or passively mention the side hustle but don’t account for it in their allocation to work on team commitments. They continue to work their side hustles, often, to the detriment of the delivery.

In this article, I describe the side hustle; what it looks like on an agile team, how it impacts the delivery, and some suggestions on what can be done to minimize or eliminate this practice in agile teams.

What is a Side Hustle?

A side hustle, as it relates agile teams, is when a team member does work or participates in activities during the sprint that are not related to the team’s work on the product. These activities are usually requested by someone outside of the team, for example, the functional manager, and are not communicated to anyone within the team. Since the work is outside of the team, it is not part of the sprint backlog, and therefore not visible to the rest of the team. Note that most non-team-related work is valuable to the business and not a bad thing. It only becomes a side hustle when it is not accounted for in the team member’s availability to work on team commitments during the sprint.

What Does a Side Hustle Look Like

To illustrate, this is how a side hustle usually plays out. During sprint planning, the team member confirms that they have full allocation for the upcoming sprint. If the team member has historically completed 8 story points at full allocation, then they should be reasonably expected complete 8 points in the upcoming, barring any unforeseen impediments.

What the team member did not mention was that the day before the sprint started, they were told by their functional manager that they had to participate as an SME in 2 full days of discovery for a new, unrelated project. This means that 20% of the team member’s time over the next 2 weeks would be dedicated to non-team activities. So, based on a 20% allocation to the work not related to the team, the team member should have only accepted work totaling 6 points or less for the sprint (8×20% = 6). Since the team member committed to the story estimated at 8 points, they are now overallocated and risk not being able to complete the story during the sprint.

At each daily scrum, the team member reports they are working on the stories, have no blockers and will be done in time to test before the sprint ends. They also passively mention that they are attending a ‘bunch of other meetings’ but give no details. On the day before the story is scheduled to be ready for testing, the team member reports that work is not done. What happened? More likely than not, they were working on the side hustle and did not have enough time to work on the sprint commitments.

The Hidden Dangers of the Side Hustle

Side hustles undermine core agile values, including transparency, commitment and respect. When team members are not open about their non-team work during the sprint, the team can be overallocated, causing other team members may need to work overtime to meet their sprint commitments. This may lead to resentment towards the team member with the side hustle.

Side hustles also impact commitment reliability, a key agile metric that can predict the team’s ability to meet sprint or release commitments. Commitment reliability or, the say/do ratio, the ratio of story points delivered compared to the points to which the team committed during planning. For example, the commitment reliability of a team that plans 60 points in a sprint and only completes 56 points is 93%. If they complete 45 points instead, then the reliability for the same period will be 75%. The better the team is at planning the workload based on its availability to do the work, the higher the ratio and the more reliable the team becomes over time. When there are side hustles, the team is less likely to meet its commitment and will decrease its reliability.

Benefits of Eliminating the Side Hustle

As teams start to account for work down outside of the team during the sprints, they will more closely match the sprint workload to the team’s true capacity. This alignment should help increase commitment reliability.

The chart below shows how the commitment reliability is higher in sprints 3&4 after a team started committing to work that more closely matched its availability. This is compared to sprints 1&2 where the team was not adjusting the availability for non-team activities and taking on more work than can work during the sprint.

As a team becomes better at matching its capacity to the sprint workload, the team increases its chances of completing the stories and meeting the sprint commitments. This should help eventually make the team be more predictable as it plans sprints and forecast release timelines.

So, what can be done to eliminate, or at the least, minimize side hustle on agile teams?

3 Suggestions for Minimizing the Side Hustle

1. Update the Team Working Agreement
   Include language regarding team members being transparent with other team members when they are working on non-team activities. Activities consist of anything from attending a non-team meeting as a proxy or participating in a discovery session on an unrelated project. The wording could be something like, ‘Team members shall uphold the transparency value of Agile by informing the team when they are asked to do work that is not related to the product delivery.’
2. Reduce capacity to account for team member’s availability during the sprint
   At the beginning of each planning session, as a team, update the capacity of each team member. Confirm the planned time off and percent allocation to the project for the upcoming sprint.
3. Confirm workload matches capacity
   Check that the total number of points in the sprint backlog is equal or very close to the total capacity for the team. For example, if the team’s capacity for the sprint is 60 points and the total points planned for the sprint is 70, then the team is overallocated and should work with the Product Owner to move stories to the product backlog The capacity check should also happen during the sprint as team members may want to work on additional stories but may not have the capacity based on where they are in the sprint.

To reiterate, non-team activities performed by team members during the sprint are not a bad thing. The key is for team members to be transparent about their availability during each sprint so that the team does not make a commitment to do work for which they don’t have enough capacity to complete.

If you have experiences with the side hustle and would like to share your thoughts, or need help recognizing and addressing this anti-pattern, please contact me at [email protected].