In this installment, we will briefly discuss many of the often-discussed (and maybe one or two that are not-so-often mentioned) benefits of agile methodologies.
Deliver early and often
After each development sprint, working software is delivered. This means that, unlike a waterfall project, an agile project (assuming four-week sprints) will never be more than a month off target. This is a significant departure from the waterfall horror stories we have all heard (and some of us have witnessed firsthand). Requirements are given, agreed upon and signed off on. Then, the developers spend a year writing millions of lines of code, leading up to the "here's hoping we got this right" demo, which is inevitably so far off target that you almost instantly have to allocate additional funds to try to fix things without losing momentum.
The capability to provide working software and get feedback after each sprint, coupled with the iterative planning and prioritizing associated with the sprints themselves, allows for changes, both large and small, along the development path.
Transparency
In addition to delivering working software after each sprint, developers are required to report progress daily under agile guidelines. This results in the latest sprint-level and release-level status reporting on a daily basis as well.
This approach leads to complete transparency at all levels at all times. If a developer falls a couple of hours behind, you can almost instantaneously determine if that anomaly will have an effect on the overall delivery of the task, feature, sprint or release.
Flexibility
The capability to react not only at the sprint level (every four weeks or so) but at the DAILY level is possible only with agile. In order to necessitate a sprint-level reaction based on the daily reporting, there is usually a significant error in task or feature estimating. We will cover this later in the article, but for the purposes of this section, it is significant to know that it's possible to react that quickly if the parameters of the project change mid-release or even mid-sprint.
Agile's flexibility has become a requirement of modern development projects. If you have never before attempted a cloud-based application programming interface (API) for exposing some or all of your proprietary corporate data to the development community at large, developing that using a waterfall approach would have to be several orders of magnitude scarier than an agile approach, where you can tweak releases, sprints, features and developer tasks after every sprint, as you learn more and more about the process and technologies involved.
Another item of note is how well-suited agile is (and how poorly suited waterfall is) to cloud development in general. It seems that all of the significant cloud providers are releasing new features almost monthly. The only way to stay current and take full advantage of these features is by having the flexibility to adapt your code quickly and efficiently, which agile allows.
Engagement is king
Another key benefit of agile is that it favors flexible, collaborative communication throughout the process. What this brings along with it is a level of engagement that is not possible with a waterfall approach.
The product owner and other "customer" resources are intimately involved from the onset. This higher level of engagement, as it is not optional, always alleviates the lack of customer involvement in a waterfall project. Furthermore, the product owner is responsible for making decisions that affect all stakeholders, giving everyone representation, if not an actual seat at the planning table.
Couple this level of engagement with the iterative nature of having short development sprints, and the customers and stakeholders have no choice but to stay engaged, as they are seeing working software and providing detailed feedback after each sprint.
Quality
Because every developer is also a tester, quality assurance is built into the agile process from the beginning. This is part and parcel to the concept of delivering working software at the end of each sprint. "Working" means that the software has been developed and tested with the appropriate rigor and thoroughness ... and that happens for each feature of each sprint.
Indeed, no feature can be marked "complete" until it has been fully tested and is ready for release as part of the "end of sprint" delivery. This does not constitute anything close to User Acceptance Testing (UAT), a requirement in many companies. We will address that as a concern in Part 2 of the series.
Cost predictability
By definition, agile projects start and end at a certain time. By definition, agile projects do not, and should not, allow for a "push to release, also known as a "death march," scenario.
If you know how many sprints you have in a release, how many resources you have on the project and the cost for each of those resources, you can predict, with relative certainty, the cost of the project. The way this phenomenon is enforced is through the concept of "Next Release" (see below).
Happy developers
Hiring and training new developers is hard. Most folks prefer to keep the ones they have. If you have spent any time around developers, you know that the ones who produce the best code are usually a bit more "high maintenance" than those that do not produce the best code. If you are lucky enough to attract those top-tier developers, it is always in your best interests to keep them happy.
Agile has many qualities that developers enjoy, not the least of which is the lack of a possibility of that "death march" described above. Another developer-friendly concept is that agile allows developers to be involved in the requirements gathering and estimating, ensuring a level of investment and ownership not usually possible in waterfall development.
But perhaps the most important agile quality that most developers enjoy is the sense of autonomy they have day-to-day. They attend the daily scrum and then are free to work on their code with no one looking over their shoulder.
To be fair, this is the default action and adult behavior and code quality are assumed. However, if a developer is struggling, it is always possible to manage by exception under agile methodologies without negatively affecting the time line or quality of the overall team, sprint or release.
Use the next release
While "Next Release" is associated with software that comes from honest-to-goodness software companies, it is an integral part of agile development. If you choose to ignore the "Next Release" and pull everything forward into the current release, you are ignoring a key part of the methodology.
Using the "Next Release" means that, by signing up for an agile development methodology, you are prepared to take one or more features from the product backlog of the current release, which are (hopefully) the lowest priority and have been overcome by the events of the current release, no matter the reason, and move them to the product backlog of the "Next Release".
At many large companies, the concept of "Next Release" is completely at odds with complex processes around procurement, bids/proposals and budgetary planning. We will address that in Part 2. For the purposes of Part 1 - the "Next Release" is assumed to be already bought and paid for.
An agile example
Since agile projects are time-boxed, it is easy to propagate the effects of today's development efforts throughout the life of the current project.
Please watch the companion screencast to see how some of these benefits work together in a real-world scenario.