Agile or obsolete: choose your side

Lining up the covers of PME Magazine is an interesting exercise. A litany of concepts that are all the rage in the business world. Key words such as Big data, benevolence, pivoting, AI, agility, inclusive, talent, employer branding, ... On a punchy headline like "These start-ups pivoting towards a more inclusive AI to retain talent in 2.0 mode".

Useful and important ideas and concepts, which have often ended up rinsed, wrung out and emptied of their substance.

Such is the case with the word "agile". Today, many people are put off by the term. They are skeptical of the jargon, dismissing these ideas as just another charade by those adopting all the jargon without the underlying substance.

The latter start getting up for their meetings and believe that this will lead to better results for their customers or users. They rename managers Product Owners, and voila! their teams become agile. But still paralyzed and exhausted by a culture of silos and top-down authority.

Agility is not a passing fad. It's a new way of organizing people to do good work, reflecting real changes in the way our world and our economy work.

To avoid an unproductive debate on agile terminology and focus solely on the substance, it's useful to turn to history.

Why agility makes sense

Remembering why agility makes sense today helps to focus on the essentials, and reassures people that it's not just a passing fad. Our world and our economy have changed, and these changes favor those who favor more iterative and adaptable ways of working.

On the one hand, we have migrated from a product economy to a service economy, where even products are worked as a service, like a Tesla or a smartphone.

On the other hand, we've moved from function-based expectations to those based on satisfaction. Apple may make computers and phones - as many others do - but they sell us a satisfaction that few others achieve.

From product to service

In the pre-digital world, organizations could typically reach thousands of people with a single instance of their product or service. Changing or updating these products or services was costly and imprecise.

Since the first decade of the 2000s, thanks to digital technologies, things have been changing. Even a small organization can reach millions of people with a single instance of its product or service.

Another kind of competition is possible. Entire markets are evolving faster and faster. Goliaths are being outfoxed by prepubescent David. The survivors are those who can adapt faster, with a precise understanding of market changes and consumer expectations.

What do you do when your market is evolving faster than your ability to adapt your product or service?

Agile approaches first appeared in IT development in the late '90s, and took off in this context. Instead of freezing specifications when a contract is signed, and then rolling out a pre-established schedule only to deliver and - worse still! - evaluate the software only after months or years of development, Agile methodologies focus on delivering value rapidly and continuously.

Their iterative and evaluative approach enables the product or service to be constantly delivered and adapted to the customer's changing business challenges, including a market that can be rapidly evolving.

Of course, with software, revisions are cheap. You can adjust lines of code and test the new version live. Often right alongside the old one. You can then learn instantly and with new precision whether the changes have worked.

Iterative and adaptive approaches have naturally proved to be much more economically attractive than the conventional method.

From function to satisfaction

In the early days of industrialization, engineering knowledge was paramount. It took precedence over the user experience - the concept of which obviously didn't exist. It didn't matter how pleasant your machine tool was to use. Its main value lay in the fact that it worked.

Later, in the age of mass production, the balance shifted. If you made a mass consumer product, it had to work, of course, but it also had to be elegantly designed. The twentieth century was marked by the idea of combining form and function. The paradigm shift was certainly crystallized by Apple. Technically and aesthetically well-designed, the value of this type of product lay increasingly in the satisfaction it brought to the user.

And it fundamentally changes what you need to know and do to create things of value.

Now more than ever, you simply can't neglect your users. Gone are the days when you could sometimes get away with bad user experiences.

