This document discusses Brooks' Law and strategies for increasing the velocity of an agile team without adding more members. Brooks' Law states that adding more members to a late project will only make it later since new members require time from existing members and increase communication overhead. Instead of adding people, the document recommends ensuring team productivity, removing impediments quickly, focusing on sprint work, fixing structural problems, using true agile practices, empowering a single product owner, and increasing capacity through a second scrum team only if truly needed. It also provides tips for increasing velocity such as improving DevOps practices, scheduling slightly fewer points per sprint, reducing team size, increasing cross-functionality, and refining products effectively.

1. When things are going too slowly
Brook’s Law
Part 1: on-boarding a new takes the time of an existing person, and that new
person is not immediately effective
Part 2: more people = more communication points = more complexities
Part 3: it is not always possible to divide up a task. One elephant takes 22 months
to have a baby, ten elephants cannot have one baby between them in 2 months.
If it is looking like your programme,
project or team will not meet the next
agreed milestone, not meet a
contractual deliverable, or velocity is
too slow then the natural response is
to add additional team members.
As soon as you have these thoughts
that things are too slow, you have
two choices:
1. Get more people. They then
create work for your existing
people. Things get slower, you get
more people, you get more
behind schedule. Then you bring
in the “superhero fixer” who
dramatically changes some stuff,
reduces the people. In the
meantime the team felt
undervalued and the project cost
more than anyone wanted!
2. Realise you want to make choice
1 and don’t! Instead read this
guide now BEFORE you start you
project.

2. Okay, so I won’t add more people… but
what should I do?
• Make sure the team are productive
– see right some key things to
consider.
• Ensure impediments are being
removed quickly. Engage the
business and escalate to get this
done.
• Check the team is working on sprint
content, rather than other tasks.
• Fix any structural problems you
have, for example skill shortage,
inadequate architecture, etc.
• Make sure the project is actually
using Agile, appose to combing
some elements of Agile with
waterfall. For example is you are
using water-scrum-fall or mini-
waterfall, then this is likely to be
your problem.
• Is there one, and only one, Product
Owner who is empowered to make
decisions, does make decisions, is
present at all relevant meetings
and is close to 100% on the project.
• If all of these things have been
resolved, the team has a good
velocity, and is productive, then you
may consider carefully adding a
second scrum team to increase
capacity. However be warned, if one
team can do 20 points, two teams
will definitely achieve less than 39 in
the same time period.
Increase an Agile team’s velocity by:
• Dev Ops – ensure they are using
automated testing, build and
deploy.
• Schedule slightly less points per
sprint. For example if they typically
do 20, then schedule no more than
18. If they have time they can pick
up extra items, over achieve, feel
good, become more motivated,
work faster.
• Reduce the number of scrum
teams or number of people in the
scrum team (do you have too
many cooks)?
• Train the team to become more
cross functional.
• Ensure product refinement is
happening.