Why (some) agile teams fail

A simple explanation of why an agile team might fail.
Register or Login to like
team meeting

WOCinTech Chat. Modified by Opensource.com. CC BY-SA 4.0

White cat

Over the past year, I have had many conversations with people that always seem to revolve around two questions (much to my dismay and resulting squinty-eyed look):

  • Where are you going with agile at your company?
  • What kind of standardization (and/or framework) do you provide for the company?

Before I answer those questions, let's start with a story. When I was first practicing agile in 2006, I was asked to document our scrum process so the team would best understand how it worked for projects that had an end or "release" before we moved onto the next project. We came up with a visual that looked like this:

Agile scrum process chart

Looking back on this experience, it made perfect sense for me to standardize the process. We were a small team, and the documentation we produced was what worked for the team at the time we created it. Twelve years later, my perspective has changed, and I view documents like this as ambivalent or chaotic neutral at best. At worst, they are often used as the holy grail to solving team problems. The danger is always in how the information is used.

"Look over here – this team seems to be doing well, we should just copy what they are doing!"

Teams are different because they are made up of different people with different situations. Certain practices can be easily shared across teams, but in my experience, trying to standardize processes doesn't actually work and adds unnecessary overhead on teams. To make matters worse, the introduction of certifications in the industry has over-emphasized the idea that implementation of agile is the only thing that matters, rather than the idea that teams experiment and learn together what works for them. This is the same danger we face with capturing metrics on teams and using them without understanding their intent and purpose.

"This team over here can do 60 story points a sprint, but this team over here is only doing 40. Clearly, there is a problem."

Yes, there is a problem, but it may actually be "jumping to conclusions." Comparing what one team can do vs. another is a shorthand management approach to agile at its worst. It's a symptom of both a lack of understanding of the intent behind self-organization and continuous team improvement and also an indicator that the industry of agile has spent a lot of time focused on the performance of small engineering teams. The hard work of addressing how the rest of the organization gets work done remains largely unfinished.

So, when faced with the question: What kind of standardization (and/or framework) do you provide for the company? My opinion has always been first and foremost based on this statement:

Do not do what works for another team. Do what is right for your team.

Cat sitting on a router

And the harder question: Where are you going with agile at your company? My answer is a little squirrely, but it is an honest one. We go nowhere together if we don't stay true to the foundational truth of what agile was asking us to focus on in 2001: building trust and transparency in teams so they can work together to accelerate their learning in a safe and open environment. We go nowhere together if we look to push process onto others without striving first to understand why and what is needed.

One might think after seeing the above picture, "Get that cat off the router before it overheats," without first asking, "Why the cat is sitting there?" I can attack the problem by removing the cat, or instead, I can eliminate the problem by providing the cat with a heated bed in the winter so the arthritis in his back legs doesn't feel quite as bad when it is cold.

3 guide rails for teams

Cat in a laundry basket

I'm sure you are thinking at this point, "OK, Jen, that's not really solving the reason we asked the question in the first place." Many people I talk with about the subject of agile often feel trapped by the status quo, like this cat. I understand that—I have also felt that way. Sometimes, I still do. In an effort to help with this problem, I ask teams I work with to follow some guide rails, and I advocate others teams embrace these practices as well.

Track and share your work so others in your organization can understand what it is you are doing.

The key here isn't that you are tracking the work (although that's a bonus!), it is that others beyond you can understand why you are doing the work. If you can't communicate the customer value to someone who isn't involved in the details, do you really understand it yourself? Additionally, there is significant value in being able to empirically explain how you are going to measure the impact of the work you are completing. This follows the simple user story format of: As a customer, I need this piece of functionality, so that I can achieve this result. This is followed by: We know we will have delivered this result by these sets of qualitative vs. quantitative measurements.

There is truth in the phrase, "Begin with the end in mind."

Continuously work on improving your practice as an individual and team.

This includes the process in which your team and product get work done and what your job function is. If you are an engineer, learn something new about coding and practice it. If you are a project manager, try out a new facilitation technique you read about. Process doesn't only refer to how you move cards around in a tracking system. Make sure you are openly talking with your team about the things that aren't working—whether it is related to people process or technical process. Without that commitment, process and technology will become stale.

