4 Warning Signs that Your Team’s Agile Process Stinks

Key Takeaways

• Agile implementation requires more than just adopting rituals and roles, it should embody the philosophy of agile to bring real value. Misuse of agile can obscure real problems in the organization.
• Four warning signs, or “process smells”, that an agile process isn’t working effectively include: the phrase “Can’t we just…” indicating scope creep; the phrase “Historically that hasn’t worked here” indicating resistance to change; the phrase “It’s a one-line fix” indicating underestimated work; and the phrase “We need to hire more ninja rock-star engineers” indicating a hero culture, which can be detrimental to team cohesion and sustainable work environment.
• When these warning signs appear, it’s crucial to address them by reminding the team of the value of agile, encouraging them to try new methods, treating changes as independent stories to be scheduled properly, and promoting a team effort where everyone shares both credit and responsibility.
• Everyone in the organization, not just the scrum master, should be vigilant for these warning signs, as they could indicate a broken and chaotic process hidden beneath the surface of agile terminology.

Getting used to doing things in an agile way can be challenging for everyone in an organization, from senior management all the way to the core team engineer.

But applying agile is more than a matter of blindly following the rituals, filling out the artifacts and labeling people with the roles.

An agile organization needs to embody the philosophy of agile in order to get real value out of the process. Otherwise, agile can become a stand-in for whatever buzzword management technique happens to be popular, and will only serve to obscure any real problems that may exist.

In order to recognize potential agile process issues and address them, it’s helpful to have a set of signals to watch for.

Here are four such signals I’ve noticed–I call them “process smells.”

Recognizing Process Smells

As an engineer who has worked on development teams for many years, one of my favorite metaphors for noticing something suspicious about the way a project is being done is the “code smell.”

Code smells are recognizable patterns of behavior that are reflected in the code a team produces, and they usually mean trouble.

In Javascript, a code smell might be abuse of global variables declared without the var keyword. In HTML, a common code smell is overuse of the div element when there are semantic elements that could support the same content more appropriately. One code smell that’s very common is a codebase with no automated tests, or with tests that validate basic language features but ignore critical business logic.

Code smells often indicate a development team that isn’t paying attention to the quality of its work. Frequently they are a sign that the coders were being pushed too fast to accomodate a single use case by an unreasonable deadline. In this case, the team lacks incentive to consider the implications for maintainability, readability or scalability.

When an engineer tells you your code smells, that often means there’s a deep underlying problem that needs to be addressed before practical changes can be attempted.

An agile workflow generally operates in a coding environment, but agile itself is communicated in the language people use to share ideas and track progress. Over the years I’ve noticed several patterns of conversation that I consider process smells.

These are phrases or attitudes that come up while people are talking that indicate an organization may be using the terminology of agile while continuing old practices that undermine their efforts to use agile effectively.

Here are some of the cues I tune in to when I’m sniffing around for process smells in organizations that are trying to adopt agile practices. I’ll also illustrate how I draw attention to them so they can be acknowledged and handled.

1. “Can’t we just…”

One of the phrases that people start using when they’re testing the boundaries of agile is some variation on “can’t we just…”

This may come up when a product owner is trying to squeeze in an extra feature into a backlog that’s already been defined. It may be a critical feature. It may not be the project owner’s fault that nobody noticed that it was missing until the backlog had been finalized. The stories in the backlog may not even make sense without it.

But “can’t we just” opens the door to scope creep. Part of what makes agile methodologies work is that the team has the opportunity to recognize and commit to the entire scope of the work they’re going to be completing in a given sprint before the sprint begins. Once that scope has been defined, the team knows from top to bottom what they have to work on.

Engineers on an agile team can trust that they won’t be buffeted by changing expectations and requirements, at least for as long as the sprint lasts. That security gives them the opportunity to work efficiently and with focus.

When you hear people on the team say “can’t we just,” remind them that they agreed to follow an agile process because they recognized the value it would offer over whatever they were doing before. Point out the advantages of maintaining the trust of the team and allowing them to focus on the stories they committed to.

Then ask them, “Can’t we just save that until the next sprint?”

2. “Historically that hasn’t worked here.”

When adopting an agile process, there’s generally a pre-existing pattern of getting things done that agile is replacing.

Perhaps certain engineers “own” certain features, and people around the company are used to coming to them directly when there are issues. Maybe product owners have been used to working side-by-side with engineers to define features as they were being built, instead of creating clear user stories.

