“Agile” seems to be suffering the same fate. Being Agile is the new panacea for many companies. The promise of Agile, many understand, is that they will get results faster. It is not that this is not true or that it is all they think they will get, but to think that this is the benefit of Agile is to reduce a vast concept to a result-oriented, tactical vision that commoditises a philosophy for the benefit of a short-term vision.
Antes de definir qué es ser Agile, miremos ejemplos de lo que no es ser Agile.- Being Agile is not about having a list of tasks or projects (prioritized or not) and calling it Backlog.
- Being Agile is not about cutting up a Gantt, planning everything in advance and dividing the same mega project into “Sprints”.
- Being Agile is not about changing the daily work planning in the IT area to make it more efficient at the internal management level.
- Being Agile is not about making a fast but low-quality app, full of bugs, that meets the minimum requirements of the user or customer.
- Being Agile is not even about sitting together around a table but not having excellent coordination, communication and alignment.
The meetings, the tools, the rhythm of work are activities, work techniques, which are some of the tactical aspects of Agile. It’s what many call “Doing Agile”. In fact, they are guidelines, aspects, and tools of a particular Agile methodology or framework (e.g., Scrum, Kanban, XP, etc.).
When an Agile implementation focuses on the tactical, we are leaving out what it is to be truly Agile.
What is Agile?
In 2001, 17 developers got together in Utah, USA, to look for a “lighter” methodology that would allow them to adapt to a changing context. The result was the Agile Manifesto and the formation of an “Agile Alliance” dedicated to evangelising this new work philosophy.
The Agile Manifesto has the following fundamental principles:
- Individuals and interactions on processes and tools
- Software for working on complete documentation
- Customer collaboration on contract negotiation
- Responding to change on a rigid plan
Jim Highsmith, one of the participants in that original meeting and a signer of the Manifesto, explains that the developers who formed the Alliance (and the Manifesto) had a common vision, “a set of compatible values (…) based on the trust and mutual respect and by promoting organizational models based on people, collaboration and building the kinds of organizational communities we’d like to work in.”
He also explains that “Agile Methodologists are really about ‘soft’ stuff, about delivering good products to customers operating in an environment that considers people the most important thing.”
The Agile manifesto contains 12 key principles:
- Our highest priority is customer satisfaction through early and continuous delivery of(software with) value.
- Business managers and developers work together on a daily basis throughout the project.
- Projects are developed around motivated individuals. They must be given the environment and support they need, and entrusted with the execution of the work.
- The most efficient and effective method of communicating information to the development team and among its members is face-to-face conversation.
- Continuous attention to technical excellence and good design improves Agility.
- The best architectures, requirements and designs emerge from self-organizing teams.
- At regular intervals the team reflects on how to be more effective and then adjusts and refines its behavior accordingly.
- We accept that requirements may change, even at the late stages of development. Agile processes leverage change to provide a competitive advantage to the customer.
- We deliver functional software frequently, between two weeks and two months, with preference given to the shortest possible period.
- Working software is the primary measure of progress.
- Agile processes promote sustainable development. Promoters, developers and users must be able to maintain a steady pace indefinitely.
- Simplicity, or the art of maximizing the amount of work not done, is essential.
Of the 12 principles, 7 (which I have gathered at the beginning) are universal and applicable to the online or offline world. And they are all about values and culture, where people are at the center, and matter more than the bottom line (which is also very important, but never at the cost of people). And speaking of results, it is essential to note that Agile is focused on creating a good product as a result of a process (the “outcome“, as it is called in English) rather than focusing on delivering something (“output“) (often at any cost).
The vision
Adopting the Agile vision implies a profound cultural change. It implies stopping trying to control and define everything from the beginning, to stop working in silos, to stop working based on hierarchical relationships or being guided by an almost obsessive result-oriented approach.
Agile is not a methodology; to be Agile is to have an agreed-upon vision that focuses on how people work, interact and achieve results.
The strategy
Once we have agreed on this vision, in order to work in an agile way (“do Agile”) we will need to decide which particular framework to adopt. This is a strategic decision that will make the vision a reality.
Examples of frameworks (and the confusion between “methodology” and “framework”…) include
- Scrum
- Kanban
- Extreme Programming
- Dynamic System Development (DSDM)
- Feature Driven Development (FDD)
- Agile Project Management (APM)
- Lean Kanban, Lean Startup (I’ll talk about Lean in another post 😉 )
However, adopting a methodology (or framework) is not painting by numbers. There is no universal magic formula. Beyond the “soft” level (cultural change, values, etc. — which in itself is the basis and the most important thing about being Agile), we have to understand that there is no perfect model, one size fits all and that’s it. Every company, every team is different (in terms of culture, knowledge, experience, product, market, etc.).
Let’s take Scrum as an example, which is one of the most popular Agile frameworks. The creators of Scrum, Ken Schwaber and Jeff Sutherland (who wrote and maintain the “Scrum Guide”) define Scrum as: “a framework through which people can address complex adaptive problems, while delivering products efficiently and creatively with maximum value.
Then they clarify:
“Scrum is a framework composed of processes used to manage complex product work since the early 1990s. Scrum is not a definitive process, technique, or method. On the contrary, it is a framework where a set of different processes and techniques can be used .
The tactical level
Once we are clear about the path we will take to achieve the vision, we can (finally) move to the tactical level and define activities, artifacts, tools, etc.
It is not enough to take a course (in Scrum, Kanban, XP, etc.) and you are already Agile. At most, you will know the rituals, artifacts, activities and tools of that framework. When you leave out the vision and essence of Agile, and adopt only the tools, artifacts, rituals, activities of Scrum, or Kanban, etc. you adopt what is called “Fake Agile” (or “Waterfagile” or “Agilefall“).
To adopt the tools, ceremonies, etc., is to adopt only the tactics. And as Sun Tzu wrote in The Art of War, “Strategy without tactics is the slowest route to victory. Tactics without strategy is the noise before defeat”.
Unfortunately, many companies tend to focus on the tactical, because it is more tangible, and measurable. They demand results such as speed of delivery, profitability, sales, etc., and activities at the tactical level give (or should give) fast and visible results (even if they are not good).
When you talk to these companies about cultural change, the conversation tends to change tone. “Well, we’ll see if it works, but give me results first to prove that it works. The other thing, all the “soft” stuff, is very complicated and now things are not ready to make big changes”.
Staying at the tactical level is to want change without wanting to change (or to be changed). It’s short-sighted, conservative, and result-oriented, waving the Agile name around like a magic wand, the same wand with which a UX designer was bought to fix the “UX” of the site
If the goal of an Agile implementation is simply to improve delivery speed, increase profitability and see more project deliverables – often at the expense of the well-being of Agile team members, ignoring all the “soft”, cultural stuff – then we are not Agile. If we really want to have the benefits of Agile, then we must begin the journey to be truly Agile.
Being truly Agile
Being Agile is a learning process that never ends, where we must continually change to adapt to each team, situation and stage of our learning process. It is a path that begins with the vision of how to work.
Of course, the adoption of something new (be it a methodology, a product, a service) cannot be done all at once, in one day. It’s a process, and if we are truly Agile, we will always keep the vision in mind. We will question the framework. We will want to iterate and expand and consolidate as we measure and learn. But in any case, we must have a clear conviction from the beginning that the Agile vision is the one we want, even if it takes time (especially in very large companies).
What can you do?
You can always do something to be agile, because Agile is about people and the first change is the change of mindset that each one of us makes.
If you are the founder, thinking of founding or working in a small startup, if you are a Product Owner, a project manager, a Head of UX, a designer or a functional leader (marketing, sales, etc), you can start being Agile if you start by adopting the Agile philosophy at the level of people, communication, respect. You can set a vision for your team that is Agile at its core.
As this post is very (overly?) simplified, I hope it at least serves as a starting point to pique your curiosity, get out and investigate further. There are enough free online resources, and books, and videos, and courses to learn more about each framework (such as,
If you know English, you can visit the resources section of the Scrum.org website, where they have excellent resources. (But remember: learning Scrum techniques won’t make you Agile; it will just help you along the way).
I also recommend Rashina Hoda’s presentation on “Being Agile and Doing Agile” (video, 37 minutes). Rashina has spent more than 12 years researching the human and social aspects of Agile, and explains this Being Agile (instead of Doing Agile) much better.
Finally, and as it seems to be very fashionable (still), if your company or you are thinking of “copying the Spotify model”, I invite you to read this interview where it is quite clear that there is no Spotify model.
If you want to be truly Agile, the journey starts today, now, with yourself.