Estimated reading time: 4 min
It is thought that traditional approaches to software development are fast enough. However, today’s “fast enough” may not be enough for tomorrow and the business is changing quicker than ever. It is reported that the rate of change in the world has accelerated dramatically over the past years, especially over the past 10.
You have to keep up with the accelerating rate of change. If you don’t, you’ll stop being competitive. Speed is the advantage - teams need a methodology that helps build software quicker and at lower costs. That will result in gaining a competitive advantage on a fast-moving market. That’s why we need Agile.
making up for 11,000 per hour and 259,200 per day! Even though that number is lower for the U.S. alone (3 startups per minute on average), that pace is still a real threat.
The ability to respond to changes quickly
Frequent deliveries of software
Close collaboration with customers
In others words, it means that we gather often, we communicate a lot, we change things quickly and we deliver more, more frequently. Agile works great with the lean startup methodology - it’s perfect for rapid MVP development.
Agile development process
Conventional project approaches consist of one big process. You gather all the requirements, design everything, build the product, verify it and go to market. That’s what we call a waterfall model.
But what if something changes during the process? It’s almost impossible to remain flexible during those massive phases. Because of the length of a whole process, a product launched as a result may not have a value for consumers anymore what makes a product worthless. Users’ needs change fast and stories defined only once in the very beginning may not be valid now.
Waterfalls lack constant feedback (idea validation), they require a lot of time to deploy new features and results cannot be seen until the end of a project. Wasting your time and money on developing a product that fails is definitely not a thing you want to do.
Agile is different. We still collect requirements and make a backlog (a list of features, user stories) out of them, but we don’t develop them all at once and we often add more during development. We split them into groups which we will build later during sprints.
A sprint consists of a number of small stages (plan, design, develop, test, deploy, review, launch) done in a short period of time (a day or a week). After finishing all of them the whole process is repeated for another group of features. Each sprint results in launching something - usually a new product version, some features or a part of a project. You get real results right away.
You can change anything, you can add new user stories and you can check new features with every launch, that is the end of each sprint. There are as many sprints as required to develop all things on the backlog gathered at the beginning of the project.
Once a usable release is built, the project is ready for implementation. And it’s ready promptly.
One of the most important things about adopting Agile is attaining a feedback loop which allows you to validate your ideas and to answer new needs. You verify your product with every sprint getting knowledge you need to improve it. You are a part of the team - you participate, you see results constantly, you can adjust your ideas quickly. Together, we develop right things right in no time.
There are a lot of advantages of using agile approach for development. What’s the most important is that the methodology helps with improving customer satisfaction by delivering better quality products in less time. You’ll be able to see the benefits of adopting agile development probably within the first three to six months and certainly within the first year. And we’re talking about serious improvements here: it is possible to double the number of released features and to deliver a few times more value to customers compared to previous years.
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.
Arie van Bennekum
Robert C. Martin
© 2001, the above authors this declaration may be freely copied in any form, but only in its entirety through this notice.