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

Source: Freepik

5. Customers are unsatisfied with deliverables

I would call it the most headache issue. Think about it, teams worked so hard and paid huge efforts to develop a feature, however, they were criticized as worthless by customers in the review meeting. Their working motivation will suffer a major hit and bring a disastrous decline in trust.

Possible reasons for the dissatisfaction:

1. Wrong priority. They did nothing for customers' key points but did everything the customer doesn't care about.
2. Just a few volumes of deliverables can't impress customers with the obvious result.
3. Poor quality of deliverables and even inability to complete the flow of Happy Path.

To address the issue of dissatisfaction, we can get started with the following points:

• Double confirm if tasks' priority is consistent with customers.
• Control and avoid unrealistic expectations from customers.
• Improve story flow time with automation tools, pipelines, and other technology; improve workflow with WIP Limit and other methods.
• Define the proper DoD

6. Slow or volatile delivery of work

I would call it the most normal issue. It is mainly manifested in the number of delivered items, the unpredictable size, or the fact that more work in an iteration is put into subsequent iterations.

In addition to the low quality of requirement input and frequent requirement changes, the slower work can basically be attributed to the team and tool level.

Possible reasons for slow or fluctuating delivery of work:

1. Inadequate team personnel capacity.
2. The wrong ratio of team members.
3. Insufficient use of automation tools.
4. Inadequate unbundling of requirements, resulting in some work not being completed within the iteration.
5. Make Agile a small waterfall.

The slow delivery of work can be addressed by these points:

• Building cross-functional teams.
• Rationalize the iteration and release plan.
• Building automated tool chains.
• Encourage the team to use their own handy IDE, tools.
• Teach the team how to split the story.
• Make the team aware of the importance of having "delivered items for each iteration" and measure them with metrics.

Source: Freepik

7. Disruptions to the pace of work due to varying levels of owned and outsourced staff

I would call it "growing pains". It is an inevitable and easily perceived problem in large companies. Some organizations are afraid to fire unqualified outsourced staff because of their outsourcing systems and strategies, fearing that they won't be able to pick up the staff and therefore deliver on time.

The only solution to this situation, if the company's employment system cannot be changed, maybe to change the way outsourced personnel is managed. For example, implementing an agile working model among own staff, and managing the outsourced staff with task allocation and time point tracking.

Note: Training of outsourced personnel is not recommended and is an abuse of organizational costs. Also, the mobility of outsourced staff can lead to wasted training costs. If possible, it is best to recruit outsourced who can run agile, otherwise managing outsourcing as a resource pool may be a more useful practice.

8. Others

There are a number of other points, most of which, from my experience, seem to be SM or AC issues that teams are not generally aware of.

• Wrong use of the framework

This is usually the easiest to spot and the easiest to correct. The solution is familiar to everyone and will not be explained. It is no more than training and coaching on frameworks and tools.

• No continuous improvement in the team

This is less easy to spot, except in the all-too-obvious case of a team not having a retrospective for a long time. There are several areas where this can be judged.

1. Does the team often make the same mistakes?
2. Team trends are too flat and do not improve over time.
3. Other metrics are too stable, such as story flow time.
4. The daily working atmosphere of the team is too quiet and there is not much communication and discussion. There is basically no solution to this situation other than coaching techniques, and there is no other way than to make the team aware of the importance of continuous improvement.

• Teams are like a black box

Typically, the team is unable or unwilling to be transparent and looks like a black box from the outside. This can usually be attributed to the organizational and management systems, giving the team the feeling that "the black box is the source of security". The team can be advised to be transparent on a small scale, for example, starting from within the team and then looking for opportunities to support transparency in the organizational system.

• Not using good engineering practice

This is probably one of the most difficult changes a team can make. For this, it is not recommended that SM or AC deal with it directly, but rather that the team will generally change after being pressured by the metric and then made aware of the contribution of engineering practices to the metric through training or coaching.