AGILE – the new buzzword in project management. What does Agile stands for? Agile is the Adaptive methodology which got prominence in 2001 when 17 Agile practitioners came together in USA and announced the Agile manifesto.
Agile was there before 2001 and it was not a sudden development. You can read History of Agile and get a perspective how Agile came into being in 2001.
Many organizations see the value from using Agile practices:
- Adaptive and flexible to the changing business requirements, giving the organization more scope to add, remove or modify the requirements.
- Early and continuous customer feedback improves communication and empowers business owners who can receive and review critical information necessary to make decisions to steer the project throughout the development process
- Early measurable return on investment
- High visibility and influence over the project
- Project Progress leading to early indications of problems
- Incremental delivery rather than a single complete delivery at the end of the project; reduces product and process waste
The Agile practitioners’ group which met in 2001 announced the Agile Manifesto. The Agile Manifesto talked primarily of 4 Values and 12 principles.
Agile Manifesto
4 Fundamental Values:
- Customer Collaboration over Contract Negotiation
- Working Software over Comprehensive Documentation
- Individuals and Interactions over Processes and Tools
- Responding to Change over Following a Plan
It was agreed that the items on the left are valued more than the items on the right. That does not mean that the item on the right, e.g., Comprehensive Documentation should be avoided. It only suggests that Working Software is more important than Comprehensive Documentation.
Let’s look the same into more details:
- Customer Collaboration over Contract Negotiation
In today’s age of knowledge workers, things change as no one is quite sure on how the software or the knowledge outcome is going to shape at the end of the project. It is important that both the parties, i.e., the customer and team realize the same and agree on common definition and accept the fact that the things change over a period of time. Hence, collaborating with the customer is more important than sticking to the fact that the initial acceptance is what it was and stick to that, and negotiate to get more. “Doing the thing right” than “Doing the right thing”.
- Individuals and Interactions over Processes and Tools
This suggests where your primary focus should be. The entire project is executed by people, right from the defining the scope, solving any problems or challenges or accepting the deliverables. The people and individuals are most important and it is essential that we focus on them and train & develop them to get the best out of the project.
That doesn’t mean that processes and tools are not important. The Processes are important to follow; however, our bets attention should be focused on individuals and their interactions.
- Working Software over Comprehensive Documentation
The Agile approach to documentation is “Just in time, Just enough and sometimes – just because”.
The idea of documenting “Just in time” means that the documents should be updated as a last responsible thing so that any changes or updates are well understood.
Documenting “just enough” is to take of bare sufficient things to cover the essential needs.
And Documenting “just because” someone requests is better doing than facing the consequences of not doing it. For example, in a govt set up, it may be a compliance requirement.
- Responding to Change over Following a Plan
Changes are inevitable they say. Changes are in fact good for the project. And Changes are bound to happen. And the idea is NOT to guard the changes and just follow a plan, but respond to change and incorporate the same by collaborating with the customer. Not that the plan is not valued – Planning is absolutely essential but also acknowledge the fact that you cannot know all the things upfront and changes do happen in the project.
Agile software development principles
The Manifesto for Agile Software Development is based on twelve principles:
1.Customer satisfaction by early and continuous delivery of valuable software.
This principle is talking of 3 things here:
Customer Satisfaction – This is of paramount importance. The project essentially tries to satisfy the customer needs and hence, the customer.
Early & Continuous Delivery – The idea is to deliver incrementally and continuously so that customer accepts the end deliverable or even reject or suggest changes at the start itself.
Valuable software – The project should be able to add value to the customer providing a valuable system or product or service or deliverable.
2. Welcome changing requirements, even in late development.
Changes are inevitable. And changes can happen during any time of the project. It is important that we detect the changes early in the cycle rather than late which will reduce costs. In some other project methodologies, managing changes itself takes considerable time and effort, and generally, changes are discouraged. However, in Agile methodologies, changes are embraced and welcomed.
3. Deliver working software frequently (weeks rather than months)
It is more of human intrinsic nature that we share the software in its completed state rather than on a regular basis. However, in Agile methodologies, the idea is to get feedback early in the cycle rather than later. It is recommended to show the deliverable or software continuously to garner feedback and make the necessary corrections, which sets you in the right direction.
4. Close, daily cooperation between business people and developers
Customer Collaboration is one of the 4 values which the Agile manifesto emphasizes. It is important for both the parties to constantly be in touch with each other and ensure that feedbacks are continuously taken in the right spirit. Agile methodologies use the tool of Daily Scrum meetings. Constant meetings and interactions with business people give more insights than just mere requirements for the development team.
5. Projects are built around motivated individuals, who should be trusted
Projects are built around the best of the team members. It is a proven fact that the right talent takes the project to successful delivery. It is important to empower these individuals and motivate them to perform better. Many times you do not get the best of resources and here it is important to motivate the individuals and trust them to do the job.
6. Face-to-face conversation is the best form of communication (co-location)
The most effective method is face to face conversation. It is estimated that 55-70% of communication happens through body language. Written documentation, on the other hand, need to assume that the context is not provided and you have to begin on a low starting point.
7. Working software is the primary measure of progress
I had met a very senior officer for one of my projects. He was reluctant to disburse any payment for the milestones as per the plan. His argument was that he cannot see or check what we have done. He was comparing to other projects he was handling and said that he can disburse money for other projects such as road construction, as he can see 20% of the road being completed. However, in software, it is difficult to do so. Working Software is the primary measure of success.
8. Sustainable development, able to maintain a constant pace
Sustainable Development is maintaining a constant pace, which helps in growing working conditions and working relationships. Unlike say, in RAD (Rapid Application Development), where long intense working hours can burn up the individual and result in resignations, and loss of domain knowledge and resource. This can be pretty expensive. Maintaining a constant pace at say 40 hours a week helps in sustainable development.
9. Continuous attention to technical excellence and good design
This is more related to software and can be applied to other industries as well. The developmental effort is highly valued; however, it is also important that the design is up to date. The design is also important which brings the necessary clarity for development efforts. The team should give importance to preventive measures and other things such as Refactoring of code to make a good end product.
10. Simplicity—the art of maximizing the amount of work not done—is essential
It has been observed that the users tend to use only 10-20% of the features in a product. The rest are very infrequently or never used. The more the complex system, the lesser the features that are used. Thus, agile methods seek the “Simplest feature that could possibly work” and the solution built around that. This not only mitigates the risk but also is a great confidence booster.
11. Best architectures, requirements, and designs emerge from self-organizing teams
The best decisions are taken by self-organizing teams. They know the environment; the technical details and they are the closest to what’s happening on the project. External help look great on paper, but when self-organizing teams take decisions, they know they need to abide by them – so they will ensure that the decision works for the team.
12. Regularly, the team reflects on how to become more effective and adjusts accordingly
Gathering lessons learned at the end of the project is a tad late or less effective. You can take the lessons learned while they are still applicable and implementable. That means we should take lessons learned during the project and not after the completion of the project. This helps the remainder of the project to be more effective.
By Ashish Sadekar
– Founder & Director
