What is Agile development?

What is Agile development?

To understand what Agile Development is, you must first understand what came before and why there was a need for change.

The Waterfall Methodology explained

Before Agile Development, software developers used something called the ‘Waterfall Methodology’, this being developed in the 1970’s. In its time it was the gold standard for any software development project. The process entailed the production of what was known as ‘the Spec’. This was a very detailed document, a business requirements document which covered everything the business needed the application to provide.

By definition, these documents were often very long, as they had to detail literally everything, from strategy to a comprehensive list of functional specifications, not to mention the visual user interface designs.

Once this was written and agreed, then a technical specification was created. This covered such areas as the applications architecture, data structures, object oriented functional designs and user interfaces.

Only then could the actual process of coding begin. The coding itself contained the sub processes of Integration and Testing, both having to be completed satisfactorily before the system was ready. As you can imagine, this process could take many years.

This in itself was the achilleas heal of the whole process, as over the time the application was being developed, the businesses needs could well have changed, this especially being the case when the Internet became of age in the late 1990’s.

Why Was The Waterfall Methodology so Slow?

In the 1970’s software development was very different. Most of the many development tools required specialised training, and the lack of open source or commercial software components, APIs, and web services meant that the coders had a lot more to do than they have today.

This meant that even simple applications required large teams. As the communication tools available were limited, this meant that the process could be extremely slow and error prone.

The technical specification document was the driving force, and no changes could be made to this without approval from the customer and the agreement of all the teams involved in the coding of the application.  Agreeing and communicating these changes across the teams, and making the code alterations was therefore very expensive.

The process was further hampered because the software developed was based on the technical architecture, the lower level artefacts being developed first, those dependent on them later. Each task was assigned to the appropriate technician then handed down to the next stage in the chain. This meant it took months before anyone saw the completed application working and by then, the real requirements were often better understood and that meant starting the whole process all over again. Something just had to change.

Agile Development to the Rescue

Agile Development was launched by 17 technologists in 2001, the process being built around a set of ‘major principles’, the purpose of which was to deliver better software.

The process is enshrined in what is called the Manifesto for Agile Software Development, the principle aim being to develop software more efficiently and in a manner that allows changes during the delivery of an application.

In other words, rather than deliver a complete system (after many months or years of work) the application is broken down into sections, each one being delivered before the next was started. This allowed for changes to be incorporated at each stage, even major alterations being possible as there was no overall technical specification to be altered.

The Principles behind the Agile Manifesto

The highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behaviour accordingly.

Through this Manifesto, the authors came 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, they valued the items on the left more.

Adopting Agile Development

Adopting the Agile Development methodology requires the creation of a whole new set of roles. Each of these roles covers a different part of the process, but before anything can be started, a vision statement, detailing the scope of the problem, any opportunities and the values that must be adhered too, has to be created. The Product Owner is responsible for this statement and works with a multidisciplinary team (or teams) to deliver this vision.

The Roles are:–

User

As would be expected, it is the User who occupies the centre of the stage and it is their needs that must be addressed. Different user personas are often used to ensure that the software supports the necessary operational flow, the different types of customers, their needs and behaviours.

Product owner

Just as with the Waterfall Methodology, a vision of what function or services the application is to provide must be understood. This is the job of the Product Owner. They have to be the voice of the customer as well as any internal stakeholders. They need to be able to distil all the needs, insights, ideas, and feedback to create this vision.

Unlike the Waterfall Methodology’s ‘Spec’ these visions are simple and short. However, they must provide enough detail about who the customer is, what values are being addressed, as well as providing a strategy on how all of these can be brought together.

The Product Owner must then work with the software development team (or teams), breaking down the overall vision into a series of user stories. It is these user stories that provide the detail needed, giving information on who the target user is, what problems are being solved for them as well as the importance finding that solution. Any constraints are also made known and the criteria for acceptance defined.

Each of these user stories are prioritised, each one being discussed with the team to ensure they have a shared understanding on what is needed.

