Working with a wide range of teams adopting agile, I’ve looked into what are the common pitfalls or caveats for a coach when starting up.
The information I present here is mainly gathered from system maintenance teams; i.e. teams that are focused on day-to-day handling of system failures, feature requests and general knowledge support.
The comon characteristics of the teams are (as seen by them):
- They are definitly not a team – they are a group
- Not cross-competent – working in silos based on system knowledge
- Few people (2-5 persons)
- High degree of self-management
- High degree of freedom to resolve tasks
To put it short, they are a group of people working in the same room. The only reason why they are grouped as a “team” is that the systems that they work on belong to the same business unit. Each person is a subject matter expert or key personel; each posses valuable knowledge about their own systems. Their workload is heavyliy depending on projects needing their system knowledge, large tasks that are just below the project-size barrier, day-to-day system failures/support/outages and massive requests via e-mail and phone.
These people are, generally, driven by few things in their daily life:
- An urge to solve problems for their customers (please customer)
- Large degree of self-planning (please manager)
- Ego-boost through key personel status (please themselves)
Through lessons learned I’ve collected a set of key motivators that definitely should be avoided when motivating agile in a new area.
Increase resource utilization by measuring throughput
Do not under any circumstance inform the team that this is a mean to make people work harder and faster.
It may be a key motivator for the mananger that the new formed overview gives input to evaluating performance – but flow optimization is key to agile. Team performance is increased by measureing the flow of tasks through the system. By performing retrospective meetings and reviewing the meassurements bottlenecks can be identified and actions can be identified. Comon congestion points are items like key persons taking on too many tasks, external suppliers not living up to their agreed deadlines, etc. Fixing these problems will result in higher performance within the team.
Force standardized processes on participants
Do not under any circumstance inform the team that introducing agile will also introduce a standardized process on the team.
It may be a key motivator for the manager that the overall process will appear to be the same after introducing agile. However, this is usually a side effect of analyzing the current working process within the team. It’s vital for the adoption rate of agile that the team begin with their current working process.
That being said, agile can be a used for introducing a company wide standardized process. But do it evolutionary and with great care. Conformance to standardized processes can be introduced step by step by gradually adding updating the policies attached to the agile board or through “definifion of done”.
Work sharing across competencies as key driver
Do not under any circumstance inform the team that introducing agile will turn the team into a cross-functional team where everyone is able to solve all tasks within the team.
The vital part of agile is to increase the knowledge within the team about task state through a visual overview. After a period of time the team, normally, starts to use the knowledge sharing forum to identify when and how they may assist each other. If the daily meetings are held in a structure emphasizing that focus must be kept on “getting things done” – it will become natural for the individuals to help out where applicable.