Planning with Scrum – Why Bending on Cost isn’t a Great Option

A common misconception about Scrum is that teams using it can’t do planning.  In the next few posts, I’ll be demonstrating some techniques that can be used to plan releases for teams using Scrum.

In a previous post, I talked about the options project teams have when a project starts to fail.  In it, I described the three sides of the “Iron Triangle” that can be adjusted when things start slipping.  In this post, I’ll talk about choosing to flex the cost side of the triangle.

What does flexing cost mean?

Being willing to flex on cost can mean several things.  It could be buying some additional tooling, buying new hardware, or setting up new environments.  Those are all things that might help get a project back on task.  However, when most people talk about being flexible on cost what they often mean is adding additional resources, and that is something that rarely helps get a failing software development project back on track.

Other folks have covered that topic much better than I can, so I won’t go into all the gritty details.  A good place to start is the book “The Mythical Man Month” by Frederick P. Brooks Jr, but there is a wealth of information available on the internet dedicated to this topic.

Why do people do this?  What are we hoping to improve by adding resources to a Scrum group?  One word: velocity.

Why doesn’t this work?

Velocity is a tricky beast.  At its simplest, velocity is a measure of how much work a Scrum team can complete during a single sprint.  While the concept of velocity is simple, understanding how it is affected by changes to a team is anything but.  In general, adding new people to a Scrum team tends to initially disrupt the ability of the team to get work done.

From a purely technical perspective, the usefulness of adding resources to tasks relies on that work being parallelizable.  In other words, the work can be broken up into pieces that have no dependencies on each other and can be consolidated into a whole after the pieces are all complete.  Unfortunately, most software development tasks don’t fall into this category, and adding additional resources only adds to confusion and communication problems.

Ignoring technical issues, the people and personality challenges caused by adding “new fish to the pond” can also prevent velocity from immediately improving.  These kinds of factors are also very hard to mitigate and usually just need to run their course.

Can additional cost ever help?

While adding more resources to a Scrum team in the hopes to have an immediate positive impact on velocity doesn’t tend to work, there are ways to increase the team’s velocity in the long run.

Adding members can eventually increase a team’s velocity.  If the need for more capacity is recognized early, adding new members to the group will increase the velocity after the group has had the time to reintegrate.  How long that takes varies from group to group.  These additions to the group would ideally be new permanent members of the team, not simply burst capacity brought in to push schedule to the left.  There is also a “sweet spot” for team size.  If the team grows past about nine people, it may be wise to split the group into more than one Scrum team.

If team members are not fully allocated to the Scrum team, increasing the existing team members’ allocation will absolutely allow them to get more done each Sprint.  My preference would be for folks to be 100% dedicated to their Scrum team, but I also live in the real world and understand that that doesn’t always happen.  If your Scrum team members aren’t 100%, making them full time is the best way to increase their capacity for work.

So how does this help with planning?

It doesn’t, much.  Since it’s really not possible to know what effect adding team members will have on velocity, you can’t really plan accordingly.  Bummer.

Given my druthers, on projects I’m working on, I’d much rather be flexible on schedule or scope than on cost.  I’ll talk about those in future posts.

Triple Constraints – When nothing can give, what does?

Triple Constraints
The Triple Constraints or “Iron Triangle”

In project management, people often talk about the triple constraints, or the “Iron Triangle”.  It describes the concept that when a project encounters obstacles there are a limited number of things that can be adjusted; the schedule can be slipped, the scope can be decreased or money can be spent to purchase additional resources or tooling.  There aren’t a lot of options outside those three, but sometimes a project sponsor is unwilling to bend any of the edges of the triangle.  What happens then?

People who have been involved in more than a few projects understand that unforeseen  things will happen.  When a project sponsor is unwilling to be flexible on schedule, scope or cost the team often goes into hero mode in order to bring the project back on track.  The unfortunate truth is that this rarely works.  As people start putting in longer hours they get tired and start making mistakes.  This typically has the effect of putting the project even further behind.

In reality, when we’re not willing to bend one of the three sides of the iron triangle, we are actually bending the hidden fourth edge: quality.  People will start advocating decisions to cut corners.  Testing often gets thrown out the window in the interest of saving time.  In the end, quality suffers, and in many cases the project misses its schedule, scope or cost goals anyway.

My recommendation for every project you work on is to have the project sponsor decide which of the constraints they are willing to let bend when difficulties arise.  I also recommend that instead of including just schedule, scope and cost in the  list of options, that quality is also one of the choices.  Most people are not willing to sign their name to slipping quality when the project starts failing.  Furthermore, explicitly listing it as an option will drive home the reality that that’s what will suffer if one of the other options isn’t chosen.

In the next few posts, I’ll talk about different techniques that can be used to plan Scrum projects once we’ve chosen which edge of the triangle we’re willing to flex.