Is agility a concept exclusive to software development projects? Is there any relationship between agility and projects? What makes an agile organization so different from a traditional one? This small article seeks to clarify some conceptual doubts about what "being agile" means and its difference with "doing Scrum" or "implementing SAFe or LeSS or Nexus".
Agility is more synonymous with efficiency and effectiveness than with speed and velocity. Many companies don't understand the difference. However, they believe that the goal is to do more in less time and with the same people. What choice do we have but to do everything faster? Are we all wrong? It is always easier, more salesmanlike and simpler to understand to argue that agility is do more, faster, and cheaper.
Agility and projects
Projects are vehicles for change and allow us to undertake efforts with a particular focus for a defined time. That temporal characteristic conflicts with the maturity of the work team. To illustrate the problem, let's use our imagination.
Example on the conflicts between agility and projects.
For this example, imagine you are the Executive Chef of a famous and successful restaurant. As chaotic as it may seem to an outsider, the people working in your kitchen have complementary roles, clarity on each dish to be prepared, the order of preparation of each request, the ingredients and their role in the preparation.
The specific tasks to be performed for the preparation are rarely discussed, as each person and the team knows their capabilities. Although it is possible to discuss new dishes or preparations, and how to improve some cooking techniques, once a dish arrives, the team goes into "operation" mode and is dedicated to producing the food in the most efficient and coordinated way.
This is how an agile team works. Without many timelines, but with a clear strategy and a consolidated team capable of taking forward almost any requirement.
Problem: the temporality of the projects
What's the problem with agility and projects? Well, now suppose that every night you have a different team, that you are Executive Chef of several restaurants at the same time and that the 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 you know what each one does? Is each member clear about his role, his role in each preparation? Will he be clear about the order of the preparations so that everything goes well and on time?
It sounds like a silly example, but it's not at all. Have you seen how easily people are assigned to projects? I have seen cases of more than 6 assignments at a time. The problem is not the capabilities of the individuals, it is the way we organize ourselves. And that's where the work needs to be done, how we organize ourselves to get projects done.
If you want to learn more about the subject, I invite you to review the following concepts:
- Movement #noProjects
- Value Streams o Business Architecture
Agility and operation
Unlike projects, the operation does not suffer from the same temporality, and therefore, it is more consistent with team assignments. This is why, we can see agility in areas other than software development, such as legal areas or departments, purchasing areas, human talent management areas, and in short, many areas where the work group is relatively small - no more than 10 or 15 people.
The agile mindset, let's remember, promotes teamwork, collaboration based on trust in each other, and of course, decentralized decision making - similar to what happens in our kitchen example.
Work doesn't go away
An agile organization, far from being perfect, is characterized by the fact that work flows with little or no friction. However, in an agile organization:
- The work doesn't go away. Under normal conditions, work does not disappear or shrink. This is a silly myth. The goal of agile is - just like Lean - to reduce waste and make work flow faster - to be honest with you, I don't like the word fast, I prefer to say "frictionless" and that speed is a consequence of the former.
- The team suffers less anxiety. Agility, based on collaboration between people - we must not forget that companies are made up of people - allows the work to be done in the short term to be clearer and fairer - in terms of effort and time available. Imposed plans with ridiculous compliance times tend to disappear.
- People feel more at ease with their job. By understanding the capacity of the system - if we say system, those of us who have studied Systems Thinking say system - people are more consistent with their capacities, plan their work better, and "accept responsibility" for its fulfillment.
These qualities - like many others I haven't named from agility and operation - don't talk specifically about projects or operation. They don't mention concepts like, maintenance or strategy execution. We talk about "workflow".
Considerations
Before starting with the conclusions, I would like to highlight some considerations of this relationship between agility and operation, agility and projects.
- The scale of the operation: How many people are we talking about? Imagine a kitchen with 100 or 200 people. It is clear that agile management models will compete with the need to govern some processes - quality and similarity of preparations, times, flavors.
- The physical location of people: Imagine managing a team that is not in the same office, city or country.
- The relationship with third parties and suppliers: What about suppliers? In the kitchen example, all the ingredients are in place before the start of the day. For a moment, imagine that you have to arrange for some ingredients to arrive WHILE YOU'RE COOKING - a crazy thing that happens more often than it seems!
Conclusions
- Agile is for everyone, I'm not afraid to say it. In projects, operations, and even among friends, it is possible to consolidate an agile work structure. How much Scrum, Scrumban or Kanban do we do, is another discussion? Remember that agility is a way of thinking, a mindset.
- Being agile is not as simple as having a daily meeting, it is a human construction that strengthens trust and respect for each other and their work. This applies to projects and operations.
- The way we organize ourselves - assign certain responsibilities - does not influence the outcome. Always think of the kitchen. It's not just about assigning people, it's about ensuring that we provide the team with the necessary skills to perform the tasks demanded.
- Projects are challenging, and having mechanisms that accelerate the team's maturity process is key. Good leaders and coaches know how to do this. But it also requires the political support of the organization. Agility is not an experiment to be done in a pilot, it is a profound decision that will alter the culture of the organization.
