Why service firms need more “Ri” in their teams

Agile Models. Delivery Models. More boxes on a single page that you can shake a stick at. All of them claiming to use agile approaches and processes to maximize the benefit to you and your firm.

None of them talk about outsourcing, or using multiple vendors beyond the typical “make-them-all-work-as-one-team”. Never mind the different cultural mindsets, multiple time zones and that teams from outsourcing providers are generally put together at the start of a project/engagement and have a revolving door of people joining and leaving the team every few weeks.

Different team members may also be at different stages of the agile journey. A popular way of measuring progress is the ShuHaRi. A short description of the 3 stages from Martin Fowler’s blog is below.

• Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
• Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
• Ri: Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

Most teams when pulled together are in the “Shu stage”, and never get much better.

The challenge for most service firms is doing delivery — or at least delivering the outcomes as if the teams are in the “Ri” stage. After all, who would not like their teams to deliver not just outcomes, but improvements with a proactive mindset and achieve high alignment with customer goals.

The problem is that the “revolving door” gets in the way. People quit (try looking at attrition metrics across top service firms for 2019 — most of them cross the 20% mark) for various reasons- bigger paychecks, no unique proposition to hold them to their current managers/employers, no environment that challenges them and no people engagement within their organisation. With scale, the problem is only aggravated as innovation in any of these areas is even more difficult. There are rules for everything from travel to team lunches. As an example, try moving the seating arrangements on an ODC floor (offshore development center) from straight lines to teams sitting together in open areas and see what you run into (I have). Or promoting an associate who is on maternity leave (and hence on the bench list).

So if we cannot retain our people (or our ability to do so is limited — more on this in a different post), how do we make our teams deliver at an above average level?

When you cannot hire the top 10 percentile, but have to deliver in the top 2 percentile? Sometimes the team barely settles into a cadence before changes take place making it a case of two steps forward, one step back.

For me, the approach that has worked is forming the team with at least one (if not more) team members who have a “Ri” level of expertise — team members who think using iterations, experimentation and a tendency to build one piece at a time using intensive collaboration and discussion for the initial quick wins as well as the long term habit forming that a good team requires. They should be also capable of holding up the important questions that foster culture, such sa “Why are we building this?” “What value do we expect to deliver?” “Which of our available design choices are likely to be the best fit?” Such team members are rare, but are definitely trainable. They do not have to be the best technical staff, but definitely need to be in the right mindset to set the team up to succeed quickly.

Once a team gets into the right habits, the “Ri” teammate can move into other teams to set an example which others slowly get to that level.

Have you seen this problem before? How have you managed changing teams? What techniques and approaches have you used? Please do write to me or leave a comment to start a discussion.