Agility at scale: what pitfalls should you avoid? [part 3]
In the previous 2 parts of our 3-part series (part 1 & part 2), we focused on the risks associated with deploying the framework at scale, as well as the involvement of stakeholders, whether sponsors or actors in the Agile transformation.
In this third and final part, we look at the risks associated with the often non-agile environment in which this transformation is taking place.
Pitfall#5: Ignoring the non-agile environment
Many manufacturers had to introduce an Agile methodology partially or even sporadically, but very rarely in a comprehensive and coordinated way across the various players in the company.
As a result, it happens (too) often that a team, a project or even a department deploys an Agile method, without having secured its integration with the rest of the company and the constraints that this entails.
Since it is not feasible to systematically push this type of structure to make a complete switch to Agile, compromises must be found by the various stakeholders.
Unfortunately, this often comes down to forcing teams who have implemented agility to adapt their working methods, reporting or framework to the constraints imposed elsewhere.
However, some adaptations are easier to implement and more acceptable than others. On the other hand, if nothing is done, the legitimacy and therefore the survival of the Agile organisation put in place may be jeopardised.
In our view, the main risks for an Agile team working in a non-Agile environment are as follows:
- The company can impose milestones (e.g. ones of a programme under development), independently of the team’s capacity, thus imposing an expectation of results at specific moments in the project.
- Our recommendation: since it is not possible in principle to free yourself from this constraint, you need to be as honest as possible about the framework to which the team is constrained, without making them believe they can deliver completely autonomously with a totally flexible scope. The target is this milestone, and autonomy and empowerment as described in the agile framework are possible, provided that they are in line with the expected maturity.
- Our recommendation: Although this goes against Agile principles, adapting the length of the PI Planning according to these constraints can be a fairly simple adaptation to avoid additional risks such as changing priorities during the course of the PI. In addition, it is necessary to create meeting points with stakeholders who are not organised in SAFe in order to synchronise the different teams.
2. The sponsors, generally senior managers of the company , manage portfolios of projects on a regular basis and in an often predefined format. Working within this framework is essential if you are to secure good support from them.
- Recommendation: make proposals regarding the form and frequency of information and decision-making. The top management in question may also appreciate being challenged and having a different kind of reporting from what they are used to. Why not invite them to an Agile Demo?
- Recommendation: whatever happens, integrate this reporting into the Agile backlog, so that it is considered by the team as a task like any other, even though it does not add value to the product.
3. Agile methods can lead to a lack of understanding or visibility for people outside the project, whether they are customers, suppliers or simply interface partners, who are unfamiliar with them.
- Recommendation: Go through an on-boarding phase of these contacts, then proactively involve them in the rituals put in place, to avoid having to take specific actions, always in response to their requests, for each of them.
Conclusion
Being aware of these risks and the being able to guard against them are key success factors in the deployment and application of an agility framework at scale.
Implementing a SAFe framework is more than just a fad in this age of working more efficiently, more quickly and in a more agile way. In fact, its implementation lasts over time, even if it means making it evolve or adapting it to the specific context of the company.
Despite this, it is important to bear in mind that there are pitfalls to be aware of when implementing. They can jeopardise the model’s effectiveness, although its implementation roadmap only addresses them in a fairly simplistic way. That’s why we’re proposing to work with our customers using best practices and recommendations, which are summarised below:
- How can you avoid enduring the deployment of a SAFe framework? On the one hand, by involving the sponsors and management in the transformation, to promote it and stay connected with the reality on the ground. On the other hand, by not neglecting the change management effort, and by starting well in advance of the project.
- How do you face the reality of a deployment / implementation on a complex physical product (vs. software)? This involves identifying impacted areas and business lines (particularly those directly linked to the physical product), adapting the SAFe model to the constraints of the company, and combining it with project management methods when the framework is not explicit. It is essential to give meaning to the transformation in order to engage and motivate the teams in line with the company’s culture.
- How can innovation be taken into account? Innovation is not an option: teams need to feel free to innovate, with dedicated time and without pressure from management, which should on the contrary encourage it. This effort to innovate must become a factor of recognition for the teams. Using specific methodologies for innovation should help getting the best out of teams, even if this often requires external intervention.
- How can the voice of the customer be heard? Particular attention needs to be paid to identifying and involving customers. In particular, we recommend setting up regular exchange forums between customers and Business Owners in order to establish a BO community and a global consistency, to be able to compare points of view and to gather feedback from future users.
- How do you integrate with non-agile environments? Transformation often has to be integrated into business processes or rules that are not linked to an agile environment (e.g. imposed programme milestones with strict expectations, regular reporting required by top management). Transparency is therefore essential with SAFe-structured teams as regards their autonomy, which is possible but constrained. Proposing a different type of reporting from the expected one, at least through Agile demos, is a way of reconciling the top management’s expectations with the agile organisational mode.
Read more
