What is Agile?
Traditionally, [software] project management followed a linear pattern termed “Waterfall” project management. This Waterfall project management style would be divided into several typical phases:
- Requirements — Determining an exhaustive list of requirements for the entire project.
- Design — Completing full design specifications for the software requirements.
- Development — Converting the designs into a working software product.
- Test — Comprehensive testing of the completed software product.
- Go Live — Delivery of the software product to the client.
The name “Waterfall” comes from the sequential nature of this project management style where water progressively falls downward from one phase to another, in one direction and in a way where each phase is handled by a separate team. This structure can work well for small projects, but tends to lead to inefficiencies and disconnects between the client and the product when used for more complex projects of the type common in software development today.
The first problem is that the requirements for the project are held as absolute, while the cost of the project and time to delivery are subservient to however long the requirements take to be fulfilled in completion by the project team. What’s more is that scope creep, where the requirements of the project expand beyond the initially agreed upon parameters, can overtake the project at any of the phases which leads to delays in delivery of the product to the client.
The second problem comes from the waterfall structure itself which leads to siloed sub-teams; the Design team is fully distinct from the Development team. This can cause a disconnect among the broader project team where the project team is made up of individual sub-teams and this can lead to frictions passing work between teams along the project. What’s more, because the phases are worked on for the entire project specs at once, large sub-teams are required which leads to difficulty maintaining appropriate utilization of employee time. Bottle necks along the project can cause entire sub-teams to be either over utilized or under utilized, leading to burn out or boredom.
The final main problem is that because the client only sees the final working product at the end, it can be difficult to incorporate timely client feedback into the project workflow. Combined with the long time to get a working product to the client, it may not be practical for the client to further wait for these additional items of feedback to make it back through the project workflow funnel.
The Agile philosophy aims to build a workflow for project management that solves these problems by making it easier to incorporate client feedback, easier to balance sub-team utilization, and to management scope creep, cost, and time.
The Agile Manifesto
Link: https://agilemanifesto.org
The Agile Philosophy is captured in the 4 items of the Agile Manifesto:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
These 4 philosophies are embodied in 12 Agile Principles, also found on the website. The principles which most directly encode the 4 philosophies are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- Business people and developers must work together daily throughout the project.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
The Agile Philosophy prioritizes flexibility and adaptation to changing needs of the customer and therefore does not lock the project into specific requirements. In other words, it embraces the ever present possibility of scope creep and instead embraces constraints on what can be delivered in a specific time and cost.
With this new paradigm for project management, the first redesign comes in the form of the project requirements. Since Cost and Schedule are meant to be fixed with some variability on the feature set that can be delivered from the project, having a exhaustive list of requirements at the start of the project that would be worked through from start to end is no longer viable. The first step toward adopting Agile project management is to make use of the Agile method of Requirements Gathering.
Agile Requirements Gathering
Requirements in agile are brown down into 4 levels, “High Level”, “Medium Level”, “Small”, and “Details”. These can be classified/relabeled as “Visioning”, “Brainstorming”, “Breakdown”, and “Deep Dive”.
The High Level is a general topic for the project: What is the theme we are working toward? The Medium Level identifies elements of what features are needed in order to accomplish the theme. The Small Level introduces Stories and Epics. These 3 levels are ones which should be identified at the start of a project, with room to adjust, add, or remove during the project life cycle.
Themes and Features are general high level ideas about the project while Stories and Epics require more explanation.
What are stories?
Stories are a way of stating bite-sized requirements of the project in ways that both developers and users can understand in plain English. They will typically be of the form “As a <role> I want <to be able to do something> so that <benefit>”. Here are two examples:
- As a student I want to purchase my monthly parking passes online so that I can save time.
- As a student I want to be able to pay for my parking passes via a credit card to avoid using cash.
Notice that there are potential elements of overlap between these two stories. We can accomplish the goal of the second student while simultaneously accomplishing the goal of the first student if we build a system which allows for online purchase of parking passes via a credit card. However, if the second student actually wants to pay using a credit card at the location on a per use basis then the solution for the first student would not work. The inclusion of the “benefit” clause in the story helps explain to the developer exactly what problem the task this story will generate is trying to solve and captures the mindset of the problem the user is trying to solve. This adds context to how the task of building an online portal for parking passes fits into the bigger theme of something like “Improve Transportation Operations”.
Stories do not always have to be in this form if it would be unnatural. Some stories may be simple statements of technical requirements like “Prune unused Git branches”, but even then it could be useful to restate this with some more context as “Prune unused Git branches so that it will be easier to coordinate sharing code”.
Here are some more examples of user stories.
What are epics?
An epic can be thought of as a very large user story. This large user story usually consists of smaller user stories which can be identified and extracted into bite sized user stories. Typically epics are useful for grouping together one bigger narrative of a user story to show how the smaller stories fit together. Consider the following epic:
As an electronic banking customer, I want to be able to easily make an online deposit of a check into my bank account through my IPhone® so that I can save the time required to send a check for deposit through the mail and I can have the money immediately credited to my checking account as soon as the deposit is completed electronically.
This epic breaks down into the following user stories:
- As an electronic banking customer, I want to be able to scan an image of the front and back of a check into the IPhone® so that it can be deposited electronically.
- As an electronic banking customer, I want to be able to enter the deposit information associated with an electronic deposit so that the correct amount will be deposited into the correct bank account when the electronic deposit is processed.
- As an electronic banking customer, I want to be able to electronically submit a scanned check and deposit information to the bank for deposit so that I can save the time associated with sending deposits by mail.
- As an electronic banking customer, I want to be able to receive confirmation of a completed electronic deposit so that I will know that the deposit was successfully processed.
The epic captures the story narrative of how a single role, an electronic banking customer, wants to interact with the portion of the banking system that role makes use of. It is then broken down into the bite sized user stories that the development team can tackle.
Below the Small Level are the Details or the “Deep Dive”. These are actionable items which are translated into tasks unique to executing on a specific user story. These are not filled at the Agile Requirements Gathering phase but rather “just-in-time” at the time a specific user story is ready to execute. This avoids getting bogged down in long detail gathering at the start of a project and instead spreads that process over the project life cycle at the time they are needed to begin developing for a user story.
Here is an example of what the Agile Requirements Gathering frameworks looks like in practice.
All these user stories need somewhere to go and they are place into the Product Backlog.
The Product Backlog
The Product Backlog is, in its simplest description, a to-do list of User Stories. The Agile Philosophy has guidelines on how to manage this Backlog. The backlog is organized first in terms of importance to having a functioning product and then in terms of dependencies which must come before those prioritized stories. In going through the product backlog stories must be developed into full details for execution periodically so that the backlog of active user stories for execution does not run dry. Here is a sample of what a product backlog might look like.
Notice how the stories are grouped together and the order of the groupings are selected so as to be able to deliver functional products in small chunks, e.g. a login page, a profile page, a product ordering flow.
As these stories get developed the details will be populated and then the various team members responsible for Design, Engineering, Testing, etc, will work on the tasks.
The specific ways that the Product Backlog is managed lead to different workflow methodologies like Scrum, Kanban, etc, all of which adopt the Agile Philosophy into codified methods for execution. Agile itself is a philosophy focused on the element of structuring teams and work, as well as how to structure the requirements of a project. Scrum is the most popular software development Agile methodology and has been developed with a number of best practices and workflow patterns.
Now that you know what the core building of Agile are, you can adopt them uniquely for your own team context, or explore other Agile methodologies you can adopt.
