THE BEGINNING OF AGILE
In ancient times, when people weren’t communicating with Messenger or their smartphones, the word “influencer” didn’t have a special meaning and politicians weren’t expressing their point of view on Twitter, the term “agile” has now been born. It was exactly 2001, when a group of 17 IT specialists drafted the Agile Manifesto. They gathered in order to establish some major principles for developing better software:
“We are uncovering better ways of developing software and by doing it we are 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 planThat is, while there is value in the items on the right, we value the items on the left more.”
I guess you are wondering what this mysterious term “agile” means. Was there anything before the “agile” era? Keep reading.
OLD SCHOOL THOUGHT – THE WATERFALL METHOD
Let’s move to Canada for a minute. I am sure that if you visit this beautiful country, you will definitely want to see the famous Niagara Falls. Let’s sit on the shore and admire this amazing natural marvel.
I bet you think: “What’s the point of this story? There’s no connection between waterfalls and IT.” Are you sure? Try to use your imagination a bit – or I can help you visualize this picture.
Before agile, a waterfall model was the most common approach to software development. It works quite simply – once you go past a stage, you can’t move back. Just as with water in Niagara Falls.
It means that programmers must stick to rules that were set in advance, even if a market changes. Coders are limited by tons of documentation. Sometimes it takes months to build an application and it’s not even tested before it’s finished. What’s more, a client is also very limited. He can’t change his mind and suddenly add or delete some features. After compiling the requirements document, it won’t be possible.
The term waterfall model was first used by Winston W. Royce, in his article Managing the Development of Large Software Systems. This model emphasizes that a software development life cycle (SDLC) is composed of some specific phases:
■ Requirements: In this phase, a product manager should do his best to get the most specific information regarding a client’s outcome expectations. All requirements regarding a product specification should be written down. Later, software will be developed on the base of this requirements document.
■ Analysis: This is a stage, when all requirements are being analysed. A group of specialists study how to build a system, taking into account all necessary tools and materials.
■ Design: This phase concerns technical aspects of the design – programmers choose an appropriate coding language and technologies, the best and most compatible with a particular software development.
■ Coding: Bearing in mind previous steps, programmers start implementing business logic, which means creating the code.
■ Testing: It’s a moment when both a whole software and its particular parts are being tested. Testers look for bugs and report issues if they find anything not working properly.
■ Deployment: A piece of software is ready to launch – real clients start using a product. A deployment is not the end of a Software Development Lifecycle. Even more important is software maintenance – support in further product development.
Based on a waterfall model, software development was a very long, difficult process. In some cases it took years to get software ready to launch and a documentation had hundreds of pages.
In the 90s, people experienced a very rapid internet proliferation. The development of a global network had an impact on the birth of new coding languages such as PHP, Ruby and JavaScript. The evolution of technology caused the need to invent different approaches regarding software development – more flexible, matched to continuous market changes, and most of all – with faster implementation.
NEW SCHOOL THOUGHT – AGILE DEVELOPMENT
The growth of the agile approach has officially started with an Agile Manifesto in 2001, which I quoted in the beginning. However, the roots of this methodology can be found much earlier in Japan, more precisely – in the Sakichi Toyoda business approach. The founder of the Toyota brand was also the father of Kaizen and the precursor of “lean management” – a new way of thinking, based on improving business operations continuously, with a special focus on innovation and evolution.
The main objective of agile thinking is to minimise the time spent on preparing documents and overall planning. Coming back to Agile Manifesto (probably the most significant moment in the agile history), a group of IT specialists has set 12 principles concerning the agile development.
According to them, customer satisfaction is the most important. It can be achieved only when software is improved and changed continuously, no matter on which stage the product development is. The goal is to create valuable software, so that it becomes a client’s competitive advantage.
“Change” may be a key word to understand agile development. It’s much different than in a waterfall approach, where once requirements are determined, they can’t be modified in the future. In agile, programmers focus on building an excellent working software, not just a product adjusted to specifications (that sometimes may turn out to be wrong).
Like in “lean management”, the simplicity is the way a piece of software should be developed. When creating a code, it’s important to minimise the amount of essential work in order to create a better, good quality product.
The process of software development is divided into small parts, called “sprints”. At the end of every phase, everything is tested and consulted with a client’s representative. It is the perfect moment for a client’s feedback concerning possible changes and improvements.
According to the 11th annual state of agile report, organizations are succeeding with agile:
“98% of respondents said that their organization has realized success from agile projects.”
If you are not convinced that the agile approach is a good way to implement projects, I recommend you to track this website, where the 12th annual state of agile survey has been already published.
In many cases, an agile development is the best approach to implement projects. Be careful though, this is not the rule. In some situations, it’s impossible to apply this solution. There are some fields in which a waterfall approach works better. For example, when building a refinery, first you need to plan every step precisely, then build. When the project has a fixed scope, time and budget, a waterfall approach is a better choice.
And what do you think about agile development? When to use it? Share your opinion in the comments!
Need help with building a website or mobile application?