Except perhaps with Microsoft (an entire article should be dedicated to this anomaly: I'm still amazed to see products like Outlook, Word or Excel languishing in the UX of the 2000s).

Agility makes sense and plays a central role in today's business world, because a poorly designed service has no value.

Agility is particularly relevant to those who feel immune to it.

If you think you're not concerned because your company is in the "real economy", that of physical, "classic" things or services, you're wrong.

It's no longer about the reality of what you do - a washing machine, carpentry, banking advice and so on. - but the customer or end-user satisfaction.

We've recalled the context and why agility makes sense. So how can we work in an agile way without getting distracted by Agile with a capital A?

Getting back to basics

Rather than focusing on the word itself, let's look at the two fundamental principles of Agility:

1. You should always start by defining your problem in terms of the user's point of view. Don't get lost in your own business or technical considerations. If you have to make compromises, don't do so until later (we'll come back to this).
2. You should always build solutions quickly and simply at the outset - just create something that works. Then show it to your customers/users and adapt it in response.

These two principles capture many of the benefits of agility without the jargon. Applied, they lead to much better products and services.

They're also revolutionary because they go against the grain of how most organizations operate. Looking at things from the user's point of view? It's obvious! Yet few really know how to do it.

In 2023, our ultra-light laptops still carry a monstrous, heavy power supply.

These two principles seem simple, but applying them correctly can be really difficult.

Contractual requirements, power games, managerial culture, overwork and deadline pressure all scupper the best of intentions. But above all, can they be applied to day-to-day operations? An administrative team, a secretariat, IT support, a breakdown team?

These two principles apply to all projects, large and small, and even those that don't look like it. Whether you're writing reports, building an intranet, organizing a new in-house training course or managing a construction site.

What does it mean to be agile?

These two principles are the empire of common sense. It's the natural, spontaneous way of doing things. Yet it has been lost in the technocratization of the professional world.

When you look at things solely from the point of view of the person receiving your work, you significantly improve the chances that what you deliver will bring satisfaction. You reduce the risks and costs of doing something wrong. And the closer you are to your customer/user, the more excellence you'll deliver.

When you get into the habit of breaking down your projects into small, deliverable, usable chunks, you' ll gain a serious competitive edge:

1. Every delivery brings value to your customer: an e-shop that only accepts credit cards now is better than one that accepts all payment methods in 6 months' time: your customer can start selling now and not in 6 months' time.
2. The customer (who may be you) and/or the market can give you immediate feedback. The effort involved in correcting and improving is incomparably less than a late, complete delivery. If your e-shop works very well with credit cards, and a change in the market means that a new feature needs to be developed quickly, you've saved time and money by skipping the incidental (other payment methods) and allocating those resources to the new priority.
3. You aim for excellence: you focus only on the next piece that will have the greatest impact for your customer, you consume only the resources necessary for that, and you integrate market feedback immediately.

You've become agile because you're able to evolve and react quickly, even when your context suddenly changes.

Think user, deliver regularly, evaluate and evolve. That's Agility without the jargon.

Rest assured that you can apply these two principles even to projects that don't look like it, such as writing an annual report, organizing an HR training program or managing the day-to-day work of your administrative team. You'll do a better job with less effort.

How to be agile?

Scrum⁽¹ ) is the best-known agile method. Probably because it's the most versatile, applicable - in whole or in part - to all teams, all industries, all types of organization.

Scrum is a holistic approach to projects and teams. Scrum is concerned with the mechanics of project management (planning, meeting deadlines and resources, assigning tasks, reporting, etc.) but also with everything that makes and impacts the team and the project. Customer and other stakeholders included.

Scrum is about thinking and acting as a team.

We're not going to go into Scrum in detail, but rather focus on the main principles that make this type of approach essential today. What interests us here are the active principles of agility.

Promoting transparency

Information silos slow down collaboration, reduce quality and increase costs (energy, time, money).

By fostering a context of transparency, you enable everyone to access information easily and quickly, to understand how what they do fits into the greater whole, and to make better decisions.

The key is your information system and collaboration tools. You need to be able to search, find, share and organize information effortlessly. This is not possible with IT infrastructures that are a little... shall we say... dated.

Promoting distributed authority

The way in which roles and prerogatives are distributed within a Scrum team is essentially one of distributed authority. Power is not deposited in the hands of a single person (project leader, manager, etc.), but is strictly distributed on the principle that whoever is most involved decides.