But an organization wouldn’t be considering adopting agile if the way of doing things in the past had been working. Although these behaviors may be deeply ingrained, it’s up to team and the scrum master to help coach people, both inside and outside the team, about the agile way of doing things.

Objections based on history can come from people on the team who are uncomfortable trying to explain how the agile process is different to customers, senior management or clients. These objections can also come from people on the team who have relied on the old patterns and habits to develop ways of protecting their career paths and preferred work processes, even if these patterns were destructive to the team as a whole.

The best way to handle this objection is to be prepared with reasonable responses that address the concerns. Point out that the team is trying something different, and that agile is an iterative process. It’s always possible to try something for one sprint, and then discuss it at the retrospective if it turns out it isn’t working. Remind people that things weren’t working well before, and agile has straightforward answers to some of these seemingly entrenched issues.

3. “It’s a one-line fix.”

Scope creep comes in many forms. One of the most common is the assumption (often by someone who doesn’t know how the code works) that a specific change in the acceptance criteria for a story already in the sprint backlog will have little impact on the level of effort.

But the misconception here is that the size of the feature request somehow makes it safe to introduce this change after a sprint backlog has been established and agreed to.

This challenge can come from both product owners and engineers. Frequently an engineer will come across a part of the code that they’re working on and recognize that something unrelated to the story appears to be a quick fix.

There are several problems with this. First, making this change means the team will be doing work that isn’t going to be reflected accurately in its velocity. It risks changing the functionality of the product in a way that isn’t tracked in the stories. In addition, apparent one-line fixes can sometimes have deeper implications, leading engineers down a rabbit hole and taking more focus away from the objectives of the sprint.

Whether or not the impact of the work being proposed in the middle of a sprint is actually minimal doesn’t really matter. The point is that the acceptance criteria for the story are being changed after the story was estimated. No matter how small the issue is, when an unrelated change comes up it should be mentioned to the product owner and treated as an independent story to be added to the icebox until it can be scheduled and estimated properly.

The overhead that comes from having this much ceremony for something that may appear trivial on the surface is a worthwhile investment in keeping the agile process clean and trustworthy for everyone involved.

4. “We need to hire more ninja rock-star engineers.”

Hero culture is at the core of many problems in engineering organizations.

Often the organization will have spent years celebrating key engineers who worked late into the night and over the weekend to solve complex problems. The reward structure for a company is sometimes built around how obvious the effort was in overcoming a difficult challenge, not the business value or support for the rest of the team. The hero who took on the herculean task and and came up with a workable solution may be given raises, prizes and applause at company meetings.

The problem with hero culture is that it does not create a sustainable work environment in which everyone is encouraged to contribute and share ownership of the code across the entire team. When an organization focuses on it’s hero engineers, the rest of the team may become starved for attention and resources, creating more resentment than motivation.

Hero engineers may work on special projects that they consider interesting, but their time and energy is being pulled away from the team’s efforts. They may be ignoring the direction being charted by the product owners, or they may be working together with product owners to develop solutions outside of the agile process everyone else is following. Either way, this approach undermines the trust and cohesiveness of the team, and it creates an artificial impression of the team’s true velocity.

Furthermore, code developed by mavericks working outside of shared office hours and fueled by caffeine and other stimulants, is almost certainly not the kind you want to brag about to your customers.

If you were betting your company’s future on a product, would you trust an organization whose recruiting literature focused on rock stars and ninjas? Personally, I would want to get my products from a company that stands behind its code and demonstrates that by giving its engineers what they need to get the job done correctly.

An agile process promotes team effort in which everyone works together and shares both credit and responsibility for the entire product. Code developed in isolation will always bear the signature of the individual who wrote it. Reliance on rock stars and ninjas may put your company’s product development efforts at the mercy of code that is idiosyncratic and difficult for other people to step into and modify if that particular engineer happens to win the lottery one day and quit.

Sniff Around For Process Smells

Although the scrum master is tasked with keeping the agile process moving forward smoothly, everyone in the organization should pay attention.

Even in companies that have invested time and money into training and materials, the local flavor of agile may just be a thin veil hiding a broken and chaotic process.

Listening to the way people talk about the work they’re doing can reveal hidden patterns that need to be exposed and addressed.

Frequently Asked Questions (FAQs) about Agile Process