How to Train a High Performing Team Using Scrum

How to Train a High Performing Team Using Scrum

The fact of SCRUM: It’s lightweight, easy to learn, but tough to master. Also, it’s application can vary from business to business, from company to company. To increase the efficiency of the process, and get the most out of the team, every Scrum Master has to inspect and adapt their approach constantly. And while achieving results using Scrum is not that difficult, setting up a stage for those successes is a whole different ball game.

If you are reading this, you are probably in the midst of the following situation: your company has either decided to implement Scrum or has been using Scrum for some time, but things just haven’t been working out. There is a team you should be training: a team of highly capable experts who simply haven’t warmed up to the idea that their work should be determined by Sprints. Either they are not familiar with the concept, or are unwilling to accept the change of the existing order. Anyway, it is up to you to persuade them to accept the new framework and turn them into high performing team.

In this case, the best advice would come from a certified Scrum Master. However, those are scarce and rather hard to come by. Right? Well, no… We managed to find a few and ask them for their advice on the matter.

Disclaimer: If you are new to the idea of Scrum, this post - quite frankly - is not for you. You can, however, get in on the subject by studying The Scrum Guide. It’s quite short and very well written, so you should catch on rather quickly.

The obvious basics

Before you get started:

  • Determine if the team to are supposed to work with - is actually A TEAM: There are four stages every team goes through (Forming, Storming, Norming, Performing) so depending on the stage the team is, you should adapt your approach. A team that is in its forming phase may have trouble collaborating, but will most likely accept a particular framework as they have no preset preferences. On the other hand, a closely-knit performing team will already have established rules and patterns all members are accustomed to, which is why, in this case, introducing Scrum may be a bit difficult.
  • Emphasize the benefits: If the team is reluctant to accept new framework, just point out all the benefits it reaps. By that, we do not mean benefits for the company, but the benefits for the team and each individual separately. Your primary emphasis should be on constant process adjustment and obstacle removing - two main duties of Scrum Master. The real team doesn’t care about working less - all they care about is doing a good job, properly and effectively.
  • Finally, Scrum is about quality, rather than quantity: Try to shift your team’s focus from the amount of written lines of code to the quality of the product (or product’s part) at the end of each sprint ends. Product Owner will not be satisfied with 1.000 lines of spaghetti code, but will gladly accept 50 lines of top notch software. Make sure that the team knows that.

After The obvious basics, there are advanced techniques to apply when forming a high performing team using Scrum. Instead of scouring the internet for existing content and advice you’ve already read, we turned to actual Scrum Masters for their advice on the matter.

Three different masters have given us their insight and approach they use to train high performing teams. These are their answers.

Shu Ha Ri model of “Agile Corner Consulting”

According to Bojan Spasic the owner, founder and chief agile coach at Agile Corner Consulting, training high performing teams using Scrum requires an approach similar to Shu Ha Ri approach.

Highly performing Scrum teams do not happen overnight. Just like in Shu Ha Ri, there are three stages every individual should go through to:

1. At first stage team learns the basics of Scrum and strictly follows the rules;

2. At second stage team members can copy and collect methods of other masters;

3. At the third and final stage, the team has mastered the Scrum skill and can alter the process as they see fit.

However, for this to work you would need to hand pick those who know their stuff and are experts in the field. For this to work, you would need to carefully craft and develop the team. Since Agile frameworks are all about trust, you will have to make sure that they have proper environment and all the support they need, help them to understand the goal (or support them in developing it), and trust them to get the work done.

Scrum is an empirical process framework, not only for team members but for as well as Scrum master as well. By utilizing short iterations (sprints) and through transparency, inspection, and adoption adaptation, you will increase both process, as well as and team effectiveness. It will enable you not only to deliver the high-quality product but will enable you also to train get a high performing team through constant process tweaks improvements. Finally, as a Scrum Master, it is up to you to support team in selecting and implementing whichever tools needed to collect and implement a new tool that will help the team maintain to constantly improve their effectiveness.”

Three pillars of team training at “AndPlus”

Jonathan D. Roger is an operations director and a certified Scrum Master at AndPlus. His company creates high performing teams by relying on three pillars:

First pillar - the culture of trust

One of the most important things we did to help our teams become high-performing is to remind them that Scrum is only a framework and not an all-inclusive system. It's specifically designed to ensure that teams can work in the most effective way that suits them, without trying to set up a one-size-fits-all rigid process.

Second pillar - constant improvement:

Our Scrum Masters work very hard to help and coach teams to find areas of improvement, even for teams that already consider themselves "high-performing." I've had the experience in the past of established, high-performing teams thinking that they don't need regular Retrospectives or project postmortems -- it turned out that these teams tend to slip back into lazier habits and lose efficiency as a result.

Third pillar - an honest feedback:

A lack of fully open and honest feedback can kill a Scrum implementation in its infancy. Some organizations that practice Scrum consider retrospectives to be the time to say what the Scrum Master and Product Owner want to hear, rather than tell the truth. Also, without true inspection and adaptation, no team can become high-functioning.

Hybrid process at “MarketGoo”

Jaime Muñoz, a Scrum Master at MarketGoo, says that all new hires have to read the scrum ‘theoretical material’ and become the part of company’s ‘Hybrid process.' Also, his company relies heavily on frequent sprint retrospectives.

Hybrid onboarding process

Our process has gradually evolved from being by the book to a hybrid process during which:
1. We planned a weekly sprint with general estimations for completion of workload;

2. Allowed more than a few very large tasks for each sprint;

3. We refrained from using Scrum terminology when presenting our sprint status report to the rest of the team.

Additionally, we trained a non-Dev person (product manager) in our Scrum methodology so they could be our liaison with the rest of the teams in the company. In return, this person trained other new hires from outside the tech team, so they can have an understanding into how dev-teams function.

However, “Hybrid process” we are using at the moment is a little different. Regarding planning (analysis, task breakdown, time estimations), we largely stick to “canonical Scrum.” Also, our status report goes out company wide, with all the correct terminology (data points, average KPIs, velocity vs. capacity, sprint goal, turndown, etc.). As a final result, everyone understands these parameters because they have been trained in the process.”

Constant sprint retrospective

The Sprint Retrospective is critical. I try not to interrupt the process while a sprint is ongoing. However, I do make a note of everything that may not be going right and bring it up during the Retrospective. This way the team assimilates possible improvements better, simply because they’ve seen the consequences of a certain approach. I find it especially important to give every member of the Dev team a voice - that’s how we discovered that 5-days sprints weren’t working for us and since we switched to a 2-week sprint, we have increased overall productivity and quality of work.

Also, allowing only the Product Owner to add tasks on the Production Backlog has also improved our productivity. It turns out that using him as a liaison between the Dev team and the rest of the company has lowered our stress levels.

Finally, a Release Plan is the final touch on maximum productivity and transparency for our team”.

The conclusion

Training a high performing team using Scrum is very similar to using Scrum: basics are obvious, but when it comes to implementation, obstacles appear left and right. Just remember that this is an Agile framework and that constant adaptation is required, so don’t feel downhearted if at first, you don’t succeed. Just determine the length of your next sprint and try to improve on mistakes you’ve made during the last one - simply put, that is how Scrum works.