Agility at scale: what pitfalls should you avoid? [part 1]
The use of Agile methodologies, and in particular Agile at scale such as the SAFe framework – which is the most widely used organisational model – Is becoming increasingly common within the engineering departments of major manufacturers, and no longer just in the context of software development. Many manufacturing industries have chosen to implement these working methods in order, among other things, to combat the lack of communication and synchronisation between their teams, and to arrive more quickly at mature and exploitable concepts, prototypes or results.
Why implement a SAFe model? Just a fad or real added value?
Over and above the questions that are probably divisive, we would like to focus here on an operational issue linked to its application in an industrial context. The SAFe framework is made up of a coherent set of elementary building blocks that describe what is expected at each stage and answer the following questions:
:
- How do you put together the teams, the trains, the solution trains ?
- What routines are needed?
- What are the associated roles and responsibilities?
- How can the interactions between the various stakeholders be managed?
- How do you support and develop skills?
These are all questions that need to be answered, adapted to the company’s context, in order to be able to deploy under the right conditions, with the risk of neglecting one of the building blocks or prerequisites resulting in an organisational model that is neither relevant nor functional.
Based on our various experiences in the field, we will attempt to highlight the types of frequent pitfalls to be avoided in order to guarantee an implementation that exploits the full potential of the SAFe model. The pitfalls presented will focus on different areas:
- Imposed or endured deployment of the agility framework at scale
- More complex implementation in a context of physical product development (as opposed to software implementation)
- The impact on innovation, which is not given enough room or may even be completely neglected
- Links with the various business lines and business owners to ensure that the customer’s voice is heard
- Implementing an Agile methodology in a non-Agile environment and mindset
Pitfall#1: imposing (or enduring) the deployment of a SAFe framework
The SAFe model suggests a gradual, train-by-train roll-out.
Particular attention needs to be paid to the change management aspects of this profound cultural change. What is generally true with all projects and progressive roll-outs is all the more true in a context where a SAFe framework is being deployed on a massive scale: preparation at a very early stage is essential to increase the chances of success. So, impact analysis, identification of sponsors and the right profiles for each role, taking into account the specific characteristics of the company, preparation of a communication plan and a training and skills development plan are all elements that need to be in place before deployment begins.
Of course, massive deployment involves a major risk: if the model must be adapted, for whatever reason, the adjustment work is all the more consequential and painful.
In addition, the lack of involvement of sponsors and management in transformation projects often proves disastrous for their success. This lack of involvement can manifest itself in two ways:
- Not having the commitment of management with real sponsorship takes away all the strength of the approach in the Agile mindset (inspired and inspiring leaders). The perceived message is that this deployment is not a priority for management, who prefers getting on with tasks that seem more rewarding. As a result, it is important to have a highly committed middle management team that acts as a channel between top management and the operational teams.
- Conversely, not involving management, for example by not inviting them to the rituals put in place to ensure that information is shared on the progress of work and to gather their feedback (e.g. demos, Inspect & Adapt), can lead to a feeling of disinterest in their work on the part of the teams, and on the other hand to opacity and a risk of a two-tier organisation.
An Agile deployment, especially if it is at scale, needs to be supported by the right level of management if it is to have a good chance of success!
Pitfall#2 : not taking the measure of a deployment / implementation on a complex physical product (vs. software)
Since agility initially emerged in the software world, its implementation in the context of software development projects takes on its full meaning with increased ease to deliver incremental value to customers, through MVPs (Minimum Viable Products) and then Product Increments.
With the development of increasingly complex physical products (e.g. defence, aeronautics, space, nuclear, automotive…), development and integration cycles are much longer. Several parameters can simply explain this:
- The involvement of different interdependent business lines that cannot always work in parallel: modelling, drawing up plans, creating and reviewing digital mock-ups, time-consuming simulation phases, etc.
- Long, incompressible industrial processes, whether in the prototyping, manufacturing, routing of elementary parts/equipment or assembly phases.
- The availability of the technologies used by a handful of specialist suppliers that they alone have mastered, creating a latency in supplying their various customers.
- LThe complexity of industrial organisation: the impact is all the greater when a company’s organisation is split between different centres and/or countries, as may be the case for European manufacturers such as Airbus, whose sites are spread across Europe, making it virtually impossible to co-locate teams (unlike Boeing, whose engineering and production centres are centralised in Seattle). Added to this geographical complexity are the problems of extended enterprise with its suppliers, and all that this implies in terms of confidentiality, data exchange and collaboration in the broadest sense.
- National and international regulatory constraints, which are less predominant in most software development, and which can add additional lead times.
All these parameters represent additional obstacles to large-scale deployment and agile transformation. However, these obstacles are no blocking factors, and can be overcome by implementing a set of best practices. It is nevertheless necessary to anticipate them upstream when framing the transformation at scale. Our recommendations are as follows:
- Clearly identify the areas and business lines targeted by the transformation: the obstacles mentioned above are more significant when considering professions linked to the physical product (prototyping, industrialisation, production), which is less the case for professions further up the value chain in the development and design phases.
- Encourage modelling and simulation in the upstream phases of architecture and general engineering in a localised manner on sub-systems in the domains and business lines, enabling shorter and more regular simulation loops to adapt to SAFe’s schedule.
- Organisational models of agility at scale, such as SAFe, are not very explicit when it comes to applying them to hardware development (for example, DevOps developing a Continuous Delivery Pipeline to enable Release on Demand), so we need to be able to draw inspiration from the basic building blocks of the model, making the most of their roles and responsibilities, routines, etc. to adapt them to the company’s particular context and combine it with another project management method (e.g. V Cycle).
- Enfin, donner du sens à la transformation est primordial afin d’obtenir l’adhésion des équipes, tout en montrant que la culture et la réalité terrain de l’entreprise sont bien respectées, sans donner l’impression de déployer une méthodologie sur étagère. Avoir des individus engagées et motivés est clé ! Cela peut se décliner de différentes manières : renforcer la collaboration pour mieux maitriser les interfaces (à travers des points de synchronisation réguliers par exemple), maitriser les plannings grâce à des engagements à court terme permettant de voir et estimer la valeur produite, ou encore capter régulièrement les retours clients pour s’assurer d’avancer dans le bon sens et de livrer le bon produit.
In this first part of our 3-part series, we focus on the risks associated with the deployment phase of an agile framework at scale.
In the second part, we will look at the involvement of stakeholders, be they sponsors or players in the agile transformation, in particular to set up an innovation process which we consider as essential.
Read more
