By now, you know about agile methodologies and how they can help improve your software development efforts. In this series of articles, we will discuss benefits of going agile (Part 1), some traditional concerns with agile at enterprise scale (Part 2) and offer some strategies you can use to become more agile in your shop while minimizing those concerns (Part 3). We also include screencasts to show agile in real-world scenarios.
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.
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.
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.