They say that teamwork makes the dream work, but what about when the dream is colossal, affecting multiple sites, countries, teams and divisions? How do you retain that decentralised, flexible and collaborative approach to development when the team is over 100-strong? What if the cycle is so complex that it has to go through different touchpoints countless times, resulting in a confused game of Chinese Whispers? What if the environment you’re working in is highly regulated or high risk, with reams of red tape to negotiate? What about when there are lots of exec stakeholders weighing in, or none at all? How, on earth, do you tackle Agile at Scale?
Agile is an iterative approach to software development, where solutions are built incrementally through collaboration and constant feedback between independent, cross-functional teams. The project management-centred philosophy emphasises continuous integration, testing and deployment, driven by teamwork and transparent communication. The end result is rapid delivery, reduced risk and improved quality for the customer. Agile at scale simply means applying this methodology on a much wider level – be that scaling it across an organisation, globally, through cross-product projects or high assurance environments.
Many of the principles that define Agile – its emphasis on teamwork and self-organisation, for instance – form the backbone of applying the principal at scale. Agile can be defined as a culture as much as a methodology; scaling up begins by addressing the people behind the process and ensuring that the general principles are adopted and magnified as it expands. By shifting cultural outlook and ways of working, Agile can be made operational, irrespective of the organisation – its scale, size or specialism. To this end, we decided to look out how to apply Agile at scale to get the best from your team in terms of efficiency, adoption of processes and motivation.
1. Team Structure
As Agile scales up, the temptation can be to add a hierarchy to manage the process - often to the programme’s detriment. One of the defining features of Agile is its focus on a delineated management structure, with teams working cross-functionally and in tandem. An excessive structure typically creates boundaries between teams, suffocates work flow and increases work queues as accountability is diluted.
One way to add structure without unbalancing Agile’s equilibrium as it scales is to deploy a project/product forum (or ‘scrum of scrums’) approach. In this model, various multi-disciplinary Agile teams are responsible for discrete, but interdependent projects (e.g. cross-country operations). Each day, each team nominates a representative from within the development team who will also sit on the forum and help to negotiate sprint timeframes, communicate risks or challenges and suggest opportunities for improvement. The forum also serves as an outlet for bubble-up (where challenges are escalated for instant rectification), helping to identify both immediate and repeat challenges that could affect the entire programme in a shorter timeframe. Each representative is an active and valued part of their Agile team with a working knowledge of the nuances of their team dynamic and potential challenges – resulting in more effective and meaningful communications than a traditional top-down approach to management.
2. Executive Sponsorship
That said, Agile at scale simply will not work without buy-in from senior leadership. This may be as simple as nominating Agile ambassadors within your organisation or forwarding an enthusiastic email from your CEO. Education in Agile such as through group awareness sessions, social media promotion, one-to-one or team based mentoring sessions and classroom, e-learning or self-learning courses will help stakeholders to embrace the methodology. This is particularly valuable in Agile at scale, as cross-functional stakeholders (e.g. in finance) become an integral part of the cycle. Stakeholders that champion Agile should be made visible throughout the organisation in order to effect cultural and business change, while stakeholders responsible for a prioritised work item list (i.e. the product owner) should be aware of their accountability to escalate risks quickly and deliver requirements within timeframe. This adoption does start from the top.
While executive management should be handled delicately in Agile – each team should have the independence and responsibility to decide how to deliver the end result – rules and guidelines from above can streamline the process and prevent potential team disputes. One example of this is at Mircosoft, where large-scale Agile teams work to a maximum bugs rules. This dictates that each team is entitled to a maximum of ten bugs per head at any one time. Once the number of bugs exceeds this figure, the team are not allowed to progress their project until the volume of bugs are below the cap again. This approach creates structure, reduces risk and helps each team to prioritise, without impacting their ability to innovate or keep to rapid cycles.
3. Autonomy
Autonomy and independence is a hallmark of the Agile methodology and it is critical to its success that this is not disrupted as it scales. Agile values individuals and their interactions, looking at each team as a holistic and unique unit, as opposed to resource that can be assigned and replaced at will. One of the ways that organisations can scale while retaining this defining feature is through allowing teams to self-organise. By empowering individuals to allocate the roles and skills they need, as well as their ‘representative’ for forums, Agile will be supported organically as it scales. Teams will form their own relationships and ways of working that maximise the available skillsets, while the forum acts as a sort of centralised nexus, where groups can exchange information and skills as required, as well as building personal relationships. This model also resists role assignment and devolution (e.g. assigning one software engineer for each team), instead appreciating the specific skillsets that each team may need, and how this may change from project to project. The team should also be split cleanly, with clear deliverables agreed. Enabling teams to select their own members will ensure that teams identify which people and skills they need to achieve these expectations, as well as providing a platform to raise concerns over available resource or skillsets that could affect project timelines at an early stage.
4. Transparent Communications
Clear, regular, honest communication is the cornerstone of the Agile methodology. At scale, this is made challenging as communications are made through different mediums, remotely and through different touchpoints. Virtual Kanban boards – a tool used to visualise and optimise work flow between teams – are just one example of how communications can be managed even at a distance or cross-functionally. Advances in technology have also enhanced our ability to communicate across teams, and many tools for facilitating Agile at scale can be found on open source. Even at basic level, open forums, instant messenger, video conferencing, emails and phone calls all offer options to stay in touch with different Agile teams – some organisations even end each sprint by posting a blog or vlog summarising the risks and output of the activity on internal wiki-style websites. Staying in touch has never been so easy. This also provides a record of previous activity, protecting legacy information and providing a quick catch-up guide for new starters. Where multiple teams are involved, it can be helpful to define roles early on. A ‘team charter’, defining the purpose, structure and culture of each unique team can be created and made available to all other teams to aid this. This ensures that a clear understanding and expectation is placed on each team ahead of each project.
Delivering Agile at scale is not a simple task. It requires mass organisation, orchestration and communication, but also cultural empathy and understanding; stringent control and obsessive accountability of risk, but also flexibility and trust. Our recommendations barely chip the surface on what is – for all intents and purposes – a multi-faceted methodology. However, Agile at scale is not impossible. With the right foundations in place – the people, their relationships and the structure – all else will follow. It is our nature to form communities, bridge cultural gaps and work together to form a stronger whole – this is the fabric of our society. And at the end of the day, Agile is nothing if not a people-centred software development methodology.
We are currently partnering with a number of leading organisations who are paving the way for Agile at scale within challenging and highly regulated environments. We have supported these clients to deliver workshops and events on the challenges and rewards of delivering Agile at scale successfully, and we’re always keen to hear alternative perspectives or fresh ideas. If you’re interested in attending a future event, learning more about Agile at scale or simply finding out more about opportunities in the market, you know where to find us!