The Times News were on a journey to re-platform their system. While working diligently behind feature flags, using elements of Scrum, it wasn’t clear to the stakeholders the value being delivered and how well the teams were progressing towards their end goal.
After reviewing the portfolio, the programme leadership team (PLT) recognised they needed to strike a balance between moving towards the proposed technical platforming and delivering valuable features for the business and readers.
Rather than dictate to the teams the PLT agreed they wanted to develop a culture of ownership. The hypothesis was: if the teams have some stake in defining the work they will be much more motivated to work on it.
The PLT commissioned a team comprising of the principal engineers and product owners to develop a set of feature proposals that would roughly fit within a quarter and satisfy the aims of the portfolio. The output of these sessions were vision cards and the skill set required to deliver such as iOS, Android, etc.
The temptation existed to take the skills list and feature proposals and redistribute the staff across each. It was so great that an initial model of assignment was created but quickly discarded. The PLT were eager to continue with the principles they had started with and wanted to see how far it could go. If they allowed all the staff to choose their own work assignment would it lead to increased ownership?
Origins of self organising teams
It was recognised that a characteristic of the most innovative organisations was the concept of self organising teams.
“A project team takes on a self-organising character as it is driven to a state of “zero information”— where prior knowledge does not apply. Ambiguity and fluctuation abound in this state. Left to stew, the process begins to create its own dynamic order. The project team begins to operate like a start-up company—it takes initiatives and risks, and develops an independent agenda. At some point, the team begins to create its own concept.
A group possesses a self-organising capability when it exhibits three conditions: autonomy, self- transcendence, and cross-fertilisation.” (Nonaka & Tekeuchi, 1996)
Self organisation in agile teams
This has become the cornerstone of agile teams, especially teams following the Scrum framework, which were an attempt at moving away from Dilbert-esq environments to ones that actively supported engineers.
“Development teams are structured and empowered by the organisation to organise and manage their own work. The resulting synergy optimises the development team’s overall efficiency and effectiveness.
Development teams have the following characteristics:
They are self-organising. No one (not even the scrum master) tells the development team how to turn product backlog into increments of potentially releasable functionality.” (Sutherland & Schwaber, 2017)
Implementing the self organised re-org
To help with the facilitation of the event we organised a first round selection with the product owners, scrum masters and principal engineers. By having these people allocated to the teams for the main event it was felt it would help with the sales pitch and general organisation. These people then identified “vacancies”, essentially the number of developers and associated skills needed to deliver against the vision.
They were also tasked with creating “Posters” capturing the vision, goals, benefits and vacancies for their team to be used at the main event.
Some business constraints were identified; the architecture team needed to remain as is (we had very specialised people in that team who we couldn’t afford to lose); a mixture of senior through junior skills and experience needed to be spread across each team and PLT had final say if we got to a deadlock. We also documented rules of engagement to help ensure the event ran smoothly. We outlined a clear agenda with a set of rules to help the event run smoothly.
We planned to hold the event in a large room with the posters for each team on the walls with each team’s PO to present a sales pitch to the programme about why people should pick their team. The team were then to pick their name card up and find a vacancy in one of the teams and stick their name card to the vacancy.
Easy!?
Kicking off the event was the head of product, who gave a brief keynote describing the need to focus on getting product to market and several key metrics of success. This was followed by a short overview of the event process and the constraints.
Each product owner presented their sales pitch and then the self-organising began. For the majority of people, it was very easy to pick their team and most found a new home within a couple of minutes. Indeed, many people picked as we might have predicted. 3 or 4 proved problematic, which required some difficult facilitation after team members were not able to resolve themselves. Ultimately the PLT had to make the final decision.
Lessons learnt
- There were a number of people who for whatever reason could not be there in person for the event which was primarily planned to be facilitated face to face. Next time we would allow for more preparation for remote staff to understand how they participate.
- Continually sharing the vision for the product and the aims of the business is essential as this seems to atrophy in people’s minds over time.
- Ensure the skills and minimum number of people required for each team is crystal clear and doesn’t change through the session.
- Have a trial run with the scrum masters to help them understand the facilitation challenges specifically around resolving conflicting allocations. Also, a single master of ceremonies would have been advantageous.
The authors
Lucie Dow is a programme manager in The Times technology team. If you’d like to be part of the team at The Times check out our vacancies page.
Paul Grew is head agile coach and a professional Scrum trainer at Agility In Mind; helping organisations and teams adopt lean & agile principles.
Bibliography
Nonaka, I., & Tekeuchi, H. (1996). The New New Product Development Game. Harvard Business Review.
Sutherland, J., & Schwaber, K. (n.d.). The Scrum Guide.