The foundation of all long-term success lies in building a resilient and growth oriented mindset. Without ground-work, there could be no success story. This is a universal rule which applies to almost anybody to anything. As Messi once said “I start early, and I stay late, day after day after day, year after year. It took me 17 years and 114 days to become an overnight success”. We hope you know that Agile is not just a methodology, it’s a mindset. Many Software development methodologies evolved over the years, but why do you think Agile development stuck? What made it so popular? Yeah, the Foundation! The Agile Manifesto was written in February of 2001 by seventeen independent-minded software practitioners. The Manifesto defines four Agile values and twelve principles which forms the foundation of the agile movement.
The Agile Values
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
© 2001, the Agile Manifesto authors
Individuals and interactions over processes and tools
A fool with a tool is still a fool 🙂 Yeah! Process and Tools are important, but what if the individuals involved don’t have the skill set? Even the best of tools are of no use in that case. First, it should always be about the people and how they work as a team >> Process and tools are just to aid better software development. As we say – Teamwork divides the task and multiplies the success. So don’t talk ‘about’ each other, instead talk ‘with’ each other 🙂 just replace that ‘I’ by ‘We’ and turn your ‘Illness’ to ‘Wellness’!
“Train people well enough so they can leave, but treat them well enough so they don’t want to“ – Sir Richard Branson!
To facilitate communication, agile methodologies rely on frequent inspect-and-adapt cycles. These cycles can range from every few minutes with pair programming, to every few hours with continuous integration, to every day with a daily standup meeting, to every iteration with a review and retrospective.
Working software over comprehensive documentation
Many of you who have industry experience know this difference very closely. Technical Design, Interface design, Test Plan, Environment readiness, Understanding document, Metrics, etc. – enormous amount of time is spent on documenting the product for development, testing and ultimate delivery. What do you prefer – focus on working to build & test a software OR capture each & every progress by maintaining documentation? Yeah! Building the product indeed. Documentation should be kept bare minimum, only the most important documents.
Taking a look from the client perspective – what do you think a client would prefer? A fifty page document describing what you intend to build or the actual software itself? The working software indeed. All of the agile methodologies stress on delivering small pieces of working software to the customer at set intervals. Documentation has its place, written properly it is a valuable guide for people’s understanding of how and why a system is built and how to work with the system. However, never forget that the primary goal of software development is to create software that is clear & self-explanatory, not documents.
Customer collaboration over contract negotiation
Only your customer can tell you what they want. Yes, they likely do not have the skills to exactly specify the system. Yes, they likely won’t get it right the first time. Yes, they’ll likely change their minds. When is it better to find out that your requirements may not be what you really want? During the project when you can do something about it? Or at the end of the project when it might very well be too late to do anything about it?
With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to starting any work. This meant the customer was involved in the process before actual development began and after it was completed, but not during the process. The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process.
It’s important to find ways to separate the legal relationship you have with your customers from the product relationship. Contract negotiations have their place, but they can easily create a boundary with your customer that doesn’t help you develop great software. Successful teams work closely with their customers and communicate with them frequently. Create a relationship with customers that encourages communication and you’ll quickly learn their thoughts, opinions, and preferences.
Responding to change over following a plan
As they say “The art of life is a constant readjustment to our surroundings.” – being Agile! Agility is the ability to adapt and respond to change…Agile organizations view change as an opportunity, not a threat!
What do you think is better? Developing a custom website for Client in 6 months just to know that technology has evolved in the background and now the client wants a Mobile App OR getting a continuous feedback and then readjust the strategy after 2 months to eventually develop a Mobile App in 7 months? Yeah! The choice is simple.
Industry data shows that over 60 percent of product or project requirements change during the development of software. Domain understanding change. The business environment changes. Technology changes over time. Even when traditional projects finish on time, on budget, with all features in the plan, customers are often unhappy because what they find is not exactly what they wanted.
There is nothing wrong with having a project plan, but a project plan must be malleable, there must be room to change it as your situation changes otherwise your plan quickly becomes irrelevant. Agile methodologies seek customer feedback throughout the project so that teams can incorporate feedback as the product is being developed.
It is not the strongest of the species that survive, nor the most intelligent, but the one most responsive to change.
Point to be noted
One of the most important point to be noted here is that Agile values are NOT against the traditional values. The Agile values just pay MORE attention to Individuals, Software, Collaboration and Change. In other words, The Agile values define ‘preferences’, not ‘alternatives’. The interesting fact here is that many organizations claim to be Agile, I.e. that they follow the basic agile values but in reality they are nowhere close – they still follow ISO-9000 compliant processes and treat their staff as replaceable assets, produce terabytes of irrelevant documentation and follow a rigid plan.
Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.