Agile for Developers With Video – Part 2

What does Agile for developers mean, and why are the Agile Values and Principles necessary for todays software development companies?

The History of Agile

A 59 Seconds Agile Video Animation
The History of Agile with 59 Seconds Agile

The History of Agile for Developers

A 59 Seconds Agile Article

This article provides an ‘Introduction to the History Of Agile’ and looks to discuss how the Agile values and principles were formed . It provides a brief introduction into the history of Agile and why Agile is important to the developer role.

The History of Agile

Maintenance is the final step of waterfall development and is strictly for keeping existing software features functional. Even if customers have since developed new needs, it is too late to apply them in a waterfall project. These new requirements need an entirely new project, with all of the same problems and downsides as the previous project. The maintenance phase allows no room for software evolution and improvement.

The biggest issues with waterfall development are project time frames and resistance to change. Since each step is fully completed in one pass, adding or changing requirements and features later is basically impossible. Despite the fact that the customer requirements may change as the product evolves, waterfall demands that all of the documentation be set at the beginning.

With this resistance to change and the fact that problems allow for fewer solutions, waterfall projects typically take a very long time. Individual products may take years, or possibly even decades to complete. With the accelerated pace that the technology industry evolves, this means that a software product is often outdated before it even reaches customers.

Agile for developers: A Need for Change

In the 1990’s, a group of experts in the software development field got together to create a new style of project management. They discussed the problems with existing methods, and how these could be improved upon. First and foremost, software development should be lightweight, hence the name “Agile.” Also, projects should be accepting of change, from customer needs or any other source. In 2001, the Agile Manifesto was drafted and began the process of implementing a new style of project management.

Agile for developers: Agile Development

With the barebones Agile Manifesto, goals are simple and straightforward. Instead of a complex list of rules and policies, the manifesto gives a few simple priorities that organizations can apply in their own way. This makes Agile software development very modular and improves the experience for all roles involved, especially the developer.

The biggest change between Agile development and waterfall development is the cycle of steps. Instead of having each step done fully, one at a time, every step is performed for small repeatable iterations of the software development. This allows the team to spend less time in each individual step and gives ample opportunity to improve on previous iterations.
What does the cyclical nature of Agile mean for developers? Most importantly, this means less development time. Instead of spending years working on software before it gets to customers, stakeholders receive new iterations of software every few weeks. Less effort is wasted with each cycle, and so the stagnant delays of waterfall are replaced with fast-paced cycles.

Agile for developers: Adaptable Agile Development

In addition to less wasted time, Agile is more adaptable. This gives developers the opportunity to adapt to requests and write code accordingly. Stakeholders can express new requirements or changes, and those get prioritized with the rest of the work for a project. There is never a point at which customers are cut off from requesting new features. Requests just may not make it into the product if they are not deemed a high enough priority.

Since verification is done after every sprint cycle, less technical debt builds up. Developers have the opportunity to take care of smaller bugs soon after they appear. Instead of having vast amounts of broken code, they only have to fix what has been introduced in the most recent sprint. This means that they rarely have the opportunity to build on features that are already broken. Everything is working the way it was intended before the team moves forward.

While the waterfall method is not perfect, it did have good intentions. Early software developers had nothing to base their methods off of, besides hardware. This worked for a time, but it was far from ideal. When experts began to analyze new methods, they came up with Agile. With Agile software development, teams create better code, that more appropriately appeals to customers, and with more efficiency.

Prev <— Continue Reading —> Next

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.

Continue Reading —> Next

What is Agile?

A 59 Seconds Agile Infographic
59 Seconds Agile - The History of Agile
59 Seconds Agile – The History of Agile

Prev <— Continue Reading —> Next

User Stories Applied

A 59 Seconds Agile Book Review

User Stories Applied by Mike Cohn is one of our favourite books on Agile User Stories. The book starts with an overview into user stories, and details what a user story is and the different aspects of them. He then discusses how to go about writing a user story, and provides details of the INVEST criteria that can be used to determine if the story is meeting all of its objectives. Next Mike gives an in depth discussion of who user stories are written for and where to begin when gathering the details for them. The book then discusses acceptance testing user stories, including how to go about specifying these criteria and the responsibilities of the development team and customers during this process.

Continue Reading —> Next

Our Favourite Agile Books

We found these books great for finding out more information on Agile Scrum: