Large Scale Agile Transformation
By Zenaxys – Transformation | Consultancy | Technology
Agile methodologies have been in existence for more than 15 years. The practices were first introduced in 2001 with the publication of the Agile Manifesto. This article looks at the challenge of scaling the Agile process to program level change, as an initial step on the road to broader organisational deployment.
Due to the success of the Agile approach for smaller teams, many organisations are moving more and more towards agile methodologies and seeking to deploy the techniques on a wider, organisational basis. Scaling of the agile methodology is not yet a well documented, straight forward process and is often harder than expected.
The most popular Agile process is the Scrum methodology. In this process, the central figure of the process is the Scrum master. The Scrum master maintains the Backlog catalogue of requested new features for the product. Priority elements of the backlog catalogue are collected into Sprints for phased delivery. A cross functional team, usually of around 9 people, will be responsible for the full process. This includes definition of new features via “user stories”, development of these features followed by testing and subsequent deployment to a productive environment. The Scrum will operate in a largely autonomous manner, focusing on short term planning and early delivery of benefits. The cross functional team, short sprints and continuous nature, mean this methodology is very well suited for dynamic, fast paced delivery, with frequent changes of priority.
A number of benefits arise from an agile approach and close collaboration within cross functional teams. Communication barriers are broken down, enabling the business to better understand the benefits delivered by new technology and ensuring technologists have a good understanding of the full requirements of the business. Functionality can be delivered earlier, leading to revenue improvements. Incremental delivery, coupled with continuous testing, leads to an improvement in quality and reduction of delivery risk. Higher levels of staff satisfaction and business engagement are also achieved. Most importantly, the “right” product is built and customer satisfaction can be much higher.
When the process is scaled to the organisational level, a number of challenges arise. Firstly, at the organisational level, high level plans are necessary to ensure coordination across teams and departments. For instance, the customer relationship management and sales departments must be aware of material changes well in advance, so marketing plans can be coordinated with the launch to ensure customers are well informed. Most large organisations are geographically distributed. The Scrum communication processes, with daily face-to-face stand ups, do not lend themselves easily to geographical distribution spread across multiple time zones. Middle management often find the transition from a waterfall based organisation to a more agile organisation difficult. With less hierarchy and more team autonomy, the traditional middle manager role needs to be adapted. As an example, Scrum masters must focus on supporting the team and less on micro managing.
A number of methodologies have been developed in an attempt to scale the “Agile” process. However, there is no consensus within the agile community, on which of these approaches to follow. Two of the most prominent, SAFe (Scaled Agile Framework) and LeSS (Large-Scale Scrum), focus on different priorities. SAFe, developed in 2011, defines a multi-layered structure based on Teams (the Scrums), Programs (up to 125 resources) and Portfolios. Portfolios represent a collection of “Value streams”, connected to the enterprise by strategic themes or initiatives. The Teams take items from the Program backlog and align sprint durations to the cadence of the program. A cycle of one innovation/planning period, followed by 3-5 sprints defines the overall program cadence. In this model, there is less autonomy for the Teams, yet stronger program and enterprise alignment can be achieved. LeSS differs in that it is designed to scale to around 8 teams, although a derivative “LeSS Huge” can scale to hundreds of staff. The intention of LeSS is to reduce organisational complexity, by simplifying unnecessary complex organisational solutions. Leading to less roles, less management and less organisational structure. The process is by design “Lean”, with a customer centric view. A “system thinking” approach is also embedded, to ensure a holistic view of the domain remains in focus.
Organisations looking to move on a wholesale basis to more agile processes, would be well advised to consider piloting the process as an initial step. Examples of potential candidate programs would be, platform consolidation projects, large scale regulatory initiatives, or similar programs that involve larger change within the organisation.
Given the relative immaturity of the various approaches, many organisations customise the process to suit the enterprise. Customisations should be made carefully and pragmatically. A simple straightforward approach concentrating on agile values and including provision of initial training and coaching of staff as they learn, can deliver early benefits. Agile at the organisational level, is more of a mind-set than a detailed process. Where possible, teams should be allowed to self-organise, with autonomy at the grass roots level.
When embarking on large scale transition projects in an agile manner, it is clear some form of overarching plan will always be required. A high-level milestone plan, agreed across all areas, enables Scrum teams to retain autonomy for detailed tasks, yet enables alignment across the various cooperating teams within the program. An adjusted program management function can support high level milestone planning, build bridges between teams operating on an agile basis and those with a more traditional approach and provide a forum for ongoing communication. Organisations must also consider the degree of geographical separation to be managed. Scrum teams should, as far as possible, be located within one, or two locations at most. Coordination between teams can be managed by scrums of scrum leaders. However, practise has shown that this is not scalable beyond a handful of teams. Wider coordination across a larger number of teams and geographies, will naturally fall back onto more waterfall orientated approaches, with a consequent higher burden of administration to ensure appropriate alignment. End-to-end test cycles and non-functional testing must, to a large part, be coordinated across the program. This creates a number of dependencies and shared milestones that will feature in the high-level plan.
Adoption of “Agile” for large scale transformation is not simple. However, with investment, organisations can reap the benefits of a more open, dynamic, creative and collaborative environment, enabling greater focus on the client and optimisation of product and services for the client. Once the journey has begun, organisations must be wary of drifting back to old operating models. Visible and strong senior management commitment is required to stay on track and retain benefits in a sustainable manner.
Paul Walsh
Zenaxys