Perhaps the best we can do in this space is agree to standardize on routinely sharing with the whole organization how we are continuously working to improve and the metrics we use to demonstrate that.

Note: If you come to me and sheepishly confess that your team has stopped doing standups because the team doesn't see the value in spending the time, and the entire team is delivering measurable and clear value to your customers when it is needed, don't expect me to be upset. I am likely going to ask some questions, congratulate you, and send you on your way with encouragement to continue having good conversations about what works.

Two cats in a bed

Finally, if your work crosses team, community, or product boundaries, agree how that is going to happen before there is conflict.

I'm not talking about the details behind implementing a technology. I'm talking about defining everyone's roles in the work, defining where conversations will occur, and defining how requirements will pass back and forth from team to team—establishing as much harmony as possible before work starts and you find yourselves relying on each other to share space together—without a catfight erupting. As technology continues to innovate at a rapid pace, teams with heavy cross-functional dependencies will find that the problem will worsen. In my mind, it is the single biggest reason why projects fail. This is where standardization is most needed because, without standardization, it is hard to automate.

Do the right thing

White cat with owner

I want to close by re-emphasizing this statement: Do not do what works for another team. Do what is right for your team. Every failed agile adoption story I have heard in my career is built on top of the failure to follow that mantra. I encourage everyone to embrace that idea and seek help from your local agile experts when the team needs it.

Finally, when approached with a "you must do this because so-and-so is and it works for them…" look back on the guide rails I've defined above. Most teams are put into that position because they are perceived to not share why they are doing something, they do not continuously improve their process, nor do they ensure that dependency-riddled work is handled with minimal day-to-day conflict. My call to action for teams that are in that space is to think about why they are in that position, and what they should do to break free of that perception.

Most importantly to my fellow coworkers, technologists, and agilists: If you don't agree with what I am sharing, you can do what my cats do… or you can share what works for your team.

User profile image.
Jen Krieger is Chief Agile Architect at Red Hat. Most of her 20+ year career has been in software development representing many roles throughout the waterfall and agile lifecycles. At Red Hat, she led a department-wide DevOps movement focusing on CI/CD best practices. Most recently, she worked with with the Project Atomic & OpenShift teams.

4 Comments

Sometimes you need metrics just to avoid going after non-problems.
What is the evidence that a cat sitting on a router will cause it to overheat? Seems like the cat has solved its problem in an energy-efficient way.

It doesnt take a lot of effort to search on the internet to discover how common it is for routers to overheat when the vents are covered. In my own experience - the cat sitting on it absolutely would cause our older router to reset and cause service issues until we rebooted. ?‍♀️

In reply to by Greg Pittman

Excellent article Jen!
Here is another mantra I keep hearing "If Agile doesn't work for you, you are doing something wrong". This one is so untrue....

I have been in companies where they have a sprint plan set to be the same length regardless what project they working on.

I have seen user stories taken into a sprint without analyzing them with details such as defining the following::
1_ Data needed for the story for DB Schema
2_ Activities needed to reach user story goal
3_ Business rules that need to be applied
4_ Design session if needed
5_ Reusability analysis

If the above user story details are not practiced, then there is a high risk of failure.
And if we wait to find that detail in the middle of the Sprint, then there is another high risk of failure for not getting it done during this Sprint since developers will have to wait until the details are clear from ambiguity.

The Agile framework doesn't help the team on how to be agile performing Analysis and Design.
It's only a great framework for:
1_ Better communications
2_ Product demo
3_ Sprint Tasks planning
4_ Process Improvements

I would keep using your Mantra and add to it...
"DO WHAT IS RIGHT
FOR YOUR TEAM
FOR YOUR PROJECT
FOR YOUR PRODUCT BACKLOG ITEM"

SDLC Frameworks or Processes do not build software.
Following Software Engineering Best Practices for performing Analysis, Design, Coding and Testing, will help you build robust software and minimize your chances of failure in whatever SDLC framework you chose to follow.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.