What's more, a team is put together and roles allocated to get the best out of it, including protection from external disturbances.

It's not about looking cooool or riding the hype highway. It's about building sustainable, agile teams in the truest sense of the word.

The principle of distributed authority also means enabling the organization to be more adaptable and responsive. It's about bringing down to the right level the right latitude for action.

Take a look at how decisions are made within your organization or team. Is it pragmatic (just because it's always been done that way doesn't mean it's pragmatic)? Are there ways of doing things that are sabotaging you, particularly because authority isn't in the right hands?

Fostering commitment

Scrum is about thinking and acting as a team. Team members have collective ownership of what they do. They are co-responsible for the result. This, in turn, generates greater commitment, trust and respect among all team members.

This is made possible by the way an Agile team is organized: roles, rituals, decision-making processes.

Working iteratively

Agile methods are iterative and incremental. They divide work into small, repetitive steps delivering a functional result, enabling continuous adaptation and adding value to the product over time.

These short stages are called sprints. They have a fixed duration, usually one, two or three weeks.

Working in sprints means getting into the habit of moving projects forward in mini-projects. A sprint is long enough to create something finished, but not so long that you get lost along the way, with several things started in parallel but not finished.

By delivering something finished at the end of each sprint, which needs nothing more to add value, you can be sure that you can renegotiate priorities quickly and regularly, and adapt when circumstances demand. You're agile.

Working iteratively is possible in all circumstances: on projects in the usual sense of the term, but also for teams managing "day-to-day business". This practice is particularly important because it brings great benefits in terms of productivity and well-being: focus.

Encouraging focus

A sustainable team must be able to work indefinitely at a constant pace, without overheating. In addition to delivering value on a regular basis and enabling continuous adaptation, sprints protect the team from the reign of permanent urgency, unpreparedness, zapping and multi-tasking.

When you can anticipate what you're going to work on, when your workload is stable, and when you're not constantly disrupted by new demands and elements that don't belong there, you're more productive, more creative and less tired.

Each sprint starts with the team clearly and precisely planning what it's going to do. Knowing in advance what you're going to work on makes you more focused and efficient.

It's hard to be relaxed and creative when you don't know what tomorrow, today or the next hour holds. You can't take advantage of the brain's ability to work "behind the scenes" to generate ideas, anticipate situations or solve problems.

This is why a sprint is also a "watertight box": nothing new can be added once the sprint has started. New things will wait their turn to be done in the next sprint. The team can remain focused, without being constantly disturbed, and having to evolve in a permanent multi-tasking mode as several things are crammed in parallel. This generates less stress and fatigue, and increases productivity and work quality.

Sprinting is the art of focusing on what matters most. Everything else can wait.

What about the unexpected? Of course, most teams have to deal with little or a lot of the unexpected, whether it can wait or not. The unexpected is taken into account in sprint planning.

The famous daily flash meeting is also there for focus: getting the day on track, making sure everyone is aligned on what needs to be done and anticipating any sticky situations.

Being able to focus and concentrate on a known set of tasks is less tiring and reduces stress. The team faces up to what it has delivered, with the realization that the job is finished. This generates satisfaction, commitment and confidence.

Continuous assessment and adaptation

Each sprint ends with the delivery of what was planned. In principle, the result is presented to the customer/user for feedback. Of course, if you're your own customer, or if you're managing "day-to-day business" and not a project in the true sense of the word, you're going to keep things simple.

What's important at this point is that the team and any other stakeholders who may come along (management, for example) are able to see the result.

You need to be literally in front of what's been planned and done: get yourself a good piece of collaboration software or a whiteboard and post-its to plan and manage your sprints.

A sprint closes with an evaluation of what has been done, so as to generate feedback and create a continuous adaptation loop. The team looks at how it went, to identify what went well and what didn't, so that it can improve.

You can't aim for excellence and be reactive when you only carry out an annual one-to-one interview, or when the stumbling blocks - often little everyday things, bad habits - are not quickly identified and corrected.

Agility implies thinking and acting as a team, and constantly evaluating oneself to ensure continuous improvement.

The art of planning

Project management is about knowing where you're going, why you're going and how you're going to get there. Classic stuff: vision, roadmap, milestones, schedule, tasks, deliverables, etc. With Agile, this doesn't change; it's how you do it that changes everything.

What we discover in the practice of Scrum is the art of planning in a way that is more precise and fuzzier at the same time. It's the art of "Just Enough" applied to project planning.

The practice of "Just Enough" is one of the keys to agility. However, it is particularly difficult to adopt, as it requires resisting formalism and an entrenched vision of project management.

No plans for the future

Planning a project the Scrum way means considering that the closer (or smaller) it is, the more precise it is, and the farther (or bigger) it is, the fuzzier it is. It's about planning with the right level of detail.

The natural tendency in companies is to plan projects with the same level of detail over the short, medium and long term. This means that they appear to be very (too) detailed in the long term, but not detailed enough in the short term.

You can be precise and detailed about what you're going to do tomorrow, this week or next. You can't be specific about what you'll be doing in 3 or 6 months' time. And you certainly don't want to be! Sure, you need to know where you're going, but changes can happen at any point in the project, so you don't want to waste your time planning in detail something that may never happen.

Just in time and just enough: the recipe for efficient planning.

One of Scrum's key features is its ability to assess tasks more quickly and accurately, while taking into account the uncertainty inherent in the long term. The team manages projects effectively and efficiently, while remaining super-flexible to meet changing customer and market needs.

Resisting formalism

Agility is the empire of common sense. All these principles and recommendations are pragmatic and natural. But it's harder said than done.

You're going to come up against what is perhaps the biggest obstacle to Agility: formalism. Yours and your organization's.

Resisting formalism means identifying and abandoning anything that doesn't add value but consumes resources.

Any examples? Don't make a clunky powerpoint presentation when a simple hand-drawn diagram will do. Don't waste time writing a progress report (which won't be read) when a simple management visit is all you need to know about the status of the project. All these hours saved can be put to good use in creating value.

You come up against decades, if not centuries, of managerial habits, people who think as if we're still in the old world, colleagues who want to be Agile but refuse to be stripped of an ounce of the power that makes up their title on the business card and their salary.

It's generally unlikely that you'll be in a position to transform your organization's culture. There are, however, three things you can do:

1. Identify your freedom. Most Agile precepts can be applied "under the radar", i.e. internally within the team. You don't need to involve the whole organization to implement them.
2. Resist formalism. It's likely to be yours first. Depending on the context, you can impose your own way of doing things. There are often a lot of rules - usually implicit - that can be challenged at little cost. Shake things up!
3. Know how to stand your ground. Yes, you'll often have to deal with the situation. But you do it consciously, and that's super Agile 😉

Getting to grips with becoming more agile means renegotiating the way decisions are made, the way things are contractualized, the way projects are managed and even the way you think. Resisting formalism will take you out of your comfort zone.

Conclusion

It's an illusion to think we can remain competitive with the tools and methods of the past century. Rampant digitalization has rapidly and dramatically changed the nature of our activities and our environment. Yet the workplace is still "stuck" with tools and ways of doing - if not thinking - that date back to the '90s.

Not to change is too expensive.

No sector is immune. A gulf is opening up between traditional structures and those that are already culturally and technically agile. The choices of wait-and-see and status quo are doomed to failure.

Becoming agile thanks to Agile is not a fad. Our world and our economy have changed, and these changes favor those who favor more iterative and adaptable working methods.

By adopting the fundamental active principles of Agility, you'll enjoy benefits that will significantly boost your business.

 

(1) We apologize to Scrum ninjas for shortcuts and inaccuracies. The article is about the active principles of Agile. It is not an ex cathedra course on Scrum in particular.