It’s coming up to 4 o’clock on a late summer’s afternoon in London. We’re gathered in one of our ‘collaborative spaces’ at the Vodafone UK offices, and deep in the final stages of our sprint retrospective. If you listen carefully, you can hear the growl of stomachs as we begin the approach towards teatime; I know I don’t have long before we all lose focus in favour of a brew & biscuit.

As a Scrum Master, you know a valuable retrospective needs some valuable takeaways. This last section is my opportunity to bring them into land, so I steer the team towards that all-important question:

“What could we do in the coming sprint(s) that would make the biggest difference?”

There’s a moment’s pause. I wait, sharpie and post-its in hand, watching those thinking faces. A brave team member breaks the silence:

“We should definitely do more T-shaping”

There’s a resounding murmur of agreement and I feel a sigh of relief as the squad make that final stride over the retrospective finish line – they’ve uncovered a valuable takeaway!

Then my heart sinks.

Here’s the problem: in numerous retrospectives over the previous 12 months, the team have highlighted T-shaping as an initiative that would bring tremendous value, yet the actions taken away have been consistently deprioritised and forgotten in favour of the more ‘urgent’ stories in sprint.

I could probably write an entire blog post on my learnings from failed retrospective actions and how I could have coached the team better here, but let’s stay on topic for now.

What is T-shaping?

It’s also known as cross-skilling. Broadening your skill-set so you can tackle a broader range of tasks. If you’re into sport, think of it like becoming a utility player rather than being tied to one position on the field. You can slot in where needed.

Why is this important in Agile teams?

Agile teams are cross-functional by design, allowing them to develop & own products and solutions end-to-end.

T-shaping within those teams reduces single points of failure: "Only John can do that task but he’s on holiday this sprint"

Having T-shaped squads increases the frequency & quality of collaboration: "We both know how that system works so let’s brainstorm together to see if we can squeeze more value from it"

Being T-shaped increases empathy & understanding for one another: "I know how tough that bug must have been to fix, let me help you this time"

Being able to cross-skill meets a need that many of us have to constantly be learning & developing: "I’ve been really interested to learn that new programming language so this feels like I’m really progressing in my own self"

It enables Scrum teams, in particular, to really swarm around a sprint backlog with less friction.

Back to my Scrum team at Vodafone UK

I was in complete agreement that T-shaping would be valuable, but we’d need a big bold action to actually ensure it happened.

I’d had this thought for a while; one of those ‘wouldn’t it be a laugh if…’ kinda thoughts – but what if we had a sprint where no one was allowed to work on their own job?

What if they HAD to T-shape, like it was a rule for the sprint?

Back in the retrospective, I offered a suggestion to the team:

“What if we took a few days out of our normal sprint cycle to do a T-shaping sprint?”

It was met by an enthusiastic nod from the group, and so we wrapped up the retrospective with our T-shaping takeaway. After some planning and calendar configuration between the product owner and myself, we were able to book in 3 consecutive days for our little experiment…

The ‘Xtreme T-Shaping’ Mini Sprint

This Scrum team are a digital marketing team, with a focus on customer retention campaigns & optimisation. If you’re nearing the end of your mobile plan, this team ensures you get a beautiful email/text/MMS/app notification at exactly the right time with a recommendation that’s personalised to you (not a traditional ‘development’ Scrum team, but Scrum has enabled campaigns to be built & deployed in days rather than weeks as they did in the old non-Agile world).

The team is comprised of big data, commercial, design, digital, analytics, copywriting, front end development and campaign operations experts. Bigger than your ideal squad, but we’ve made it work. The T-shaping for them was as much about gaining understanding for the purpose of better end-to-end collaboration, as much as it was for learning new skills.

Sprint Day 1

Rather than sitting at our normal desk area, we gather in one of our ‘collaborative spaces’ for the 3-day mini-sprint (never underestimate a change of scenery for getting the creative juices flowing) and to kick-off, I explain the crucial rule:

“You cannot do any work on your own job at any point."

"You must either be working on a task that’s not your usual role or you may be teaching someone who wants to work on something which you normally do.”

The team look confused and excited at the same time, almost like when a parent surprises their child with a trip to Disneyland.

“Are you sure we can do this?"

"Won’t we look silly or get in trouble for not doing our jobs?”

We kick off the morning with the Ghost Game icebreaker, then go into refinement (breaking the epic down into stories and creating a sprint backlog based on value & effort) and sprint planning.

Around midday, we set off on the sprint and the team begin swarming in pairs around the highest priority tasks; one person is doing/learning and the other is observing/teaching.

[caption id="attachment_2389" align="aligncenter" width="770"]

Xtreme T-Shaping Backlog | Agile Avengers[/caption]

Day 2

During planning, it had dawned on me that the total story points for this mini-sprint came to 158pts. Now this team have an average velocity of 333pts for a 9-day sprint (not including planning, review and retro) and I’ve measured this for over a year now, so it’s pretty accurate.

Per day, that’s 37pts on average.

How on earth are they going to get even close to 158 story points in just two working days?

For a moment I thought I may have set these guys up to fail, but I reminded myself that the point of this mini-sprint was T-shaping. If we had a minimum viable product at the end, that’s a bonus.

