Agile is more than a management methodology. This is a whole philosophy that promotes a radically different approach to project work. In this sense, Agile is not about "management" at all, but about working without managers, but with a team whose members are responsible to each other. That is, "horizontal" instead of "vertical".
What's the idea
The flexible management methodology was invented to solve a number of problems of the classical / cascade / waterfall methodology (Waterfall). For example, too much emphasis on planning and the impact of delays in some teams on the work of others. To do this, as I have already said, we had to completely reconsider the view of the project work, and not change any individual mechanics.
"Flexibility" is the ability of an agile team to constantly adapt to changing conditions and is achieved by:
- Iterativenesses. Instead of working out a plan for a long time, and then even longer to make the perfect version of the product, the agile team tries to release a workable prototype as early as possible, and then test it again and again and finally finish it. Iterativeness can negatively affect the duration of development, but you almost immediately have a more or less working product.
- Self-organization. In the team, everyone is equal, there are no managers, and therefore there are no hellish agreements. This saves resources, especially time.
- The interpenetration of knowledge. Any specialist in an agile team should have at least basic knowledge of related specialties. In addition to cross-functionality, constantly diving into new topics allows you to keep the brain in good shape (in general, if the brain is regularly given new information, dementia will also come much later; but this is a completely different story).
A Brief History of Agile
The flexible approach begins to exist somewhere in the first half of the XX century (although there is an opinion that something similar to it was before). Around the 30s, physicist Walter Schuhart applied the iterative Plan-Do-Study-Act approach, which he shared with his student William Deming (now we know this approach to management as the Deming Cycle). After the end of World War II, Toyota (the same company that invented Lean, Kanban, and many other things related to Agile) hires Deming to train its managers.
In the following years, many companies come up with their own methods of flexible management: Scrum, XP, FDD, and so on. But nobody talks about "agile" until 2001, when 17 developers practicing agile management techniques come together and make a Manifesto for Agile Software Development (or simply Agile Manifesto). This is where the concept of "agile" arises, around which there is so much talk today.
Core Values of Agile Methodology
In the article about project management methods, I gave this definition:
Methodology is a set of methods and principles supported by a theory.
So the theory in the case of Agile is the values described in the Agile Manifesto:
- People and interaction are more important than processes and tools. If your team has principles, traditions, structures, tools, or conditions that clearly interfere with your work, you should get rid of them. People themselves must choose the way of organization, the set of processes, the tools used. In the end, all this should help the work, not hinder it.
- A working product is more important than documentation. This does not mean "work on Agile means work without documents". Agile teams also have documentation, but they don't spend a huge amount of time and resources on it.
- Cooperation with the customer is more important than agreeing on the terms of the contract. Look a little further than the approval of the task and the estimate. There is no point to spoil the relationship with the customer, even at the cost of timely payment. If you can't coordinate the work and spoil the communication, you will end up losing this client, and possibly the next ones. Any contracts, documents, and agreements should benefit your relationship with your customers, not spoil it.
- Being ready for change is more important than following the original plan. Even if there is a project plan, it will almost certainly have to be changed over time - this is the essence of Agile.
The Manifesto also describes the principles, but rather in an attempt to explain the values. So I will not give them here. If you want, go read it on Wikipedia.
What problems can there be?
Aw, what a cool Agile, huh? Although it can be used in any company (even if you are-God forgive me-a bank), it is not suitable for everyone. Moreover, its implementation can be extremely painful.
I see three problems (although it may well be that there are more of them), because of which you can not advise everyone to switch to Agile in a row:
- It is difficult to abandon the concept of "boss-subordinate". After all, Agile is not a way of planning, but the philosophy of the whole team. Not every company can safely survive such a transformation.
- Not everyone is ready for real teamwork. Many people are more comfortable working alone, reporting to management, and staying out of the way. And in the case of Agile, everyone will have to understand everything and constantly participate in someone else's work.
- Not everyone is prepared for the fact that some of the time may simply disappear. Let's say the team was working on a task, and then it turned out that the project goals have changed and there is no point in continuing the almost finished work. All your efforts were in vain. This is a psychologically difficult situation that can easily kill all motivation.
But if your team is working on a bunch of projects, knows their business well, and pays for the perfect result, perhaps Agile is yours.
The agile methodology allows what the cascade model does not allow-to create high-quality products without a detailed plan for all stages. This is all thanks to iterativity, customer and employee feedback, and team self-organization.
The main thing is to remember that Agile is a methodology and a philosophy. To apply all this to project management, you need to build your own methodology or choose one of the existing ones — I will talk about them in the following articles.
Join Telegram chat