The journey to small, cross-functional, Agile teams
How do you transition a large, homogeneous web team to a cluster of small, cross-functional Agile teams?
2014 saw us transition from a large, established web development team of 50+ to smaller, cross-functional pods operating in an Agile Scrum environment.
Here’s what we learned along the way.
It takes a lot of planning. This time a year ago (January) we started the planning, it wasn’t until mid-May that we made the move. There were so many factors to consider - what pods were needed, what roles were needed in each pod, how would we measure the success of the pods, how would we transition existing work, how would we allocate work and finally who should go in each pod?
Collaboration is key. A group of senior managers worked together with a number of the web team and our People Team to evolve the plan. Involving members of the team meant we had ambassadors when it came to the final, public comms. We were also able to predict and address some of the questions which came up in advance.
The right mix is important - the roles, personalities, level of experience and skill-set. It’s important to get this right so that the pods have the greatest chance of early success.
Communicating to the rest of the business. Whilst comms in the web team itself were good and well received, it is probably fair to say we didn’t do enough of this to the wider business. We had sent communications out and made a video on pods, but clearly more was needed for everyone to fully understand the changes and how it would impact them. More than one person thought the pods were the little red meeting booths we have peppered around the business! Oops!
Getting the balance right. We had geared our pods around our strategic themes and whilst we did have a trading pod from day one, we under-resourced this and had to address the problem later on in the year.
No such thing as a clean cut-off. It took about a month for all existing dev work to be completed - so whilst people had physically moved into their pods there was a period when they were still working on old, non-pod, project work. This was frustrating for all concerned, but unavoidable.
Testers make good Scrum-Masters. We didn’t have 6 ready-made Scrum-Masters to hand but we invested in some of our Testers and they have made excellent progress in their new roles.
Velocity will slow down at first. This will happen, and did happen. You have to accept this as inevitable when you are making such a transition and people are new to roles and a process. In our case, people were also transitioning to new platforms and languages so a double-whammy.
People are hungry for data. We observed a hunger for data from the pods early on - the pod structure seemed to increase the interest in metrics, perhaps because there was more ownership around what they were working on. They wanted to know how the things their pod were shipping were performing. Having an Insights person embedded in the team was welcomed.
People like owning a piece of work end-to-end. We had some great feedback from the guys and gals saying how refreshing it was to be able to see something through to fruition - whereas previously they may have worked on just one component of a task/project in isolation and they didn’t feel so bought in to it.
Disciplined get-togethers are still important. We recognised this from the outset - encouraging horizontal discipline sets to get together regularly to share best practises and learnings.
Communication and Alignment are critical. Weekly Product Owner and weekly Scrum-Master meetings were invaluable (they still are) to understand what each pod is doing and any implications. Equally the collaboration and relationships built between the PO and SM group proved an awesome mechanism for getting things done, and keeping awareness up.
Consistency as far as UI and style is hard to achieve. Something we are still working on, and will be a focus in 2015, is how to achieve consistency from a UI/UX perspective when disparate pods are working on different parts of the journey. Not a pod specific issue, but has been highlighted more now that we are working in this way.
Do not leave your pod without access to more senior developers. We had a situation which meant our most senior engineers had to work on a refactor, which took them out of their pods. We learned that if you take your senior software engineers out of pods and ring-fence them on another project, leaving a less experienced team to fly solo means the pod is unbalanced and can lead to work being re-done when Pull Requests are later reviewed and rejected by those software engineers.
Product Owners need quality time and sole focus. They also need to be available Once again we didn’t have spare Product Owners lying around, but recognised the role needed to be pretty senior due to the level of accountability and decision-making it would have. So our Associate Directors stepped into the role for the first year - dual-running however is difficult so we have now looked at ways in which we can fill the product owner roles to enable them to step out of the detail.
Looking back at the outcomes - I think we’ve seen:
- more engagement
- more focus
- more clarity
- more interest in metrics
- less context-switching
- a way in which we now have a much clearer view on the ROI of our web people
- more progress towards our strategic objectives, not just trading
- more career opportunities opened up within the web team
What I love the most however is the fact we really do have a web team who are so comfortable now with change, and who embrace new opportunities and are supportive of each other along the way.Tags Organisational-structure, Agile, Scrum