Charlotte Fouque
In Agile development, a stakeholder is anyone outside the development team with a stake in the success of the project. If you are a stakeholder, knowledge of Agile will help you understand how the project will be developed and managed, when you can expect to see progress, and what the team needs from you in order to deliver their best work. Understanding these basic concepts and what your role entails are essential to your project’s success.
What is Agile (and why should you care)?
Agile was invented as a set of values and principles to guide software development teams in adapting to change and acknowledging unknowns. In development, an enormous amount of time and energy can be spent on managing change: changing expectations, changing market landscapes, changing requirements, and changing knowledge of the work.
Since change is a constant, it makes sense to build a process that takes it into account as expected. Agile is an iterative, incremental approach to software development and delivery that allows for uncertainty and change.
There are many methodologies, practices, and processes that fall under the “Agile umbrella.” For example, you might have heard of Scrum, Kanban, user stories, or sprints. These may or may not be used by the development team you work with. You should feel free to ask about them if you are curious about the team’s internal workings, but none of them are necessary to understanding the gist of what Agile is and how it works.
Why Agile?
Agile was introduced as a reaction to “waterfall” development, where work is done in long, consecutive phases of requirements gathering, analysis, design, coding, and testing, which can each last weeks or months. While there is nothing inherently wrong with this approach, it does present significant challenges.
Time to market
If you want to launch your software in a competitive market, you may need to assess whether spending years on development before being able to release anything will be viable for your business. During that timeline, it’s possible that you will be outrun by your competition, or that the market will change in such a way that your product will no longer be cutting edge, or even relevant at all. Technology changes quickly, and so do consumers’ needs and expectations — you will need to be able to keep up.
Running out of time
Imagine that your waterfall project deadline is fast approaching. It’s likely that development is either in the coding or testing phase. If the work is running behind schedule and that deadline can’t be pushed out for business or budget reasons, either scope will have to be cut during the coding phase, or the development team will have to burn budget in scrambling to get the initial scope implemented in time.
The testing phase might also be cut short, leaving little time to test the software, identify and fix defects. All aspects of the project suffer in this case and it is likely to result in a low-quality product that will not meet your customers’ needs.
Measuring progress
In waterfall, working software isn’t produced until the coding phase has completed (relatively late in the overall development schedule). This makes it difficult to measure progress and know if the project is on schedule, or how close it is to completion. You could be more than halfway through your timeline and have nothing more to show for the time and money spent than documentation of requirements and designs. If the project runs out of budget at this point, there is no part of the software that is usable and your investment is wasted.
Increasing risk
In traditional development, risk only increases as the project progresses because the work cannot be validated, from a technical and from a business standpoint, until the last phase of development. If any major problems are uncovered in the testing phase (such as issues with the basic architecture of the app), it will require significant rework.
The rework might entail going back to the beginning phases and revising requirements and designs, then refactoring code. This will have a major impact on the project budget.
Change requests
The waterfall approach to software development does not support responding to change quickly or efficiently. If any changes to the requirements are brought up during the requirement gathering phase, they can probably be incorporated fairly smoothly. However, the farther along the project is, the more complex and time-consuming it will be to make any changes.
Waterfall relies heavily on rigid requirements because they have to be handed off to a design team, who will then pass the designs to the coding team, who will then hand off software to a testing team. Any need for changes to the end product requires a change request going through each team in turn, which will take more time the farther along the project is.
All of this does not mean that development can’t be done in this way. Waterfall has become somewhat of a dirty word in development, but this is not necessarily warranted. Some types of development work are fine done in long, consecutive phases with delivery at the very end, if there is no uncertainty about the work and if the capacity and capability of the development team(s) is a stable, known quantity. However, these ideal circumstances are rather rare. This is where Agile can help.
Agile in Practice
Since the concepts of Agile are generally abstract, it can be a struggle for anyone unfamiliar with this approach to understand how it works and why it matters. As a client, you might begin to ask yourself why any of this is relevant to you; if this is the way that development teams need to work, then great — they should do that! But your role and participation as a stakeholder are vital to the success of this approach.
This section provides an overview of how Agile development works in practice and what you can expect, as well as what the team will expect of you:
Step 1: Break it down
When development is cleared to begin (generally after some initial discovery work), the first step for the development team will be to break down the work into small chunks. While there will still be many unknowns at this point, this is a good place to begin.
Once the team has enough information to get started, they will generate a list called the “product backlog.” Each item in this backlog will represent some small piece of functionality for the product, such as a user’s ability to perform a specific action (e.g., logging in). These small pieces are what will allow the team to implement features in an incremental, iterative way.
For you as stakeholder, this step can include participating in a discovery workshop; story mapping activities; and discussing project vision, goals, and strategy. The purpose of this early collaboration is to reach a shared understanding of what the team will be building and why. They will have questions for you about initial scope, specific features, content strategy, and more. Alignment between you and the team at this stage is what will start the project off on the right foot.
Step 2: Estimate everything
Once the backlog for a new project has been created, the developers will estimate each backlog item. This step is somewhat optional depending on the nature of the project and on the team’s established processes. The estimates will help them (and you) understand how much work each item will be to implement relative to the other items in the product backlog. Most Agile teams use a point system to do this.
As stakeholder, you may have visibility into those estimates, which will help you give input on prioritization decisions throughout the project. It’s also important to remember that estimates are just that — estimates. They will be imprecise (and sometimes inaccurate), but they will be updated and refined as the team progresses through the work and accumulates knowledge.
Step 3: Prioritize, prioritize, prioritize
The product backlog isn’t ready to be worked on until it has been prioritized. Prioritization will be based on multiple components, including business value, estimates of effort, and various risk factors. It’s important to note that the reason the backlog is one unified list is that the priorities will be ordered from top to bottom: each item in the backlog is a higher priority than the one directly below it. This means that no two items can be the exact same priority, purposefully forcing some tough decisions.
The team’s product owner (PO) is responsible for maintaining the backlog, ensuring that it is clear and accurate. The PO will need your help, however, to understand the details and value of the backlog items. He or she is likely to ask for your input on high-level feature priorities and will ensure that the backlog is prioritized correctly to make the most use of development time.
Step 4: Start building
Once the product backlog is prioritized, the developers can begin implementation. They will pull items from the top of the backlog only. The most important work is always done first, saving less important work for later in the likely event that the team does not get through the entire backlog before time or budget runs out.
When the team selects a backlog item to work on, it will go through multiple phases in quick succession, such as analysis, design, coding, testing, and validation. While this sounds very much like the waterfall phases outlined above, the difference is that each backlog item moves through these phases individually and relatively quickly thanks to their small size.
As stakeholder, you will be kept up to date about what the team is working on and when you can expect to see new functionality.
A note about sprints
You may hear the development team refer to sprints, or say that they work in sprints. A sprint, or an iteration, is a timebox in which the team completes a set of backlog items. Not all Agile teams work in sprints and sprint length varies depending on the team, between one and four weeks.
At the beginning of a sprint, the team identifies high priority work from the backlog that they can complete in that timeframe and commits to getting it done. Once the sprint has started, it’s important for current priorities to remain stable, meaning that the work pulled into the sprint can’t be switched out for other work.
This allows the development team to focus on finishing a set of backlog items without interruptions or distractions, also limiting work in progress for efficiency. The backlog priorities can still be updated at any time, until the beginning of the next sprint.
Step 5: Review and feedback
Once the team has completed an item or a set of items from the product backlog, the work will be presented to the stakeholders for review. This is usually a live demo, but can also be just a notification that new functionality is available for you to look at yourself. You can expect that, unless noted otherwise, the completed work is fully tested and functional.
If the stakeholders are happy with the work, great! The team will move on to the next items on the backlog. Otherwise, any requested changes are entered into the backlog as new items and prioritized along with everything else left to do.
Reviewing completed work and providing feedback is your most important responsibility as a stakeholder. The team needs to know if they have built the right thing, whether it matches your expectations, and confirmation that they are heading in the right direction.
The team also needs your negative feedback. It’s always nice to hear what you like about what they have built, but it’s important for them to hear what you are unhappy with in order to course-correct and improve. (Check out this post for some of the techniques we use to gather your feedback.) Early and regular feedback is crucial to the Agile approach.
Evolving the backlog
The backlog changes constantly. Items are added, deleted, rewritten, re-estimated, and reprioritized. The backlog is a living artifact that is updated as work is completed, feedback is gathered, new information is acquired, new knowledge is gained, and new ideas are generated. It becomes a sort of wish list, rather than a set of rigid requirements.
As stakeholders, you can always request that new items be added to the backlog. Be prepared to answer questions about how important those new items are to you in comparison to the others. Remember that adding something to the backlog means bumping something else down in priority.
Step 6: Adaptive Planning
In order to predict when the project will be ready for a release or another milestone, the product owner will create a plan based on the pace of development and how much remains in the backlog. The product owner will use this plan to forecast either a date by which a determined scope (set of backlog items) can be completed or how much scope can be completed before a determined date.
If the forecast shows that the desired scope can be completed for the desired date, then no changes are required. If things change along the way, the plan is updated to reflect the changes, either by decreasing scope or pushing out the date.
Although you will have visibility into the plan early, it’s important to remember that it will inevitably change. Some flexibility in scope or time is absolutely necessary for any development team to deliver high-quality work.
The Bottom Line
The point of Agile is to start by building something small and simple, validating early and often that it’s the right thing or heading in the right direction, and then iterating by improving on it or adding more to it. This is in opposition to more traditional approaches in that you as stakeholder don’t have to wait until the end of a project to see the work. You are part of the process; you have visibility into real, measurable progress. You can change your mind as you also learn about your product and its users along the way. By playing an active role in the process, you can help ensure your product's success.
