How to glue a new scrum team faster
Tags: career, productivity, agile, tutorial
Published: 2019-05-26 13:29:33

---
title: How to glue a new scrum team faster
published: true
description: If you have a new and fresh team, you might struggle to glue people together and make them a predictable scrum team
tags: career, productivity, agile, tutorial
cover_image: https://thepracticaldev.s3.amazonaws.com/i/4pvp5dfnjdjlh6iy51tx.jpg
---

>This is not entirely only my idea, originally it comes in collaboration with Hannes Kockro, a scrum master I had a chance to work closely in the last 2 years. 

There is one variable which is true for every scrum agile team setup: “Time cannot be shrunk or stretch”. All the other things can be changed and adopted in order to make our scrum experience better or worse. If we concentrate on improving, every scrum master will give us three recommendations or guidelines based almost purely on empirical data.
This is the most common recommendations:
- The team should probably consist of 5 to 9 people.
- Timeframe for sprint should be one, two or maximum three weeks, while 90% of scrum teams doing it in 2 weeks interactions 
- The team has daily meetings, and sprint retrospective/review meetings at the end of each sprint interactions.

###Ideal scenario
Idea behind is to fix timeframe, allocate people and execute a plan for one sprint period. Ideally, after one sprint period team gather and conclude that they achieved all goals. (figure 1)

![Figure 1](https://thepracticaldev.s3.amazonaws.com/i/b4oaqvm05ztw07tjydng.png)
<figcaption>figure 1</figcaption>

###Realistic scenario
In the non-ideal world, during the sprint team has obstacles, issues, uncertainty, unpredictable behaviors of the component they do not have a control on. All of this lead to more realistic expectations of a scrum team, which allows a tolerance of +/- 20% of planned complexity (figure 2).

![](https://thepracticaldev.s3.amazonaws.com/i/3xjifyh0hfce5xgn2an5.png)
<figcaption>figure 2</figcaption>

###Just established team
Everyone who ever tries to establish a new scrum team, or add/subtract multiple team member, faces the very same issue, the team can’t even achieve +/- 50% of accuracy. Freshly established scrum team have a lot of “unknowns”, team member do not know each other, the product itself is unknown or some team members have still very little knowledge of it. 
What is initially happen is high fluctuation which goes all over from +/- 100% of accuracy for the first couple of sprints, and then it starts to stabilize around the +/- 20% belt (figure 3).

![](https://thepracticaldev.s3.amazonaws.com/i/9ph8q7l0r2l1p8z84im3.png)
<figcaption>figure 3</figcaption>

Basically, on figure 3 we see, that team struggled first 10 sprints to understand and take in consideration their own capacity. After that period everything starts to stabilize inside +/- 20% belt (from 80% to 120% in this case). 

###Solution
By looking at this image it is not hard to understand that for the accurate and predictable team we need 10 sprints which length is usually 2 weeks, which gives us 2~3 months for the team to establish. 
With every interaction, the team had a chance to sit together and discuss what went wrong, what they did good, propose something new and trying out. And that is the major thing which brings the team to better accuracy. With every retrospective, the team gets closer and closer to their desired accuracy. 
Not every retrospective brings a golden solution, or make a “click” for everybody in the team, but every time, the team tries, with or without success. And finally, after 3 months (10 sprints) they can call themselves predictable.  
But there are still variables in this equation, which we can adjust in order to get the desired outcome faster. If we saw that team need 10 sprints to establish, why not change the duration of the sprint for one week, instead of two? Figure 4 is a chart of the velocity for the same amount of time (30 weeks) like figures above, with the difference that first 10 sprints was one week framed (colored yellow), while others were 2 weeks. 
With pushing the team every time into retrospectives while they still glue together, you create a room for constant improvement on a weekly basis, nobody has to wait 2 weeks to ignite some topic, a team member can try out new methods with less worry for failure.

![figure 4](https://thepracticaldev.s3.amazonaws.com/i/20gyp2one21a8okmtbac.png)
<figcaption>figure 4</figcaption>

###Conclusion
Therefore, the conclusion can be that, if you struggle to operate through big team change, or just formed a new team, give this method a try and you will see that you can speed up team glue just by repeating interactions. The new team member does not know each other well, retrospectives helping them to connect, feel each other, understands others pain.