What's the Relationship Between Agility and Projects?

Table of contents

Is agility really an exclusive concept of software development projects? Is there any relationship between agility and projects? What makes an agile organization so different from a traditional one? This short article aims to clear up some conceptual doubts about what “being agile” means, and how it differs from “doing Scrum” or “implementing SAFe, LeSS, or Nexus.”

Agility is more a synonym for efficiency and effectiveness than for speed and quickness. Many companies don’t understand the difference. Instead, they believe the goal is to do more in less time with the same people. What other option do we have but to do everything faster? Are we all wrong? It’s always easier, catchier, and simpler to argue that agility means doing more, faster, and cheaper.

Agility and Projects

Projects are vehicles for change, and they let us take on efforts with a specific focus for a defined time. That temporary nature clashes with a work team’s maturity. Let’s use our imagination to illustrate the problem.

An Example of the Conflict Between Agility and Projects

For this example, imagine you’re the Executive Chef of a famous, successful restaurant. Despite how chaotic it might look to an outsider, the people working in your kitchen have complementary roles, clarity on every dish they need to prepare, the order in which each order must be prepared, the ingredients, and their role in the preparation.

The specific tasks needed for the preparation are rarely discussed, because each person and the team know their own capabilities. While it’s possible to discuss new dishes or preparations, or how to improve certain cooking techniques, once an order comes in, the team switches into “operations” mode and focuses on producing the food as efficiently and in as coordinated a way as possible.

That’s how an agile team works. Without many schedules, but with a clear strategy and a solid team capable of handling almost any request.

The Problem: The Temporary Nature of Projects

What’s the problem with agility and projects? Well, now suppose you have a different team every night, that you’re the Executive Chef of several restaurants at once, and that staff turnover is high. Do you see the problem? How can your team coordinate in the kitchen if they don’t know each other? How do they know what everyone else is doing? Does each member have clarity on their role, their part in each preparation? Do they have a clear sense of the order of preparations so everything comes out right and on time?

It sounds like a silly example, but it’s not at all. Have you seen how easily people get assigned to projects? I’ve seen cases of more than 6 assignments at once. The problem isn’t people’s capabilities — it’s how we organize ourselves. And that’s exactly where the work needs to happen: how we organize ourselves to carry out projects.

If you want to learn more about this, I’d invite you to look into the following concepts:

Agility and Operations

Unlike projects, operations don’t suffer from that same temporary nature, and are therefore more consistent with team assignments. That’s why we can see agility in areas other than software development — legal departments, procurement, human talent management, and, in short, many areas where the working group is relatively small — no more than 10 or 15 people.

Remember, an agile mindset promotes teamwork, collaboration based on trust in one another, and, of course, decentralized decision-making — similar to what happens in our kitchen example.

The Work Doesn’t Disappear

An agile organization, far from perfect, is characterized by work that flows with little to no friction. Even so, in an agile organization:

  1. The work doesn’t disappear. Under normal conditions, the work doesn’t disappear or shrink. That’s a silly myth. The goal of agility — just like Lean — is to reduce waste and make work flow faster. To be honest with you, I don’t love the word “faster”; I’d rather say “frictionless,” and let speed be a consequence of that.
  2. The team suffers less anxiety. Agility, grounded in collaboration between people — and let’s not forget that companies are made of people — makes the short-term work clearer and fairer, in terms of effort and available time. Plans imposed with ridiculous deadlines tend to disappear.
  3. People feel more comfortable with their work. By understanding the capacity of the system — if we say “system,” those of us who’ve studied Systems Thinking know what we mean — people become more consistent with their own capabilities, plan their work better, and “own the responsibility” for delivering on it.

These qualities — like many others I haven’t named, about agility and operations — don’t speak specifically about projects or operations. Concepts like maintenance or strategy execution aren’t mentioned. We’re talking about “workflow.”

Considerations

Before getting into the conclusions, I’d like to highlight a few considerations about this relationship between agility and operations, agility and projects.

  1. The scale of the operation: how many people are we talking about? Imagine a kitchen with 100 or 200 people. It’s clear that agile management models will compete with the need to govern certain processes — quality and consistency of preparations, timing, flavors.
  2. The physical location of the people: imagine managing a team that isn’t in the same office, city, or country.
  3. The relationship with third parties and suppliers: what happens with suppliers? In the kitchen example, all the ingredients are there before the shift starts. For a moment, imagine having to coordinate some ingredients arriving WHILE YOU’RE COOKING! A kind of madness that happens more often than it seems!

Conclusions

· 6 min read
../