Agility, is it only for IT?

In my role as Project Manager and Scrum Master, I have been fortunate over the last few years to be involved in many innovative projects for a variety of clients and business lines. This has allowed me to experiment and implement agility in all sorts of different ways, depending on the context and the project. Thanks to these multiple projects in various sectors, I have been able to observe a rather strong trend in terms of agility. For the most curious, we invite you to discover the differences between agile and waterfall methods in a BI project (only availbale in French).

IT, is it a separate department?

Fact: the IT department is, by nature, always involved in technological or technical projects where change is commonplace.

To make these changes optimally, many IT departments have adopted operating processes based on an agile methodology that emphasizes communication between parties to ensure a project's success. Nonetheless, does this mean that agility is only an IT issue? Should this delivery method remain within a single department?

In discussions with clients from different lines of business, I have heard far too often comments such as “the IT department is a scary place! These are not easy people to talk to. They sound like they speak a different language! They think they’re mini-Google”. How can I dispel such misconceptions?

In fact, the best way to reduce the gap between IT and business lines is, in my opinion, to involve these same business lines in projects as Product Owners (PO).
That’s how my customers realized the undeniable benefits of agility.

As a result, I have had great success with projects of exploratory and imprecise needs. Indeed, working in agility allows me to quickly present the first deliverable to the client, clarifying, or evolving the initial need.

Agile method and IT projects, which pitfalls to avoid?

Applying the agile framework promises to bring value to business lines at every sprint. However, avoiding pitfalls will ensure that agility benefits are maximized in projects. Here are three of them, from my latest client projects.

A big bang approach!

I have encountered projects that made the mistake of letting the development team take care of the delivery in SCRUM mode without offering the solution to the end users during the project. Results: Many change requests at the end of the project and a difficult change management because users felt less involved. Although Product Owners try cover everything, end users inevitably make requests for adjustments or functionality additions to use the product optimally.

Proxy POs

Some business lines may choose to replace the PO from time to time with a kind of “right-hand man”: the proxy PO. This strategy, often used by busy POs, only works if the designated person(s) has decision-making power over the product backlog scheduling. Too often, proxy POs do not have the political “power” to make decisions. This results in wasted time for both business lines and development teams.

An approach to rule them all!

Another mistake that I believe should be avoided is to impose the Scrum framework without considering the project context or the agility organization's maturity. It is important to remember that SCRUM is not a methodology to be applied blindly. It is a framework offering tools to help reduce time to market and deliver value continuously. This may seem attractive to companies, but in my experience, when the context demands it, it is important to adjust our ways of doing things to allow more delivery flexibility.

Since examples are better than words, one could imagine using the Kanban method with the infrastructure team, which is often very busy and prey to daily emergencies. Or one could skillfully negotiate with the Product Owner when they try to move the scope of the current sprint.

Innovation management, the ambassadors of agility?

I have recently noticed an emergence on the market of Innovation Departments/Management. These departments, tasked with identifying and delivering tomorrow’s competitive advantages, must, by their very nature, be ambassadors of agility, the best guarantee of rapid delivery of projects that deliver value.
Nowadays, it is becoming increasingly critical to reduce the time to market of developed innovative solutions. It then becomes obvious that there should quickly be chemistry between IT departments and business lines. The application of the agile manifesto is, therefore, a solution, an answer to this need for quick delivery, always based on the continuous prioritization of business values.

I had the chance to be involved in projects where the innovation department was very good at listening to senior management. An all-time classic: when the delivery team has the support of senior management, combined with innovative ideas and a reduced time to market, the solutions create value!

In conclusion

When projects are completed, you need to communicate the successes! Let us use Scrum Masters to promote this delivery method and pair them with sponsors and Product Owners of successful projects! Let us communicate what we have learned and use our retrospectives to disseminate information throughout the company!
Only then will we talk about organizational agility!

So, are you ready to embrace the path of agility?