4 common issues with implementing Agile and how to address them

While working on the open source ZenTao project, I get constant feedback that getting Agile up and running is a big task in many organizations. As with any new process, you will run into issues, and many of them will feel unique to your organization. While context is important, there's a certain amount of abstraction possible after you've coached enough teams. This article covers the four most common issues I've encountered. While your Agile coach should analyze any actual problems in the context of your organization, knowing these general issues can help better prepare you and your teams for the transitional process.

Note that I only discuss issues that have been found and not how to find issues, which is another topic entirely!

Lack of Agile awareness

I consider this the most significant issue. You can detect this issue in conversations between business departments, managers, and team members. They emphasize delivery as a single event that happens at a specific time. They talk about making "more plans," and you hear phrases like "deliver more work results" and "it's Agile, so why don't you work overtime?"

There's no single solution for this. You can only remedy these misunderstandings with results. Don't get bogged down in trying to correct perception; instead, focus on luring people into an Agile way of thinking with the benefit of Agile productivity.

Similarly, to lower any perceived barriers, you can reduce the use of specialized Agile terminology as much as possible when communicating with people who don't understand Agile yet.

Lack of support from business departments

This issue can determine whether Agile implementation can succeed. Business departments may fail to attend meetings, fail to clarify stories, and provide no feedback. At the same time, however, they may ask R&D teams to deliver work results according to "quality and quantity."

There are a few possible reasons for this issue:

• The business department is aggressive. Once they're unsatisfied with the R&D department, they complain arbitrarily.
• The business department focuses on its own work, and working with the R&D department is out of its responsibility and assessment.
• The business department is disappointed with the R&D department and believes support to be pointless.
• The business department has no time to provide support.

Here are some suggestions for addressing the problem:

• Do your best to choose a business team with a high support level.
• Be friendly! You can get a lot of recognition and support by increasing friendly and respectful communication.
• Bind the interests of the business team together with the R&D department.
• Rebuild trust with the business department through transparency.
• Business departments understand contracts. Negotiate with your business department to identify what's expected of them and what's required from them in terms of communication and support.

Lack of team participation

This problem is usually the easiest to detect. Team participation is key; you can generally identify right away when you don't have it. You see it when managers fail to lead a team, and team members don't feel empowered or inspired to improve the team's processes.

There are a few possible reasons for the lack of team participation:

• The company's performance assessment restricts teams from self-organizing. For example, an evaluation might focus on personal performance and actual lines of code.
• Team efforts include complicated processes with a lot of duplicate work. For example, members spend time repeatedly writing working logs and daily reports.
• Low tolerance for mistakes. When the cost of innovation is a high risk to an individual's job, it doesn't happen.
• Frequent changes in team members.
• The team's manager may lack management skills.

Ideally, changes would be made to the organizational policy to help team members engage and participate. In the absence of changes in regulations, conduct interviews with team members to address the problem directly.

Many people believe that team participation can be gained by building trust. That's true, but trust without organizational policy is meaningless because only the larger organization can ensure trust between team members. In other words, systems and regulations are crucial pillars of trust.

Poor-quality user stories

This is the biggest problem in development. Poor-quality user stories are manifested by development errors, lots of rework, redundant confirmation, duplicate modifications, and other wastes of development resources. Worse, it's one of the greatest causes of overtime.

Possible reasons for poor-quality stories:

• The client didn't express their requirements clearly or propose solutions directly.
• The project wasn't clearly defined, leading to capacity and sometimes attitude issues.
• The delivered product doesn't solve the client's problems (and even results in complaints in review meetings).
• The stories are unstable and change frequently.

Here's how I address issues of poor quality stories:

• Use visual aids, such as prototype diagrams, sketchnotes, storyboards, and so on.
• Reinforce lessons from business analysis for the product team. Focus on story confirmation procedures and review to ensure every story is correct.
• Establish writing standards for stories and requirements. (Don't assume that Agile doesn't require standards!)
• Be brave enough to say no to unreasonable stories.

Wrap up

Establishing an Agile way of thinking in an existing company is a big task with plenty of potential pitfalls. However, some problems are more prevalent than others and tend to span organizations. I've identified the four most common issues I've encountered. Whether it's lack of awareness, support, participation, or poor user stories, there are certain strategies that make handling these problems more manageable. How can you implement these approaches to help smooth the way for great Agile success?