Some Issues I Have Met While Implementing Agile (Part 1)

Source:  Freepik

At the beginning

Agile, as a complex methodology, some issues may be interrelated or recurring, and agile practice is heavily reliant upon context. So, all I mentioned below need to be analyzed by your agile coach according to your context, rather than making changes immediately.

Besides, here we only discuss "issues that have been found" instead of "how to find issues". That's another topic.

1. Lack of agile awareness

I would call it the deadliest issue. From the conversations between business departments, managers, and team members, you can find the issue easily. For example, they emphasize "make delivery at one time", "make more plans", "deliver more work results", and "It's agile, why don't you work overtime?". There is no silver bullet for such scenarios, we can only "prove with results" instead of "express with professional terms" in our daily work. Luring with benefit is one of the means to change ideology. In addition, it is recommended to reduce the use of agile terms as much as possible when communicating with such people to lower their resistance.

2. Less support from business departments

I would call it the most important issue to be addressed. It determines whether agile implementation can succeed. The issue is mainly manifested by the lack of cooperation from business departments, such as attending no meetings, clarifying no stories, and providing no feedback. At the same time, however, they ask the R&D teams to deliver work results in a quality and quantity manner.

Possible reasons for the issue:

1. The business department is aggressive. Once they are unsatisfied with the R&D department, they can complain arbitrarily.
2. The business department focuses on its own work, and working with the R&D department is out of its responsibility and assessment.
3. The business department is disappointed with the R&D department and regards all the support as in vain.
4. The business department has no time to support.

The following actions are required:

• Do your best to choose the business team with a high support level.
• Get recognition and support from a part of the business department through personal friendship.
• Change the stand of the business department, and bind their interests together with the R&D department.
• Rebuild the trust with the business department through transparency.
• Negotiate with business departments to get the proper communication methods, frequency, and time arrangement that both agreed with each other.

Source: Freepik

3. Lack of team participation

I would call it the most obvious issue. Teamwork needs to be driven by managers, while members won't seek work beyond the boundaries, and nobody will consider matters from the perspective of product delivery. Overall, most of such issues are caused by illogical regulations, processes, and governance. All the issues need to be addressed on the top tier of teams except one -- manager's lack of management skills.

Possible reasons for the issue of lacking team participation:

1. The company's performance assessment regulations have played a restrictive role in the self-organizing team. For example, the assessment focuses on personal performance, such as lines of code and delivered function points.
2. Complicated processes with a lot of duplicate work. For example, writing working logs and daily reports repeatedly, as well as data from multiple workplaces are not accessible to each other.
3. Less tolerance for mistakes. The cost of innovation is too high for individuals.
4. Frequent changes in team members and the team cannot stay in the normative or performance phase of the Tuckman model for a long time.
5. Manager's lack of management skills. It's one of the few issues that can be changed by training, coaching, and importing processes.

Let's draw back to the issue -- lack of team participation, if changes cannot be made to regulations, they will eventually be reduced to local optimization. In the absence of changes in regulations, it is recommended that an "interview" be conducted to address the matter itself. It is also possible to try to adopt some normative processes (although it seems a bit anti-agile) to change team behavior through action (although it is difficult).

Note: Someone says that team participation can be gained by building trust, however, I have a pessimistic view on it -- trust without regulation support is meaningless and can only exist on some special occasions, such as an influencer joins a team. In other words, systems and regulations are crucial pillars of "trust".

4. Poor-quality stories

I would call it the biggest problem in development. Poor-quality stories are manifested by development errors, rework, duplicate confirmation, duplicate modification, and other waste of development resources. Worse, it's one of the culprits of work overtime.

Possible reasons for poor-quality stories:

1. The business employees didn't express the stories clearly, or, propose solutions directly.
2. The product employees didn't write the stories clearly (capacity issues or attitude issues).
3. The stories can't solve customer's problems (and even result in complaints in the review meeting)
4. The stories are unstable and changed frequently within 1 iteration.

To address the issue of poor-quality stories, we can get started with the following points:

• Use visual guidance methods such as prototype diagrams, storyboards, etc.

• To reinforce the learning of business analysis (BA) for the product team, and focus on the procedures of story confirmation and review to ensure every story is correct.

• Making writing standards of story/requirement (DO NOT assume that agile doesn't require standards).

• Be brave to say no to unreasonable stories. 

Don't forget we could facilitate agile with some tools, click here to see How I Used ZenTao And Increased Productivity By 50%.