Why (the way you implement) agility might be hindering your company’s potential

Applying textbook agility is not always a surefire way to deliver maximum value to your business.

In my previous article, I suggested technology leaders embrace agility and product vision once and for all (in lieu of traditional project management method, e.g., waterfall). In doing so, I may have painted the application of agility in a too rosy manner. For example, I only remarked that agility had to be “implemented the right way for organisation” without much detail. For the sake of intellectual honesty, I should have stressed more some pitfalls of implementation of agility (precisely Scrum). To settle the score, here are two real life scenarios in which agility delivers sub-optimal results for companies.

Both these scenarios exemplify the breadth of what can go wrong in using agile to deliver applications in a company. I will present these situations as a spectrum. It can be read as a framework to determine where your organisation lies when doing agility.

For starters, let us go beyond the easy definition of agile: “on the fly” or “without much preparation.” Scrum is a lightweight framework that defines events and sequences (such as daily or weekly meetings), artifacts (like feature backlogs as User stories), and roles (defining the actors and their responsibilities) for projects. The two bonuses of this framework are:

• does not necessitate that all elements be implemented: Scrum should be adapted to your company’s culture and capabilities;
• can be implemented along with other agile frameworks such as Kanban and eXtrem Programming for more productivity and design thinking to enhance collaboration with users.

Agilists in an ivory tower

The set-up is akin to what could happen in a waterfall project:

1. The development team gets the business requirements from the business or on rare occasion, writes the business requirement by itself without consulting the functional team;
2. The development team then proceeds to implement the application by religiously applying the scrum framework: daily and weekly meetings, writing of user stories and use of a kanban board to track their advancement through various metrics;
3. The project is finally delivered to the business teams along with its documentation. On occasions a Run team is charged with maintaining the product while the development moves to another project.

Illustration: on a new business line creation project, the technology leaders took the responsibility to design the different software needed. They would schedule design thinking sessions with the users only to dismiss their requests deemed of low business value. Even protests from the COO to the CEO did not change the environment of the project. The development team strictly adhered to the agile framework.

This fact is either due to the company culture or to the balance of power leaning on the side of technologists. One justification for this way of working is the need to go as quickly as possible on the project (with the premise that interactions with the business can be a distraction). In sum, technology leaders believe that they know better what features are needed and when.

This phenomenon occurs also in companies that have switched to agility but for some reasons have kept the waterfall philosophy. We can also refer to technologist as isolated agilists.

Hyperactive business leaders

Here we find ourselves on the other side of the spectrum:

1. General business requirements along with a product roadmap are agreed upon between the business and the technologists at the beginning of the project;
2. The business leaders are aware of the importance of technologies to their core business; so they are very much involved in the project. But priorities are regularly shifted solely at their will, without input from technologists. In other words, the business dictates what features are to be implemented and will often change their mind on the developments to be done. Short deadlines will also be pushed onto technologists, often at the expense of software quality. An unfinished or buggy feature will be pushed in to production when the business requires it;
3. The development team will de facto implement Scrum on the project, not by choice but by necessity. Nonetheless, Scrum, to the technology team, will mean being able to work on short iterations and quickly refocus to follow the pace imposed by the business.

Illustration: on a deployment project for a neobank, the technology team complained of the quickly changing priorities. This situation affected their focus and motivation. In fact, the business leaders would take part in the week product reviews and give the directions for the upcoming week, changing the team’s delivery schedule and requesting ongoing developments be upheld or that the whole team focuses solely on a feature to be delivered in emergency the following week. The development team would then carry on its mission.

These scenes play out during a high stake digital transformation programme such as the creation of a new business line. The business leaders make these decisions in reaction to stimuli from the business landscape or to follow a new trend, with minimal to no planning. The requests are minor features or increments to a feature or bug fixes. The balance of the power is, indeed, on the side of the business.

The technology team hardly has time to design, let alone implement long-medium term objectives. The technical debt also grows sharply because the team is focused on implementing business features. The switching cost (i.e., energy necessary to turn focus to another subject) is also high, affecting team’s morale. Incidentally, a high talent churn rate can also be expected.

To the layman, agility means ability to switch from one task to another. This type of agile can be defined as: reactive agility for business.

Communication between tech and business is the solution to find a middle ground.

Reconciling positions

After our analysis, it seems obvious that the good type of agility should be somewhere in the middle of the spectrum. However, there is no definite solution. Business leaders and technology leaders should discuss and agree on the best set up that would suit both parties and ultimately, the business interests. They can do so by taking into account:

• the company culture;
• its capabilities (e.g., tooling and talents);
• and business objectives.

Agile should allow a company to play the short game (e.g., small upgrades, bug fixes) as well as the long game (i.e., innovative projects for the long haul). It should allow the business to be itself agile and pivot quickly and market conditions require.