What Agile is All About: Tips for a Successful Agile Project
Most individuals working in the software industry are aware of Agile approaches to software development. While many of us have likely worked on an “Agile” project, few have a solid understanding of what being Agile really means. Part of the reason for this disparity in understanding is that many teams will adopt the easy parts of Agile (like the daily stand-up) without committing to the more difficult and time-consuming parts such as upfront testing and frequent delivery of working software. To say that Waterfall is dead is an oversimplification of the problem but Agile projects do offer a distinct set of advantages over the more traditional approach to software development.
The Agile Manifesto sits at heart of Agile and defines the core principles guiding the methodology. Agile Software development is an iterative approach to software delivery that builds and delivers software incrementally instead of delivering it all at once at the end of the project.
Agile differs from traditional software development in a number of ways and the advantages inherent in the Agile process have been driving the adoption of Agile methodologies across the software industry as a whole. In this post, I’ll go over some of the main differences between Waterfall and Agile and the most beneficial solutions Agile can provide you on your next project.
User Stories and Estimation
User stories are the features that a customer might one day want to see in their software. A good user story abides by the characteristics of INVEST (Independent, Negotiable, Valuable, Estimable, Small and Testable.) Each user story represents a small piece of functionality that will provide some value to the end-user.
- As an admin user, I can delete an appointment from any employee’s calendar
- As an authenticated user, I can filter my search results using facets
- As a new user, when I register for an account, I receive a welcome email
However, unlike requirements in a traditional software project, these are negotiable and subject to change as the client becomes more knowledgeable in the problem domain and has the opportunity to experiment with early releases of the application and respond to customer feedback. These user stories are typically scored on a relative scale using points rather than an absolute metric such as hours or days.
Studies have shown that the absolute estimates used in traditional workflow methodologies are little more than overly optimistic guesses made before any real information is known about the business environment, the technologies to be used, or the project team performing the work. On the other hand, sizing stories is easier as the project team can usually compare one story to another in terms of complexity and risk. If a story is too “large”, it can be broken down into smaller stories. These can then be scored, developed and delivered separately in an effort to keep the product as simple as possible and maximize the work not done. This set of scored user stories is gathered into a list (often referred to as the backlog) which the customer prioritizes so that the most important features are worked on first.
User stories should be independent from one another so that they can be delivered separately and re-prioritized as needed without worrying about tight dependencies. In practice, I’ve found that order independence is at times hard to achieve because of an inherent relation between stories. For example, we couldn’t implement an enhancement to the search page functionality before the user story for the search functionality is completed. In some cases, stories can be combined to reflect this dependence but in other cases, this order dependence must be reflected in the backlog priority and taken into account when planning iterations.
Iterations and Planning
An Agile iteration (often referred to as a sprint) is a short period (usually between one to two weeks in length) where the project team works on a set of user stories selected by the customer from the backlog, based on order of importance to the business. Analysis, design, coding and testing are all on-going throughout the iteration and the output of an iteration is working software which has been vetted and accepted by the customer as complete. Unlike traditional waterfall projects where testing is one of the final phases of the project where time and budget are the most stretched, Agile promotes quality by enforcing continuous testing and delivery throughout the project lifespan.
The Minimal Viable Product (MVP) reflects the customer’s opinion of the minimum set of features which needs to be completed before the product can be released to a production environment. As the customer views early versions of the application, they can offer feedback which can drive the creation of new user stories. This extra visibility ensures that the customer satisfaction is always kept at the forefront of agile project development.
This production ready software is valuable to the customer but the iteration itself is also a great way to track progress against the project timeline. The number of points a team can complete in an iteration should stabilize into an average velocity that will provide early feedback to the customer about how much work can be completed by a designated date.
The project plan is continuously updated to reflect the reality of the project execution. If it becomes evident that there is too much to do and too little time, an Agile team’s first option will be to do less and flex on the scope while maintaining the time, budget and quality constraints. Since the project backlog is prioritized and the customer has the ability to re-prioritize stories, the most important features are always delivered first and quality is never sacrificed to increase scope. In fact, Agile enforces simplicity by attempting to maximize the amount of work not done wherever possible.
Embracing Change
If your customers have perfect foresight, can predict external market changes and changing internal political climate, can predict end-user feedback, know exactly what they want now and any enhancements they will need in a year and can communicate this all perfectly, then you likely have no need for change management. However, for the rest of us mere mortals in the software industry, changing requirements is a reality (and in some cases, a huge headache).
Requirements can and do change for a variety of reasons. Whether a stakeholder realizes what they asked for isn’t what they really need, a requirement was missed during design, or changes in the marketplace push the product in one direction vs another, change is a natural aspect of any software development undertaking.
In a traditional waterfall project, changes to requirements are resisted once development has begun and cannot be easily incorporated into the project plan. Changes during a Waterfall project get exponentially more expensive as time progresses and as a result, rigorous change control procedures are put in place to keep these to a minimum. Conversely, Agile embraces change as inevitable, even late in development and harnesses change for the customer’s competitive advantage. In Agile, stakeholders have the right to add new requirements, change existing requirements and even reprioritize requirements as they see fit without the need to pay exorbitant prices for these changes.
Each change is represented as a new user story which will be prioritized by the customer and scored by the project team. Through open planning and modern software development practices Agile attempts to flatten the cost of changes as time progresses while providing early feedback to stakeholders about the impact of changes to the project schedule and budget. This flexibility ensures that the customer is satisfied and that the product represents what stakeholders actually need rather than what they initially thought they wanted on the inception of the project.
The Best Types of Projects for Agile
Though Agile has been gaining in momentum in the last few years, it is too early to say that Waterfall is dead. In fact, many recent variations of the Waterfall style of project management do incorporate some concepts from Agile in an attempt to gain some of the benefits without needing to overhaul existing corporate cultures and organizational methodologies. Agile is not necessarily a silver bullet that will resolve all the issues inherent in software development but it does provide a distinct set of advantages over traditional software development including but not limited to:
- Increased levels of software quality
- Increased customer satisfaction
- Shortens time to market
- Increased transparency and visibility
The benefits of Agile are fully realized in non-static projects where the requirements and scope are not strictly defined and there is a greater need for flexibility. I believe that the tight feedback loops ingrained in Agile and its flexibility make it a natural fit for the software industry. When money and time are fixed but the requirements are likely to change you should consider an Agile approach.
What are some of the ways you've incorporated Agile into your approach and have you found it more beneficial or challenging? Join the discussion and share your thoughts via the comments below.