However, we’re halfway through the second day and we’ve made a significant dent in the sprint backlog. There’s good flow across the board and no major blockers. I feel one small butterfly waking up in my stomach and think to myself - we might just be able to achieve the sprint goal and get this campaign out the door. Maybe.

Day 3

Sprint review is booked for 2 pm, meaning we only have a few hours to get through the rest of the sprint backlog. We didn’t have a burndown (lesson learnt for me) however from eyeballing the flow across the sprint board, it would have been fairly linear.

It’s possible we might just get this done by the review after lunch.

What surprised me is that we ended up having multiple standups throughout the mini-sprint, as the rate at which the team were swarming around tasks and completing them meant we needed to re-group every couple of hours and re-distribute ourselves based on what needed to be done next and who was available to teach vs. who wanted to T-shape in that skillset.

The level of real collaboration, fast communication and Scrum behaviour was something I’d never seen before.

The team are beginning to feel it too; the mutual support and excitement that this sprint is coming together are almost palpable in the room. I’m desperately trying to keep everyone watered, fed and happy as we enter the closing hour and swarm around those final tasks.

[caption id="attachment_2388" align="aligncenter" width="770"]

The squad T-shaping on day 2 of our mini sprint[/caption]

The Review

We’re gathered for the sprint review, the team demo the various elements that make up our product, and the Product Owner inspects the campaign. There are slightly more incidents of ‘tech debt’ that we’ll need to follow up on in future sprints, but nothing insurmountable.

The Product Owner is happy, the team have met the sprint goal. Success!

I’m calculating some metrics for the end of the review and it dawns on me that this experiment may have given me more than I bargained for...

% Story Points Done vs. Planned = 89%

Pretty good in my opinion. A couple of stories were pulled from the sprint early on once the team realised they were unnecessary for this sprint goal (with Product Owner approval). All in all, this metric shows effective refinement and planning.

Avg. value/day during normal sprint = 1,067 units

Avg. value/day during T-Shaping sprint = 860 units

This caught me out at first, but the reality was the Product Owner picked a relatively low-risk epic for the T-shaping sprint goal - ergo if someone made a mistake then it won’t cripple the business. Low-risk and slightly lower value than the epics we tackle in our usual sprints, therefore nothing to worry about here.

Avg. Story Points/day during normal Sprint = 37

Avg. Story Points/day during T-Shaping Sprint = 61

Hang on.

What?

Yes, those numbers are correct. The team had a +65% increase in velocity during the T-Shaping sprint vs. a normal sprint.

Come again?

"They were +65% more effective, when not allowed to do their own jobs?!"

I check and re-check the story points on the cards; but it’s accurate. The team completed 122 story points over 2 days of T-shaping sprint time (when you remove planning/review/retro time).

My initial hypothesis was that the team would be half as efficient at best when T-shaping, as naturally, one person is teaching (and not working) and the other is learning.

They’ve not only matched their normal velocity, but they’ve also increased it by +65%?

[caption id="attachment_2305" align="aligncenter" width="886"]

Our average story points per day in a normal sprint vs. our average story points per day whilst in the T-shaping sprint[/caption]

The Retrospective

I’d helped a team member design a retrospective specifically for the T-shaping sprint, and another team member offered to facilitate. They both smashed it, and we had one of those retrospectives you only dream about.

All the learnings that I’d hoped would emerge came through powerfully:

• Empathy and understanding for team members who perform different roles.
• Skills development and personal progression.
• Increased team bonding and collaboration.

But the learning that I didn’t anticipate was the learning that brought about this marked increase in velocity, in spite of the obvious T-shaping handicap…

[caption id="attachment_2309" align="aligncenter" width="1024"]

Xtreme T-Shaping Retrospective[/caption]

Focus

This scrum team normally juggle 5-10 epics in any one sprint. I’m well aware it’s not textbook, but there are a number of strategic initiatives that touch multiple squads and unfortunately, this team get it rough.

The organisation is still growing its understanding and application of Agile across multiple teams, and believe me we’re driving that change. However, at the moment it’s not ‘one sprint, one sprint goal’ as we had it over the T-Shaping sprint.

The focus on one epic eliminated the waste caused by context switching.

The focus on one epic enabled more direct communication, as the team knew they’re all working on the same thing.

The focus on one epic enabled more frequent communication as the team swarmed around interrelated tasks on the backlog.

The focus on one epic reduced stress levels as the team could support one another in moving towards the same goal.

The focus on one epic increased team morale as they had clear vision, direction and purpose for this mini-sprint.

"All the above counteracted the T-shaping handicap in such a radical way that the team were +65% more efficient whilst not even doing their own jobs."

The learnings here gave way to a truly pivotal retrospective:

“What if we tried shorter sprints?”

“What if we only had one epic per sprint?”

“What if we did this regularly?”

Not only did this ‘Xtreme T-shaping’ experiment create revelational learnings for the squad, but it has also given me powerful data to take back to senior leaders in the business on how we should do more to empower and enable our teams to ‘focus’ for vastly greater productivity.

Above all, it’s a large stride for my fellow Scrum Masters and I on our mission to empower Agile teams to be the best they can be at Vodafone UK.

Enjoyed this blog post? It is also available in our signature comic strip style for easy reading and sharing. View and download the pdf here.