Agility at scale: what pitfalls should you avoid? [part 2]
In the first part of our series of 3 articles, we focused on the risks associated with the deployment phase of an agile framework at scale.
In this second part, we’ll be looking at the involvement of stakeholders, be they sponsors or players in the agile transformation, in particular to put in place an innovation process that we consider as essential.
Pitfall #3: Innovation is not an option
Innovation is one of the pillars of the Agile (& Lean!) mindset. It can even be a differentiating factor in getting the best performance from an Agile project.
A point of view is available on Mews Partners’ website on the theme of “Agility and innovation, from myth to reality”:
Unfortunately, it is all too rare for adequate room to be left for an innovation approach, whether structured (IP Innovation in the SAFe️ framework) or more opportunistic and disjointed.
The most blatant example, which we have come across time and time again from the manufacturers we have worked with, is quite simply not implementing these innovation and planning iterations in the name of securing a roadmap to which the team or management is committed.
« Why wasting my time working on these issues, which are secondary to the value I need to deliver in the short term from my project? »
The articles above can highlight the virtues of this approach.
For our part, let’s focus on the recommendations we can make to secure this innovation process.
Obviously, the easiest way is to implement this structured innovation approach during each PI (Planning Interval ), systematically including innovation iterations. This ensures that the teams have dedicated time to address these issues, which will often be close to their hearts, and give them the desire to surpass themselves.
In our view, three prerequisites are necessary:
1. The teams need to feel free to come up with ideas that are innovative, disruptive and sometimes even completely outside the scope of MFTs. Delivering the backlog and its commitments is the priority for the teams, and this can generate pressure, which needs to be relieved as much as possible during these innovation phases. Dedicated time must therefore be sacrosanct, and taken into account in the backlog estimate, whether during PI Planning (SAFe-type scaled agility), or during iteration planning (Agile Scrum).
2. Specific support, often external, which can take the form of an idea “agitator”: innovation is not a trivial task, and teams are sometimes not very familiar with the concept. There are specific methodologies for getting the best out of teams and their skills, such as Design Thinking, Lean Startup and Open Innovation.
3. Make it an element of recognition for the team, and even for the individual. This is a tricky element, but it can be kept relatively simple: ensure that the team has the opportunity to present the subjects it has worked on at least to its peers, and ideally to a panel of decision-makers. They could then choose to invest time and resources in the most interesting proposals. Setting up an innovation process, or even a dedicated hackathon-type event, requires time and experience. That’s why specific external help may be needed.
4. Finally, this innovation process must take into account the integration and deployment of the selected initiatives, so that they do not remain unanswered, which would be a demotivating factor for the participants, and would compromise the renewal of the experience.
Let’s face it, it seems simpler to have a global innovation approach in a software development logic than a hardware one, quite simply because the results are often instantly visible and therefore generate immediate value and satisfaction. However, as mentioned in this article, innovation can take many forms, and does not necessarily consist in a technological breakthrough.
Pitfall #4: insufficient involvement of customers (or Business Owners)
The SAFe framework is not a self-sufficient ecosystem, hermetically sealed off from outside interaction. .
It cannot evolve properly without the contribution of the Epic & Business Owners (BO), who represent the end customers, guide prioritisation and judge whether the product delivers the expected value. Given that their responsibility is at stake, they must actively participate in discussions with the teams and the Agile Release Trains (ART) and take decisions that directly commit them. However, the lack or absence of BO involvement is often the cause of failure in the development of a product or service that does not meet expectations.
This can be explained by the fact that they are initially poorly identified, with the wrong level of responsibility, knowledge or investment (both financial and technical). It is therefore essential to pay particular attention to identifying BOs, by asking questions such as:
- Who is ultimately responsible for business results? Who has the legitimacy to speak on behalf of end customers?
- Who can give direction to a train (ART) to develop a good solution?
- Who should be involved in building the roadmap, planning activities and solving problems?
- Who can help coordinate activities with the company’s other departments or organisations in an end-to-end approach?
The answers to these questions will help refine the choice of the most appropriate BOs for implementing the framework. The multiplication of BOs, representing different businesses and sometimes different interests, means that a management method needs to be put in place to collect their input data, discuss progress and gather feedback. This can be done either individually or collectively.
Our conviction is to set up a community of BOs, at , if possible establishing a ritual of exchange between them. This allows them to compare points of view and interests and to seek a solution or compromise. A Voice of the Customer methodology can be put in place to ensure that customer needs are captured. This will ultimately lead to a refinement of the backlog.
Resource management also plays a vital role in the successful implementation of a SAFe model. The framework is very clear on the different roles to be filled and their associated responsibilities, enabling the entire spectrum of the company to be covered. In the Scrum agile methodology, it is also recommended to have fixed agile teams with the right number of resources (5-12 people) and the right skills represented to deliver the expected value.
However, under the guise of dynamic resource allocation, we sometimes find that teams see their headcount vary in the middle of an PI to reallocate members to other teams on other projects, putting at risk the delivery to which the teams had committed at the start of the increment.
We note that these radical changes in resources are often caused by:
- Financial arbitration, suggesting that budgetary management has not been adequate
- Under-performance due to under-staffing, which is compensated for by adding resources
In all cases, adaptations to the size of resources in the middle of a PI are not acceptable and jeopardize the foundations of agility.
Let’s go back to Agile best practice: dynamic resource allocation is only acceptable if it is reasoned and limited in frequency (every 2 PIs maximum).
Significant deltas from one PI to another should be the result of exceptional events, in particular major, but rare, changes in strategy involving major growth or reductions in scope.
Team stability is essential over short time horizons (~2 PI): activities must be allocated dynamically, not the other way round.
In the first 2 parts of our 3-part series, we focused on the risks associated with deploying the framework at scale, as well as the involvement of stakeholders, be they sponsors or actors in the Agile transformation.
In the third and final part, we’ll look at the risks associated with the often non-agile environment in which this transformation is taking place, and draw up some recommendations.
Read more
