4 Warning Signs that Your Team’s Agile Process Stinks

Share this article

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

What are the common signs that an Agile process is not working effectively?

There are several warning signs that an Agile process may not be functioning as it should. These include a lack of communication and collaboration among team members, a failure to deliver working software at the end of each sprint, a lack of customer satisfaction, and a failure to adapt to change. If these issues are not addressed, they can lead to project failure.

How can we improve communication in an Agile team?

Communication is key in any Agile team. Regular stand-up meetings, retrospectives, and planning sessions can help improve communication. Using tools like Slack or Microsoft Teams can also facilitate communication among team members. It’s also important to foster a culture of openness and transparency where team members feel comfortable sharing their thoughts and ideas.

What should we do if we’re not delivering working software at the end of each sprint?

If your team is not delivering working software at the end of each sprint, it may be a sign that your sprints are too long or that your team is taking on too much work. Consider shortening your sprints or reducing the amount of work in each sprint. It’s also important to ensure that your team understands the definition of “done” and that they have the necessary skills and resources to complete their tasks.

How can we ensure customer satisfaction in an Agile process?

Customer satisfaction is a key measure of success in an Agile process. Regular communication with the customer, including frequent demos and feedback sessions, can help ensure that the product meets the customer’s needs and expectations. It’s also important to prioritize the customer’s needs and to be willing to adapt to changes in their requirements.

How can we adapt to change in an Agile process?

Agile is all about adapting to change. Regular retrospectives can help your team identify areas for improvement and make necessary changes. It’s also important to foster a culture of continuous learning and improvement, where team members are encouraged to experiment and learn from their mistakes.

What are some common misconceptions about Agile?

Some common misconceptions about Agile include the idea that it’s a silver bullet solution to all project management problems, that it doesn’t require planning or documentation, or that it’s only suitable for software development. In reality, Agile is a flexible approach that can be adapted to a variety of projects and industries, but it requires careful planning and management to be effective.

How can we measure the success of an Agile process?

There are several ways to measure the success of an Agile process, including customer satisfaction, the delivery of working software, the ability to adapt to change, and the level of communication and collaboration among team members. It’s also important to consider the overall quality of the product and the satisfaction of the team members.

What are some common challenges in implementing an Agile process?

Some common challenges in implementing an Agile process include resistance to change, a lack of understanding or training in Agile principles, and difficulties in scaling Agile to larger projects or teams. It’s important to provide adequate training and support to team members and to be patient and persistent in overcoming these challenges.

How can we overcome resistance to change in implementing an Agile process?

Overcoming resistance to change can be challenging, but it’s crucial for the success of an Agile process. Communication is key: explain the benefits of Agile, involve team members in the decision-making process, and provide regular updates and feedback. It’s also important to provide adequate training and support, and to be patient and persistent.

How can we scale Agile to larger projects or teams?

Scaling Agile to larger projects or teams can be challenging, but there are several frameworks and methodologies that can help, such as Scrum of Scrums, Large-Scale Scrum (LeSS), and the Scaled Agile Framework (SAFe). It’s also important to maintain the core principles of Agile, such as communication, collaboration, and adaptability, even as the team or project grows.

M. David GreenM. David Green
View Author

I've worked as a Web Engineer, Writer, Communications Manager, and Marketing Director at companies such as Apple, Salon.com, StumbleUpon, and Moovweb. My research into the Social Science of Telecommunications at UC Berkeley, and while earning MBA in Organizational Behavior, showed me that the human instinct to network is vital enough to thrive in any medium that allows one person to connect to another.

Agileagile developmentJoshEscrum
Share this article
Read Next
Get the freshest news and resources for developers, designers and digital creators in your inbox each week
Loading form