Maximizing the Value of Your Agile Transformation – Recognizing Agile Antipatterns

In my previous blog post, I wrote about the business value of Agile, and how it benefits different areas within a typical organization. With that context in mind, let’s look at some myths and antipatterns about Agile, and ways to recover from these. These antipatterns reduce the type of value I described in my previous entry, so they are worth calling out. Sometimes, when artifacts of Agile are misunderstood, they can cause more harm than good, and execution of these antipatterns are usually the underlying reasons why some people believe that Agile “doesn’t work.”

Overloading Terms

Where I see antipatterns do the most damage to the ability of the team to focus on value and continuous improvement, are when Agile terms get misconstrued, overloaded, or even abused. The two terms that I have seen most often coopted are “servant leader” and “self-organization.” These terms are particularly dangerous, because they can be weaponized for personal gain or to avoid having to do certain elements of a job that one might find undesirable. This can have a devastating effect on the quality of the team’s work, as well as the direction of the product. Let me explain.

Self-organization. This is a term that is used frequently in the Agile community, and is meant to imply that the team should determine for themselves how they will go about building their product, and what sort of working agreements they will abide by as they do so. This does not mean that the team needs to also be responsible for product strategy, user adoption, and generating functional requirements. An example of this term being misconstrued comes from a project I was working on, where the Product Owner, in response to the development team asking for detailed use cases of a feature, replied with “Just…self-organize around it! I’m sure what you come up with will be good.” In this case, the Product Owner abdicated the responsibility of defining the direction of the product by overloading the term “self-organization.” Whether this individual was motivated by a lack of understanding or a lack of desire is irrelevant; the outcome is the same. The team was left to guess at what the business wanted, and hope that the product they built would be sufficient, or even correct. I have also seen leaders misuse this term when they do not have a broad understanding of the strategy in an organization, or when there is a desire to avoid accountability for the execution of that strategy.

In order to fix the underlying problem, if it is in response to strategic questions, it may be beneficial to assemble stakeholders, sponsor, and team to align on the Product Vision, and perhaps conduct some high-level backlog refinement with Epics or Features. It may also be wise to have a session to define what the different roles in the project are accountable for, so that there is an understanding of what, exactly, the people in the project need to “self-organize” around.

Servant Leader. This term is also often overloaded in the Agile community, and has been used to the point of becoming a buzzword. The danger of this term is that some people will take advantage of the term to imply that the “servant leader” is the notetaker for every meeting, fills out all access request tickets for the team, or even gets coffee. While the servant leader may do these activities from time to time, the role of a servant leader is not to be the dumping ground for all the work that the team does not want to do. A servant leader is someone who acts on behalf of the greater good of a team, and ensures that everyone whom the leader affects is growing and evolving in their role. Sometimes a servant leader will need to have tough conversations with members on the team to get them to see their blind spots and grow. Other times, a servant leader will need to rise to the defense of the team by having direct conversations with people outside the team, and even escalate within an organization’s management structure to protect the team from being randomized or subverted. This term does not imply meekness at all; rather, it implies a shift in priority from issuing commands, to developing individuals, and acting for the greater good of the team.

Misunderstanding What Agile Is Designed to Do

Over the course of my career, I have encountered several individuals who believe that Agile has failed to deliver on its promises. More often than not, this is because there is a misunderstanding of what, exactly, those promises are. These are not antipatterns per se, but more a misalignment of expectations. Let’s look at some common myths about what Agile is designed for, based on quotes I have heard working with teams and stakeholders

Agile doesn’t work; I’m following all the practices, and we’re still not predictable, the team still gets interrupted, and (redacted name) is still causing problems!

This quote is based on an assumption that Agile will fix all the issues in a team just by following the guidance in the Scrum Guide (or Kanban books) and the Agile Manifesto. This is also, unfortunately, a misconception that some Agile consulting agencies will try to sell clients on as well, so when the client understandably becomes disillusioned, the Agile mindset and associated frameworks get blamed. The truth is, that Agile will not, in fact, solve all the problems the team or organization is dealing with; Agile is designed to make these problems visible, and enforce accountability. If a team is unpredictable, Agile frameworks provide tools for determining the cause of the unpredictability, and where in the process those causes occur; the Agile mindset then guides the team to be courageous in calling it out, and tackling the problem versus assigning blame. Agile will not actually fix the problem though… the team, organization, and/or management structure must do the hard work to remediate the issues that are causing the inconsistencies, have those tough conversations, and practice discipline in the process.

Agile is only for software development. It won’t work for (redacted).

