The word “Agile” is mostly used term in software and tech industries. But what does Agile actually mean? For various people, the term Agile holds a different meaning — particularly for the ones who are trying to sell you something.
For instance, if you ask the creators of paper products, they will say that to become agile you should write important things on sticky note cards, which they happen to sell. If you ask a consultant, they are most likely to say that Agile is a methodology to develop software that your company can use, only if you buy their services. And if you talk to the manufacturer of orthopedic shoes, you’ll be suggested that the key to becoming agile is to conduct a meeting where everyone stands. Hence, for them, the more comfortable your shoes - the more agile your team will be.
The Agile Manifesto contains the actual meaning of Agile. The Manifesto describes clearly that Agile is not a methodology and is not the only way for software development. It is neither a process nor a framework. In fact, many things that are promoted as Agile misses out on the point of what Agile really means.
Agile is a set of values and principles that help in decision making. To be Agile, you need to follow different practices, use various methodologies, and use specific tools for developing software. While these things may help a team to adopt an Agile environment, but they do not become Agile by themselves.
For example, a team may find that having a daily standup is helpful for them, but the standup will only be ‘Agile’ to a certain extent, which is the result of a team following the values and principles of Agile.
When you understand this, it’s easy to look at agile as the collection of beliefs that teams can utilize for making decisions while developing software. The term Agile is extremely flexible, but for people to give it different meanings is not right.
Agile doesn’t make decisions for you. Rather it gives a foundation that teams can use to make better decisions that result in improved software development.
The Agile Manifesto is created using only 68 words and describes that we can develop the software in a better by just valuing and considering the items that are important. So, let’s see what according to the Agile Manifesto should be valued more than the other when developing software.
Individuals and interactions over processes and tools:
It is the first value of the Agile Manifesto. It is crucial to value people more than tools or processes as people drive the development process and respond to the needs of the business. The teams will be less likely to meet the needs of customers or be less responsive to change if tools and processes direct the process of development.
Communication is one of the best examples that differentiates between valuing individuals and tools. When interacting with individuals, the communication process is smooth and only happens when the need arises. Whereas in the case of tools or processes, communication has to be scheduled and even requires a particular content.
Working software over comprehensive documentation:
In the past days, a huge amount of time was spent on documenting the product for ultimate delivery and development. Interface design documents, technical specifications, technical prospectus, documentation plans, technical requirements, test plans, and approvals for each were required. The list was comprehensive and was the main cause for delay in the development process.
Agile does not discard documentation but makes it more effective in a way that provides the developer with the important information which is needed to do the work without being bogged down. The Agile Manifesto values documentation, but what it values more is working software.
Customer collaboration over contract negotiation:
Negotiation happens when a product manager and the customer workout on the details of delivery. During the negotiation process, certain points may appear on the way where details can be renegotiated. But once the negotiation is over, there can be no further discussion about it. On the other hand, collaboration is entirely different. It implies that there is still room for discussion while the communication is ongoing.
With traditional development models like Waterfall, prior to any work settings, customers were able to negotiate the requirements for a product in detail. This meant that they were engaged in the development process before it began and even after it was finished, but they were not involved during the process. But Agile Manifesto breaks this barrier by allowing customer involvement throughout the process. This helps agile teams to align with customer needs in a better way.
Responding to change over following a plan:
According to a standard thought process, changes are expensive and must be avoided at any cost. The intention here is to develop elaborate, and detailed plans with a certain set of features to deliver and by sticking to product specifications and timelines.
But, experience always teaches us that changes are must and instead of running away from it we should welcome it and plan accordingly. With Agile change is not an expense, it is initial feedback which helps to enhance the project. It should not be avoided as it provides additional value.
Agile offers short sprints, through which teams can receive immediate feedback and change priorities from iteration to iteration within a short notice. And in the next iteration, new features can be added.
With Agile you can also plan, but it mostly makes use of just in time approach where planning is executed just when required. And with the progression of sprints, the plans are always open to change.
In addition to the above-mentioned values of the Manifesto, there are 12 principles that support it. These principles are very basic and tell you more about the ability to make the right decision in a particular situation.
1. The highest priority should be to satisfy customers via continuous and early delivery of valuable software.
2. Adapt to changing requirements throughout the process of development. The Agile process applies change for the competitive advantage of customers.
3. Frequent delivery of working software, every couple of weeks or a couple of months, in regards to a shorter timescale.
4. Developers and business stakeholders must work together throughout the project.
5. Create projects around motivated individuals. Trust and support them to get the job done.
6. The most effective and efficient way to convey a message or information within the development team is to enable face-to-face interactions.
7. Working software is an essential and primary measure of progress.
8. Agile processes encourage sustainable development. The users, sponsors, and developers should be able to support a consistent development pace.
9. The constant attention towards creating a design and other technical details enhances the process of agility.
10. Apply simplicity- develop just enough to get the job done for the time being.
11. The best designs, architectures, and requirements are encouraged by self-organizing teams.
12. The teams should regularly reflect on how to become more effective. Enhancing skills, self-improvement, techniques, and process improvement help teams to work more efficiently.
As agile is a set of principles and values, it’s a real benefit is providing people a common and a better foundation for making decisions in the best way possible to develop software. For example, consider a new project that is in a discussion on how to get requirements from a business owner. The recommended approach might be to get the business owner to write down all the requirements and sign on them before beginning the work.
But a team that is following Agile would ask the following questions:
1. While that may work, won’t it be different to the belief that we should value customer collaboration, rather than valuing contract negotiation?
2. And doesn’t it breach our principle that states the developers should be working with the business owners every day?
3. How can we make this decision in a way that is consistent with the principles we follow and our values?
Or you can even consider an example of a developer who is working on implementing a feature for the business owner. While working on the project, the developer may realize that he needs a database to make the feature work.
But the first thought that comes to the developer’s mind is to stop working on the feature and construct a strong database layer that will provide support for other development that will be needed later and handle the requirements of the feature.
And if the developer believes in the agile values and is trying to follow agile principles, he will find a way to build just what is necessary to deliver the feature, that will align better with the principles.
When you have a team that is following Agile they will be making hundreds of decisions each week in the ways described above. This is what it means to be agile. Taking each decision based on the values and principles that the team has decided to follow.
The decision making process matters. You cannot sideline things by taking on and engaging with decisions made by another team and just blindly following what they decided to work on. Another team may make decisions based on the Agile principles and values that end up in a particular way for them. But by merely trying to copy another team’s practices and actions will not make your team Agile.
The things that can be easily noticed in a well functional agile team are the practices they are utilizing. And these practices that a team decides to implement and use are only the result of following Agile principles and values. What practices a team happens to make use of is less important than why they are using it. In fact, as time passes the better agile team is likely going to improve and change the practices that they follow. A team may begin with Scrum (agile framework for managing knowledge work) and in the future find out that Kanban (agile scheduling system) is more suitable for delivering value to their customers.
That isn’t to say it’s useless to look at practices being used by teams that are performing well, but you can’t go looking for practices to make you Agile. Your principles and values are what will make you Agile. You have to look for practices that support your principles and values. The way you select your practices will determine whether you are being Agile or not. If a practice is being selected because it looks like a good way to follow Agile principles, it’s probably the best place to begin.
A team can become Agile only if they make decisions based on Agile principles and values. Hence, the decision-making process will decide whether a team can become agile or not. Agile values and principles have enough flexibility that can be implemented by teams in a wide variety of organizations to help them continually move forward making full use of their potential.
You must be logged in to post a comment.