Software development team

In Agile, the development team is built in a totally different manner to those associated with the Waterfall methodology. Here tasks were assigned to one skilled team, their job being very focused indeed. Once they had done their bit, the work was passed onto to the next team and so on, until the product was finished,

It is very much different in Agile. Teams no longer deal with just one small part of the process, and are multidisciplinary, being composed of a diverse group of people, which together have the skills to get the job done within that team.

This is important as the focus of Agile is for the one team to deliver the complete end-to-end functioning software for just one part of the overall application. This means that the database, business logic, and user interface of that part of the application is developed and then demonstrated rather than the whole application.

This requires the team members to collaborate and meet frequently too make sure everyone understands ‘who is doing what’, and what the overall picture on how the software is actually being developed looks like.

In order for any team to be able to truly deliver, software development teams often include quality assurance (QA) engineers, database engineers and back-end system specialists, the exact mix of the team depending on the type of software project.

Scrum, Kanban, and other agile frameworks

There are many different ‘frameworks’ used in agile development practices, but all are aligned to a software development life cycle.

Of all of them, the most popular is Scrum.  At its core is something called a ‘Sprint’. Every Sprint starts with a meeting, the structure of which is:-

• A planning section, where the sprint priorities are clearly identified.
• The commitment phase where the team reviews all the user stories and decides what can be delivered during that Sprint.
• The Communication phase. Here the members of all the teams involved provide updates and report of status of their part of the Sprint.

These meetings occur throughout the Sprint, the Sprint itself ending with a demo meeting. Here the functionality is shown to the product owner. Once accepted a retrospective meeting is held, the team discussing what went well and what changes are needed in their internal processes.

Kanban is another popular system, and uses a ‘fan-in and fan-out’ process where the team(s) takes the user stories from what is known as an intake board, funnelling them  through a staged development process until completion.

Also, due to the fact that many organisations have legacy systems (which are best left to the Waterfall system) some are forced to adopt a hybrid agile and waterfall approach. Here the Agile process system is used for new applications, the waterfall approach dealing with any legacy systems.

The Benefits of Agile Software Development

Customer Benefits

One of the greatest benefits comes from the fact that the entire application is broken down into small, short parts. Because of this, customers find that the supplier is able to be more responsive to any requests.

Supplier Benefits

Suppliers benefit as the amount of time lost in discussion about changes are reduced. Instead they are able to focus on the development of high-value features. The reduced time-to-market relative to waterfall processes decreases their overheads and increases efficiency. Also, because the Agile system allows projects to be delivered incrementally, customer satisfaction levels are improved, which in turn leads to higher customer retention and more positive customer testimonials.

Benefits to Development Teams

It is no surprise that the members of development teams like to see their work valued. Agile development provides this whilst also benefiting them by reducing non-productive work (e.g., writing the entire specification only to see it change before they have completed their works).  Team members also benefit as they can see that their work is truly valued, their efforts being chosen to maximize value to the customer.

Benefits to Product Managers

The Product Owner role is typically filled by a Project Manager. It is their job to make customers happy by ensuring that any development work is aligned with the customers real and stated needs. The Agile process makes this alignment easier by providing frequent opportunities to re-prioritize work and to change deliverables as needed.

Benefits to Executives

Scrum and other versions of Agile Development provides better visibility into the progress of a development project, often on a daily basis, to all the Executives involved. This means that they and all stakeholders have a better idea of what is really going on. They can therefore plan more effectively, and are therefore able adjust their strategies based on hard information rather than having to rely on more speculative data.

Conclusion

There is no doubt that any version of Agile Technology, whether it be Scrum or Kanban (or a any other variant) are powerful, proven process tools that can vastly enhance your project management as well as reducing costs and delivery times.

In order to choose what system or combination is the best option for your business it is best to become familiar with all of them, experimenting with the various aspects of each in your production environment.

Remember creating a hybrid of any Agile system with another or indeed with the Waterfall methodology is perfectly acceptable if that is what works best for you.