This misconception is widespread, largely due to the fact that many of these terms were given names by software developers, such as the signatories of the Agile Manifesto. In fact, there is one line in the Agile Manifesto that I do not agree with: “Working software over comprehensive documentation.” If anything, it should be “Working product or successful outcomes over comprehensive documentation.” Here are some examples of non-software Agile development:

• Digital Marketing. I worked with a team in a previous organization that pushed marketing campaigns for the business. These individuals would release items to a website, but most of their work did not have to do with software development. This team successfully used Scrum to manage the tools used to push the campaigns, while using Kanban to handle incoming requests from marketers. Though this team had to write some scripts and administer tools, they were not a traditional software development team.
• Training departments. Before I got into the business of Agile Coaching, I was a trainer for a customer service organization. There was absolutely zero coding done, but we used Scrum to manage the creation of training materials, and Kanban to queue up training requests.
• Manufacturing. Long before the term “Agile” was ever used in this context, the Toyota company created the Kanban system for their manufacturing plants; this system is now a prominent Agile/Lean framework, and helps manufacturing companies maximize value, throughput, and cost-effectiveness to this day.
• Nursing. There is a concept in nursing called “shared governance” that is gaining traction. This concept involves self-managed work teams that coordinate around daily huddles to track the work, and more closely align that work with the values of the profession, while keeping the focus on the best outcomes for the patient. Source: OJIN. Sound familiar? They don’t call this “Agile,” but it most definitely is.
• My own yardwork. Yes, I am a procrastinator. Yes, I look at my massively overgrown laurel hedge and think, “There is absolutely no way. I am going to play video games instead.” To help myself get out of my own way, I break down tasks into manageable chunks of work to avoid getting overwhelmed, and have everything listed on a personal Kanban board as prioritized by my Product Owner, aka my wife.

The bottom line is this: if you produce something, create a successful outcome, or otherwise add value to an organization or to yourself, you can do, and be, Agile.

The Danger of Obsessing on Metrics

To invoke an old cliché, metrics can be a double-edged sword. They are useful and necessary tools for continuous improvement, but they can also be quite dangerous if misused. Most Agile antipatterns I have seen among teams and organizations spawn from the misuse of metrics.
There is a quote that I particularly like from A. Donald Stratton, the author of An approach to quality improvement that works: “Some say you only get what you measure. I say that’s all you get.” This quote perfectly encapsulates the tendency for teams, individuals, and organizations to change behaviors to make the metric look better, versus the outcome that the metric is measuring. This can take many forms, but I see this most often occur with story points. This antipattern will usually start with a comment or an expectation such as “Why can’t you do more points in your sprint?” Or even worse: “This other team is able to do 450 story points per sprint…why can’t you?” On the surface, there are three antipatterns that manifest from this mindset:

1. An assumption that Agile teams should get faster every sprint; at some point there is a speed limit that a team will get to before they break their sustainable pace. The goal is predictability, not speed.
2. A tacit competition between teams with a zero-sum game, using a metric that is subjective to each team. Good luck getting those two teams to collaborate on anything in the future.
3. A desperation to make excuses or blame others if the metric in question is not looking completely healthy, as the reasons are likely beyond any one person’s control.

In response to this implied direction, teams and individuals will perform mental gymnastics to show that the metrics look good; they will inflate story points, attempt to equate story points with hours, deliver RAG statuses that are always green regardless of reality, insist that defects are actually “features,” and so on. What often gets overlooked, is a mindset that begins to take shape as these antipatterns are executed: valuing the metric over the outcome. The metrics themselves are not important; the questions the metrics are designed to answer are. Questions such as:

• What exactly happened to lead us to this point?
• Can we perform this feat again sustainably?
• Are we in trouble?
• Can we identify small problems early before they become big problems?
• How can we plan for the delivery of thought work, where the outcomes are uncertain?

When we prioritize making the metrics look good, we forget to keep these questions in focus, and we lose sight of the true value of measurement. After all, if I go to buy a car, I’m going to look for a car that has good gas mileage, has 4-wheel drive, and is a comfortable ride; I’m not looking for 450 story points worth of car.

Remediating Antipatterns

So once we find these antipatterns, and can identify them reliably, how do we proceed? This is where the art of Agile Coaching comes into play. It is sometimes tempting to feed our egos and approach the situation from a position of superiority by claiming that the person, team, or organization is “doing it wrong,” and that the “right way” is some process that you are an expert on, have a certification in, or have read about. All this behavior will likely do is to cause people to dig in their heels and resist. Remember, change is hard. Even if that change will cause individuals to feel less pain, be more successful, and become more fulfilled, it is still change, and that requires people to alter the way they think. Also, remember that antipatterns that are entrenched in an organization likely took a while to take root, so undoing those old patterns is going to take just as much effort to extract.