Against all odds
Agile teams must be co-located to collaborate. They must work on an important product with a long-term future to be motivated. They must work on the latest technology to produce the best results. All mantras that I thought, went without saying.
For the last year or so, I have been coaching in one of the bigger government departments here in Wellington, New Zealand. Although there were many successes, there is one team that really surprised me. The one team that was successful against all odds. First, let me describe the “problems” I saw when I started working with them:
They were a distributed team working in five ocations across three cities – The Product Owner and Scrum Master were in Auckland, one developer was in Tauranga, three specialists and a second developer were in Wellington as were the Tech Lead and a tester, only in separate buildings streets away.
The technology they were working on was old – like in “we are just going to re-platform this” old.
Their product had a limited lifespan – see old technology – they were just supposed to keep the lights on for the public website (one of the most frequently used sites in NZ government) until it got re-platformed.
Most of the technical support was done by a vendor – and we know how difficult engaging vendors can be.
Only the Product Owner, Scrum Master and one developer were dedicated to this team full-time, everyone else was part-time.
My biggest fear was: How are these people going to stay motivated to do a good job? I took the pragmatic approach of teaching them what I knew and letting the chips fall where they may. Now before I go on, I must give a shout out to Rob England, Pete Tansey, Toni Wilson, Paul Tait, Mark Murphy and all the other coaches that have done amazing work at this department. If you sprinkle enough unicorn dust around, you are bound to find one team that takes to agile eventually but I was surprised at the one I found, it looked nothing like what I imagined.
First steps
I worked with the Product Owner, teaching her about maximising value and gaining trust with her stakeholders. I worked with the Scrum Master telling him about being a servant leader (that is always the most difficult part for ex-project managers). And I worked with the team, trying to coach what Scrum is about. Chewing up the work, one mouthful at a time. And like I say to my 10-year old, don’t put so much food in your mouth that you can’t backchat your mother.
A year and a half later, and this team is still producing amazing work. They started by fixing all the broken links on a 16,000 page website and along the way:
Built features that diverted thousands of calls away from the overloaded call centres by providing real answers to real questions
Re-architected the site to make it work on mobile (actually, just to make it work full stop).
Replaced the search engine because the one they had was going to be switched off (apparently Google does not support onsite search engines anymore).
Created the ability to publish urgent content faster, from overnight to within 15 minutes.
Had a go at running an AdWords campaign that became the best performing one in the organisation’s 10-year history of running AdWords
So what was the magic sauce? What made this team tick where others just went off like alarm bells?
Leadership (and here I am going to paraphrase Dan Pink)
The Product Owner
The Product Owner was able to clearly articulate the business value of what the team was doing. This was reinforced by great customer feedback. The team had real customers (like you and me), but also business teams within the department that published content and marketing on the website.
The work they did for internal teams gave them organisational trust to do more ambitious work. She also had an actual budget that she could use.
She was able to point to the “why” behind the work knowing the future of the product was uncertain. It turns out people do not care too much about next year, as long as they are making a difference today. The Product Owner gave the team purpose.
The Scrum Master
The Scrum Master protected the team. Being a certified Project Manager, he kept the sharks at bay and turned many of them into dolphins. He never threw the team under the bus and dealt with most of the organisational bureaucracy. Most importantly, he protected the team from the Product Owner, in a good way. He would be the one to call out that the sprint is getting overloaded, even if the team over-ambitiously wanted to take on more. By paving the way for frequent changes to be made, the Scrum Master gave the team autonomy.
The Tech Lead
The Tech Lead guided the team in the art of the possible. What would be easy? What would be difficult? Along the way making hard decisions, like pulling a change at the last minutes when it might cause a bad customer experience. He was also the vendor that supplied the developer in Tauranga and the tester.
It turns out that if you stop telling the vendor how to do their job and provide a collaborative environment, even vendor come to the party (they are just people after all). The team kept improving what and how they could make changes. The Tech Lead gave the team mastery.
The Team
Personal leadership – every team member played ball. They did stuff when they said they would. They spoke up for the customer when they saw something wrong. They hotly debated the points they were passionate about. They showed passion in the first place!
The How
Release often
Changes were made regularly. At the start, some of the team members were even more sceptical than I was. They had seen it all before. Some new-fangled way of doing things that fizzled out after a month of hot air. But when real changes were being implemented, every two weeks, on stuff that they have been trying to fix for years, everyone got engaged in a big way. The biggest agile sceptic ended up becoming its greatest advocate.
Data led decision-making
They used data. A lot of the changes they made were driven by website analytics and other data. This maximised the impact they had over a short lifespan and gave maximum benefit to real users.
Face time
Empathy levels were kept high through Skype and meeting face to face. Skype was used at stand-ups (which was kind of sit-downs in a meeting room and slightly more than 15 minutes as it was often the only team discussion for the day).
Skype was used during planning, reviews and retrospectives to dial everyone not present in. But here was the catch, the Product Owner and Scrum Master travelled to Wellington for two days every two weeks to attend all the Scrum meetings and they even flew the Tauranga developer down at least quarterly.
For us humans, nothing beats regular face to face communication for ideation and realising a team member is a human and not just some entity in an email chain.
Expertise and experience
It turns out that sometimes it is easier to work with the devil you know. The old technology they were using was well understood and they found amazing workarounds for stuff the platform did not support. I see many teams struggle to make an impact because they are chasing the latest, shiniest tech. I am all for upskilling (that is a major part of my job) but learn in increments and make sure you can still do your day job well.
The real winner
But finally, the bit that amazed me most, was the awesome solutions that the team came up with because business and technology professionals worked together daily. The solutions were much more customer-focused than what I have seen technical teams come up with from a requirement (no matter how prettily it is dressed up in user story format with acceptance criteria, which was what the team used in any case).
And what will the team do on Thursday night after handing over the reins as owners of the main website for the department to the Transformation team (with whom they have worked together patiently for the last six months)? They will go out together to see a movie. Not the first team outing they have had and probably not the last.
