Risk is analyzed in Agile projects under the context of “potential threats to reaching a successful conclusion.
**”Sounds like a fancy way of saying: “When will this project fail?” **
But there's something you should know, something that many Agile practitioners fail to understand (until they hit some tricky project situations, at least): not all risks and potential problems are equal.
The upcoming list of risks may seem small and simple to you, but you'd be surprised to see how many teams overlook even these kinds of seemingly unimportant risks.
Stakeholders who want all the requirements up front
Your stakeholders have a long list of project requirements. They want you to meet all of them. This is an unrealistic expectation for agile teams, especially ones who don't have a lot of experience building software.
You've been working on a new project for a while, and your stakeholders have a long list of requirements. They want you to meet all of them, but this is an unrealistic expectation for agile teams, especially ones who don't have a lot of experience building software.
The problem is that stakeholders often don't understand how iterative development works. They expect to see all the requirements up front, but then they get frustrated when they don't see anything after weeks have gone by.
Iterative development means that we release something that's 80% ready and then iterate on it based on feedback from users or other stakeholders. This means that we're always building something, even if it's not perfect yet. If you wait until everything is perfect before releasing it, you'll probably never get anything out there at all!
Timeboxing
It's easy to see why timeboxing is so appealing.
It creates urgency and focus, and can help teams avoid falling into the trap of overthinking the solution or doing unnecessary things.
The problem comes when you let those timeboxes become too rigid—for example, if you are holding a team member accountable for a certain number of features or user stories delivered in a sprint, then they will have an incentive to deliver something, even if it isn't very polished or complete.
When that happens, you risk introducing scope creep (the tendency to add more features than originally planned), as well as creating product defects that can come back to haunt your product further down the road.
To counter this risk, we recommend using timeboxes as guardrails rather than hard deadlines. This may mean letting some sprints slip by without delivering anything, but that's OK—what's most important is giving everyone on your team enough space to breathe so they can do their best work.
Technical debt
In short, technical debt is the built-up work that needs to be completed before you can move forward with your product.
As an analogy: imagine traveling down a narrow road and coming across an object blocking your path.
To get around it, you veer off onto a dirt shoulder.
That’s fine for now, but eventually, you’ll have to circle back around and pick up that object or the shoulder will cave in under all the traffic.
That’s technical debt—you can go around it for a bit, but eventually you need to face it or risk getting stuck on that shoulder forever.
It’s important to recognize when your team has accrued technical debt so you can deal with it appropriately. Most teams are familiar with one form of technical debt: code smells (badly written code). These could take the form of anything from poor database design to inconsistent naming conventions.
Scope Creep
If scope creep were on LinkedIn, its list of skills would be so long that it would just give up and list “adaptability.”
There are lots of ways that scope creep can ruin your day, from the more common feature bloat to the less common but infinitely more dreadful late-night phone calls from upper management.
What is scope creep? It's an insidious beast with a thousand faces.
In general, it's when extra work and/or features are added to a project after you've started working on it.
The problem with scope creep is that it’s not always obvious whether something is creeping into your project or simply growing organically as part of the development process.
So how do you identify and address—or even prevent—scope creep?
What I personally like to do is pretend my product owner has never interacted with this project before. Once I have my product owner back in “new customer” mode, I ask them questions:
Is what we're doing right now what you thought you were signing up for? If not, is there anything we're doing right now that doesn't need to be done? Are there any new pieces of work that need to be done in order for us to get this thing out the door?
Lack of Buy-In
Project teams and the business users they serve can get so caught up in feature planning, story mapping, and Agile release planning that we forget about the "human stuff" of software development.
The business is just as interested in seeing things through to completion as software developers are, but sometimes lack of trust or communication can become a barrier.
This is especially true in organizations where the focus has been on delivering features over time (think waterfall) versus actual business objectives.
Here's how to avoid this risk:
Set expectations early with your project stakeholders. Make sure you know what the business wants to see out of this initiative and help them see how what you are working on will enable those outcomes.
If it doesn't enable business outcomes, you may need to reassess whether or not these features should be considered a priority right now.
Communication gap.
The two most obvious problems that can cause this risk are having a team member who does not communicate enough and a team member who spends far too much time communicating with only certain people.
Both of these problems may have the same result: work is not flowing through the entire team and everyone is unclear on what's happening.
Communication gaps between the team and the customer.
Agile teams work best when there is close contact with their customers or stakeholders, which makes it very important to close communication gaps here.
Sometimes, teams will ask questions like, "When exactly should we bring in our customer?" or "How many times should we check in with them?" or even "If they're not here right now, because they're sleeping or something, how do we get the answers to questions about their ice-cream sundae preferences?"
These are all great questions! However (you knew this was coming), there's no one answer that's going to be perfect for every situation. The best advice? Be flexible! Be adaptable! And don't forget about your product backlog grooming sessions where you can discuss these things with your teammates and customers so you understand each other better!
Confusing flow with throughput
The two terms are often used interchangeably, but they’re not the same thing.
Flow is the measure of how long it takes for a team to turn an idea into a finished product feature. It’s about the work being done, not about how much work is being done.
Throughput is the measure of how many units of work get through the entire development process from start to finish.
The more throughput you have, the larger your backlog should be and vice versa.
If you want to increase flow, you need to reduce throughput — but only slightly. If you want to increase throughput, you need to increase flow — but only slightly.
Not prioritizing bugs
You’re in a meeting with your team.
Everyone is focused on making sure the highest priority features are complete in time to meet the deadline.
As you’re reviewing your list of outstanding bugs, one of these shiny new features just won’t work as expected.
You know that fixing this bug is critical to ensuring a good user experience, but there are other bugs on the list that have lower priority. The temptation is to defer fixing the bug until after launch.
Don't do it! This thought process can be dangerous for several reasons:
Bugs affect not only user experience, but also security, reputation, morale and many other important factors
Fixing high-impact bugs early can prevent knock-on effects later because they're more likely to affect more parts of the system
Team Morale
To be fair, it's hard to estimate just how much of your team's morale you can directly influence.
Some people are naturally upbeat and others are prone to pessimism.
But as with most things in life, the results you get depend on what you put into it. Do you want a team full of energetic rock stars who look forward to Mondays? Or would you rather have a group that's listless and deflated? (The answer, of course, is that you want the former.)
Before we dive into more specific morale-boosting tactics for agile teams, let's quickly talk about why this stuff matters so much.
The importance of working on teams with high morale should be obvious—high performers are happier than their less-effective counterparts—but there are even greater consequences for low morale than just the quality of your output.
In fact, a lack of motivation can result in some pretty dire side effects:
**Longer work hours: **Team members will feel like they have to work even harder if they aren't feeling validated or appreciated by management or peers.
**Workplace gossip: **When employees feel ignored or mistreated by leadership, they start talking behind one another's backs instead of working together constructively toward a shared goal or vision.
**Higher turnover: **Almost half of employees said they've left jobs because their supervisor couldn't provide them with meaningful feedback and an opportunity for growth within the company—and that kind of thing can lead to resentment which ultimately lowers employee morale overall.
On a final note..
As we wrap-up this article, the next time you are presenting about a project, ask yourself – Are all the risks covered? Are there unobvious ones lurking on the periphery that could have devastating effects on our organization?
If you can find them and mitigate them, be assured that it will help save your product. And while they might not always be pretty and they can sometimes break things, finding issues early is better, so get out there, try to think like an attacker, and find those risks!