- Training Calendar
- DevOps Accelerator Program
- Live Online Training
- At A Glance
- Our Team
Back when I first started as a Scrum Master, in 2014, I was given a chance that some Scrum Masters are rarely given. I was given an opportunity to do an agile experiment. When I say “experiment” I do not mean make incremental change. I was able to take a team and try something that their managers were not exactly comfortable with. I called it The Sticky Teams Initiative.
I was working for a medium-sized company that had recently started its Agile journey. Quite a few concepts had been taught and were in practice. Scrum was all the rage here and so was velocity. I was working with a couple of different teams at the time One of those teams was a quality support team that would take in tickets from customers and resolve them as soon as they could based on priority and severity. I was there to help the team establish their practices and gain an understanding of Agile.
Note: You may have noticed two items above, velocity and working with multiple teams. I do not like leveraging velocity and feel that a Scrum Master working with too many teams is detrimental. For more read: The Scrum Master and Too Many Hats
As I worked with this team I started to notice that their throughput fluctuated quite a bit. They had been working together for some time but could never seem to settle into a groove.
So I took the stance of an observer. I watched the team closely to see their day-to-day work. I noticed something rather strange. The team never stayed consistently the same size.
Due to being a quality assurance team they were well-versed in numerous aspects of the products the company made. Typically this is a good thing. In this case, it was both good and bad. On the good side, the team functioned well as a quality assurance team since they could take on a vast spread of work without having to go to other teams for assistance. On the bad side, the knowledge and skill the team had caused members of their team to be periodically pulled onto other teams.
Enter The Sticky Teams Initiative. I was fortunate to have a manager who knew the importance of trying new things and experimenting. I worked with them to make sure that my sticky teams initiative was accepted not only by the engineers taking part but by the engineering manager who did not see the benefits. We worked out that the engineering team would be trying this out for 3 months. If we were unable to show positive results, they would go back to functioning as they had before the experiment.
To begin the experiment I worked with the team to establish that no one was to leave the team to work on another team. There were circumstances where a team member may need to move to another team. Those circumstances needed to be a bit extreme. Once we established that, I made it known that should any requests come in that would involve a team member leaving that I would be happy to be the one to review the request. I would be “the bad guy” who says no.
The experiment carried on for 3 months. Throughout that period the team continued to take on work as they had before. They would also run bi-weekly retrospectives to see what they could improve upon. (These retrospectives were a part of their routine before the experiment) While all this was happening I was collecting data.
After the 3 months were done there was only one thing left to do. Pull all the data together and present my findings. Sure enough, the team showed steady improvement in comparison to the time before the agile experiment. Prior to the 4th sprint (when the experiment began), the team’s average velocity was never what they actually got done. Either they would get more done or less done. It always fluctuated from above to below.
After the start of the agile experiment, their velocity normalized and even started to level out. That may not seem very exciting but back in 2014 this was very exciting for the team and management to see. They felt more confident in their ability to deliver and saw that they could steadily improve over time.
From here the team was able to stay relatively “sticky” throughout my time with them. Occasionally a team member would be promoted or would switch to a different team prominently. These are events that are difficult to avoid. But with their newfound confidence, they took each change in stride.
|cookielawinfo-checkbox-analytics||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Analytics".|
|cookielawinfo-checkbox-functional||11 months||The cookie is set by GDPR cookie consent to record the user consent for the cookies in the category "Functional".|
|cookielawinfo-checkbox-necessary||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookies is used to store the user consent for the cookies in the category "Necessary".|
|cookielawinfo-checkbox-others||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Other.|
|cookielawinfo-checkbox-performance||11 months||This cookie is set by GDPR Cookie Consent plugin. The cookie is used to store the user consent for the cookies in the category "Performance".|
Leave A Reply