8 effective ways to improve the productivity

of an agile development team

 Home (https://juliendubreuil.fr/)  /  Blog (https://juliendubreuil.fr/blog)  /  Agile
(https://juliendubreuil.fr/categories/agile)  /  8 effective ways to improve the productivity of an agile
development team

13 MAR 2017 |  AGILE (HTTPS://JULIENDUBREUIL.FR/CATEGORIES/AGILE)

Often when thinking about the productivity of a Scrum development team, you may think about
velocity, the metric used to measure how much the team gets done in an iteration. However, the
velocity is used to determine how much point a team can achieve on average on a normal sprint and
then determines how many points they will agree to achieve in the next sprint iteration. The velocity
should not be used to determine if the team is productive or not, it’s just a simple indicator based on
past sprints.

Having a high velocity does not mean that much. What matters is the result at the end and what the
team has produced. Pushing a team to drastically increase their velocity has no sense. It could be
more costly at the end because it can lead the team to cut corners on acceptance testing, skip xing
bugs or minimize refactoring just to reach the velocity.

If you want to increase the velocity of your team, you should focus on the optimal velocity over time
rather than maximized velocity, which considers the quality of the end product. To help your team to
be more productive, let’s review several tips and tricks that I apply.

1. Remove impediments
One of the key role of the Scrum Master is to ensure that impediments are taken into consideration
early in the development process. Asking good questions during the writing of User Stories, ensuring
developers have all they need to do the work, being a shield for the development team so as to not be
disputed by stakeholders are tasks that the Scrum Master has to do every day.

To do: In case the team is disrupted, ask them to redirect questions and support requests to the
Scrum Master.

Pro tips: From my experience, distractions are the primary reason for reduced productivity in a team.
The team loses focus because of these distractions and cannot really justify why they delivered lower
than normal productivity.

2. Team size
To be e cient, the team should be small, something in between 3 to 9 persons. Above this limit,
communication problems can occur and you lose more time in discussions. If your team is bigger,
you have to split it into one or more teams.

To do: Ensure the size of the team is good (not too big) and ts the project needs. Also, take care of
the turnover, as introducing new members every month on the project won’t help you deliver any
faster.

Pro tips: Working with a big team with Scrum is not a good idea. The more you do, the more people
will lose information and the more effort required to make everyone aware of everything that is going
on.

3. Daily meetings
It can be repetitive to say but it’s really important that all the team members attend the daily meeting
every day. It should not take more than 15 minutes per day and will give an overview of how the work
is progressing. If a conversation gets off topic, it should be postponed after the meeting. A parking lot
can be created to store all the points that have been raised during the daily meeting and which need
to be answered that day.

To do: Be e cient, get prepared before the meeting, have in mind what you have done the past day,
what you have to do today and the impediments you encounter.

Pro tips: Communication is key in Scrum; this moment is very important to exchange.

4. Product backlog
Everything starts from the backlog, and maintaining it clean and clear is mandatory. By reading the
backlog, you should understand where the application goes and have the vision of what needs to be
built in the near future.

To do: The more accurate the User Stories are, the less time the development team will waste trying
to understand them. Ensure that the User Stories have enough details. Reorder them if needed,
change their priority and move them to the icebox while waiting for the next release.

Pro tips: A common issue I have encountered during an Agile project is the fact that PO don’t spend
enough time on the backlog for a lot of reasons. Ensuring the backlog has enough ready to use User
Stories for one (at least) or two sprints is very important.

5. Continuous improvement mindset

Scrum is a continuous improvement process so it’s normal to improve the whole process and not just
the software. Also, known as « Kaizen », the idea is to nd something to improve at the end of each
sprint and accomplish it during the following one. In doing so, you will be able to remove one problem
at a time and help progressing.

To do: During the sprint retrospective, nd one concrete action to achieve that will help the team. To
make it work, someone has to be responsible for executing the action.

Pro tips: Start with small actions, something easy to do in a sprint that won’t take too much time. Ask
each attendee for suggestions during the sprint retrospective, choose one and discuss the plan to
achieve it.

6. Interruption buffer
When running an application in production, you have to deal with maintenance and delivering new
features, and sometime interruptions occur. It can be an urgent bug that’s been reported or another
team that requires a developer to help them. It’s impossible to ignore the rest of the world when
delivering a product. You have to deal with these interruptions in the current sprint.

What matters is your ability to face this kind of situation. A buffer scheduled in all your sprints could
help you to avoid scope changes.

To do: Create a US with a small amount of points and add it to the next sprint. The number of points
depends on the number and time consumed by your current interruptions.

Pro tips: I personally book something like half a day of a developer per two weeks to handle this kind
of situation. In case no interruption occurs, this time can be used at the end of the sprint to help on
other tickets or even better, let a developer do some R&D for the project.

7. Make work visible

It’s a known fact that making your work visible helps the team to be more responsible for the delivery.
Having metrics and other charts printed and displayed on walls also helps stakeholders and
colleagues to know how the product is moving forward.
To do: Update the burndown chart on a daily basis, display the Kaizen you want to achieve, show the
customer or team satisfaction. You can also display the roadmap of what you are building to share
the vision. There is plenty of information you can display that will help everybody get the idea on how
things are going in a second.

Pro tips: I like to make all information visible for everyone on a wall. Displaying data helps the team to
deliver quality and involves all the company.

8. Avoid multitasking
Multi-tasking happens all the time, companies praise it. But multitasking reduces productivity and the
quality of the end result. When a developer starts working on a task and has to stop for something
else to nally go back to the original task, he lost all the time he spent understanding the software.
Asking someone to give up what he is currently doing has an invisible cost that you should be aware
of.

To do: Limit the work in progress for all team members. Be vigilant that the developer doesn’t get
overloaded working on several US at the same time.

Pro-tips: It’s a good habit to limit our work in progress and focus on nishing work, not starting work.

Final thoughts
This list can be bigger, but if you manage to apply them to your project, you will see bene ts at a low
cost. There’s nothing complicated, just common sense here.

If you apply something else in your team that works or doesn’t work, feel free to share in the
comments section.

TAGS

 AGILE (HTTPS://JULIENDUBREUIL.FR/TAGS/AGILE)

 AGILE TEAM (HTTPS://JULIENDUBREUIL.FR/TAGS/AGILE-TEAM)

 SCRUM MASTER (HTTPS://JULIENDUBREUIL.FR/TAGS/SCRUM-MASTER)

 Article suivant Article précédent 

Creating a Docker container in order to execute jobs Collaborative Development Model With GIT Using
to other containers Pull Requests

(https://juliendubreuil.fr/blog/devops/creating- (https://juliendubreuil.fr/blog/development/collaborative-
docker-container-to-execute-jobs-to-other- development-model-git-pull-requests/)
containers/)

Vous avez une idée, un projet web à réaliser ?

Ensemble, mettons en oeuvre sa réussite. Je vous accompagne dans vos
projets, depuis l'élaboration du cahier des charges jusqu'à la mise en
production. Pour plus d'information n'hésitez pas à me contacter.

 Contactez-moi (https://juliendubreuil.fr/contact)
0 Commentaires Julien Dubreuil 🔒 Règles de confidentialité de Disqus 
1 S'identifier

 Recommander t Tweet f Partager Les meilleurs

Commencer la discussion…

S'IDENTIFIER AVEC
OU INSCRIVEZ-VOUS SUR DISQUS ?

Nom

Soyez le premier à commenter.

✉ S'abonner d Ajoutez Disqus à votre site web !Ajouter DisqusAjouter ⚠ Do Not Sell My Data

À PROPOS LIENS

Je suis Julien Dubreuil (https://juliendubreuil.fr) Services (/services)

, un développeur web passionné qui réalise
des projets basés sur des technologies open
A propos (/about)
sources. Vous êtes sur mon blog (.). J’utilise
Twitter (https://twitter.com/juliendubreuil)  (https://www.drupal.org/u/juliend)
pour discuter de ma veille technologique, Contact (/contact)
GitHub (https://github.com/juliend)  pour
partager mon code et
Linkedin
(https://www.linkedin.com/in/juliendubreuil)
 pour mon réseau pro.

Julien Dubreuil (https://juliendubreuil.fr) - Freelance, Consultant et Développeur Drupal (https://juliendubreuil.fr/services) - Copyright

© 2009-2017