Agile Process Overview: Post 1 of 5

Software product development requires solving challenging problems; problems with an unknown solution. When building these products, work in process doesn’t generate business value. Value only occurs when a product is used. Therefore, an adaptable process is needed that generates predictable output in short iterations. The agile methodology has been designed to fill these needs.

Traditionally, software has been built in stages: requirements, followed by design, followed by development, then testing and support, often called “waterfall”. The agile development process adds predictability over this method, delivering high-quality results quickly and consistently. It further adds adaptability so the client can evolve their needs as the software product is being built, rather than define all needs up-front. The process, when done right, also delivers on the expectations of the end user by creating an inspiring experience that is easy-to-use and functions in accordance with user expectations.

Workshop — A Product Innovation Workshop defines and prioritizes your technology concerns, creating a roadmap, then brainstorms features and finally creates a a business-priorities high level roadmap. This creates the foundation for your technology strategy, clarity of your vision and the path to achieve that vision. This work also creates the foundation for what will be evolved into a full Product Roadmap and subsequent Backlog which are maintained throughout the life of the software product.

Product Backlog — The prioritized list of features that come out of the Workshop become the Product Backlog, defined as user stories (essentially, what users want to accomplish with the product). The backlog captures all ideas related to the product, regardless of priority or value. The backlog is continually re-prioritized based on expected value, with the highest value items being at the top. This means that you are continually working on the highest-value activities. Items that are prioritized and assigned to a sprint (see below) become part of the Sprint Backlog, and all user stories in the Sprint Backlog are clearly and completely articulated, along with acceptance criteria that help define when the user story is “done”.

Sprint — Every one to four weeks (based on the needs of the project), the project team takes the top items from the Product Backlog, refines them and creates a Sprint Backlog of work to complete in that sprint. The team then works on completing these items during the sprint. During a sprint, the items selected shouldn’t change — the scope of the sprint is firm. However, outside the sprint, the Product Backlog can, and should, be groomed often to account for change. This allows consistency and focus on the immediate development while allowing change to happen easily as business needs dictate. It also provides regular inspection points for clients and even end users to ensure that what is being built will generate the maximum value.

At the end of each sprint, a complete set of functionality is done. Everything needed to complete each selected user story, including testing, is done in the sprint, and the customer reviews the delivered set of functionality with the team and signs off on it being complete.

This process allows a solution to be built in iterations, with the highest value items being done first. This means that value is delivered quickly and often, allowing interaction with the features at the end of each sprint and the possibility of releasing those completed features into production for use by customers. This also accounts for learning and feedback from the team, the customer and the users, so that future sprints may take advantage of this learning.

This process is rigorous, but it is highly accommodating of change. Still not convinced? Years of best practices and data show agile’s value. Some examples of the value of agile from industry studies are outlined below:

Michael Mah did a comparison of 26 agile projects ranging from 26 to 1,000 people to a database of 7,500 primarily traditional projects. He found:

• Improved productivity — “Agile projects are 16% more productive at a statistically significant level of confidence.1”
• Time to Market — “Agile projects have a 37% faster time to market at a statistically significant level of confidence.2”

VersionOne, an agile tool provider, graphs the value as follows, showing the agile process in red and traditional development as a dotted line (Fig. 1). It further points out a few studies supporting this difference. In the United Kingdom, a study of 1,027 projects showed “only 13% did not fail, and waterfall-style scope management was the ‘single largest contributing factor for failure, being cited in 82% of the projects as the number one problem.’” Further, a U.S. Defense study of $37 billion worth of projects3 showed “46% of the systems so egregiously did not meet with real needs (although they met the specifications) that they were never successfully used, and another 20% required extensive rework.4” These studies, and many others, show that the traditional way software is developed is broken. In fact, the first formal description of the waterfall model is often attributed to Winston Royce. Royce presented this model “as an example of a flawed, non-working model.5” One other real example: “Salesforce.com delivered 568% more value in the first year of being agile.6”

The data is compelling that agile produces more value for less cost than alternative methods. It does require a change in thinking, which if not made will lead to getting less than desirable results.

Figure 1: Agile Development Value Proposition

Agile Key Terms

User Stories — What you want your software product to do is defined in user stories. These are written from the user’s point of view, describing what the user wants to accomplish.

Acceptance Criteria — Each user story has one or more acceptance criteria, or specific criteria that must be passed for that story to be considered done. For example, on a login screen, the acceptance criteria would likely talk about how the password is verified, the requirements for the username, perhaps that there should be a particular way for the user to retrieve a forgotten password, how authentication needs to happen, etc. The idea is that if an acceptance criteria is not met, example being the username requirements are not defined within the login screen, then the story is not complete.

Backlog — The backlog comprises all the potential user stories you may want to complete that provide value to users. The backlog is also prioritized by value. The Product Backlog contains all user stories for the “product,” whereas the Sprint Backlog contains the user stories for the particular sprint in process.

Sprint — a sprint is a set period of time in which work is done. In a sprint, the amount of the backlog that can be accomplished is moved from the product backlog to the sprint backlog, and each of those pieces of work is fully developed and tested until they are all done. This is vital: At the end of each sprint, the work is done.

Definition of Done — At the end of each sprint, the work in that sprint is done. To achieve this, we need a common definition of done. This is generally different for different products as well as different teams, but includes testing on all relevant browsers/phones and meeting all acceptance criteria. Product-specific definitions of done include things like creating user documentation, developer documentation and updating automated test scripts.

Sources:

1“Reported Benefits of Agile Development,” Mountain Goat Software LLC, slide 5
2“Reported Benefits of Agile Development,” Mountain Goat Software LLC, slide 10
3"http://www.versionone.com/Agile101/Agile-Software-Development-Benefits/"
4"http://www.versionone.com/Agile101/Agile-Software-Development-Benefits/"
5"http://en.wikipedia.org/wiki/Waterfall_model"
6“Reported Benefits of Agile Development,” Mountain Goat Software LLC, slide 12"