From theory to practice: interests and limits of the Agile method
Information Systems Departments designated as Agile champions in major groups
During the health crisis of 2020, Information Systems Departments were called upon to speed up digitization.
This function, which is focused on digital innovation, cost rationalization, data exploitation and security, has had to rethink the digital experience for employees and demonstrate greater agility.
In fact, the Agile method was acclaimed by the leaders of major groups after the crisis, and this was followed by significant human, technological and financial investment:
- creation of shared services, such as CoEs (Agile Center of Excellence) or departments bringing together all the organization’s Product Owners
- implementation of tools to facilitate exchanges (ProductBoard, Mural, Jira Altassian, Teams, etc.),
- recruitment of Agile roles: Agile coach, scrum master, team tech lead, solution architect, product owner, proxi po, product specialist, dev team, for example.
IS Departments were faced with a new organizational and operational challenge, with Agile as the new way of working.
The main advantage of this method is that it speeds up the delivery of new functionalities:
- easily overcoming silos ;
- adopting a methodology based on sprints, which are the work windows and main driving force of the team, allowing greater flexibility and responsiveness through partial deliveries;
- by emphasizing the team’s ability to recontextualize customer needs in line with market developments, and to iterate on initial requests, as opposed to v-cycle methods, which advocate a longer-term vision with complete delivery.
The Agile method should therefore enable IS departments to be more flexible when it comes to the evolution of their internal and/or external products.
IS Departments are often the most involved of their organization’s departments, not only because they traditionally work in project mode, constantly striving to modernize their infrastructures and working methods, but also because they have the methods and tools to succeed.
Focus on improvement vs. maintenance workflow in an Agile context
When it comes to product management within IS departments, two release workflows coexist.
- The improvement/evolution workflow linked to improvements requested by the customer: this is known as “build”;
- The maintenance workflow for corrections following the discovery of an anomaly or copies of data: this is known as “run” maintenance.
In large-scale IT organizations, rigorous and effective monitoring is impossible without a ticketing tool. But above all, they need to define the processes that accompany them, and put in place proper governance of these requests.
From an organizational point of view, there are two possible scenarios:
Organization |
The Agile team takes charge of improvement but not support |
The Agile team takes charge of improvement and support | ||
Product | Publisher’s solution (Third Party) | In-House Solution | ||
Deliveries |
Improvement workflow | Maintenance workflow | A unique workflow improvement + maintenance | |
Delivery managers | The Agile team | The support team | The Agile team | |
Frequency / Planning horizon | Occasional/ at least 1 year | Recurring | Recurring/ at least 1 year | |
Advantages | Mastery of roles and responsibilities – Flexibility in releasing patches to production – Focus of agile team on delivery of product improvements – Good end-user satisfaction | Control of delivery scope – No additional costs (resources can wear several hats, e.g. support analyst and developer) | ||
Drawbacks |
Human and financial cost |
Mix of support and improvement topics during agile ceremonies – Impact on team predictability and velocity (major KPIs in agile) – Slower improvement iterations -Lack of flexibility linked to release planning – End-user satisfaction undermined by lack of flexibility on patch deliveries | ||
Case study
A few difficulties have been observed at a cstomer’s, here are some tips on how to get around them:
Context
As part of a global transformation plan, an IS department was asked to rethink the organization of its teams in order to apply Agile methods.
Challenges
As these topics are new, IS departments invest a lot of time on the method (how) and less on the substance (what and when). Teams sometimes have to create and assign themselves low-value-added tasks to enable their managers to keep track of activities and time spent. We then fall back into very cumbersome processes that force teams to say what they’re going to do, rather than do what they’re going to say. We lose agility in the truest sense of the word.
Drawing inspiration from architect Ludwig Mies van der Rohe’s “less is more” concept
The architectural minimalist trend that gave rise to the “less is more” way of thinking, according to which the improvement of a work is achieved by subtraction, should serve as a mantra for agile teams to recognize the quality of a product by its simplicity.
both in its design
as in its realization
The fewer rules we have, the better we’ll be able to deliver within a limited timeframe.
Giving young Product Owners the chance to say “no”
Large groups are often looking for experienced profiles (at least 10 years’ experience in these topics), both in the Agile method and in the business sector or technologies involved. Because of the scarcity of these profiles, recruiters often have to turn to qualified but more junior profiles, whose ability to prioritize subjects is less obvious.
Knowing how to say “no” by bringing them closer to those who have experience, or by sharing decision-support processes, can be a starting point.
If you have inexperienced Product Owners working on your products, remember to prioritize irritants (high-value enhancements, bugs) and only process enhancement requests when they have been approved by the majority and fully specified.
Don’t question processes because of work overload
The people in charge of each product are constrained by the budgets allocated by their management, often to the detriment of their commitments. Work overload pushes teams to rethink small parts of the method. But these changes end up undermining the team’s productivity.
The process should only be questioned once the observation phase is over, during the retrospective rituals. The less the process is challenged, the better off the team will be.
Distinguish between Run and Build flows with their own release cycles
The confusion between build and run can also seriously compromise the credibility of the product and its teams. Indeed, it is not uncommon to see release schedules with a mix of improvements and incidents. However, to increase customer satisfaction, it is more important to resolve anomalies that are irritants before seeking to develop new improvements.
The agile team must be able to deliver developments outside a predefined schedule.
Take a step back from the Agile method and apply it only where it’s relevant
Finally, it is sometimes difficult to recognize that the method may not be suitable for all products. Indeed, some teams find themselves having to apply ceremonies, rules and processes that in no way correspond to their original business and product. It’s not uncommon to see teams “bending” this methodology to pretend to be Agile, which ultimately reduces their responsiveness and flexibility. This will inevitably be felt by the team, who will end up perceiving agility as a hindrance rather than a facilitator. This is very often the case for teams working on projects in parallel with product improvement.
- IS : Information Systems
- SLA : Service Level Agreement
