Transitioning teams and organisations to Agile is difficult as it is a very different way of thinking and managing to traditional organisational cultures. For an Agile team to be successful the immediate environment for the team must also change, this includes the Product Owner, Project Sponsor and the team’s immediate management. A successful transition ensures that the foundations of good Agile practice are in place and understood before the team starts varying its practices away from the basic framework. This article proposes a route to successful transition.
Shu Ha Ri
In learning new things, people go through a number of stages. Borrowing from martial arts the phases are Shu, Ha and Ri.
At Shu the student does not understand, they just copy as they learn the techniques. Once the techniques are understood the student passes onto Ha where they understand the relationships between the techniques and start to acquire additional ones. At Ri, they have mastered the techniques and can adapt them as necessary to changing circumstances.
Starting at Shu
Often when teams start to use Agile they want to pick and mix techniques from the chosen framework. This leads to low productivity and failure. When starting the transition, we cannot allow the team to tamper with the approach. They do not understand the framework and how one technique supports others. It is important that the team just follow the rules as they learn and understand.
At this stage, the Agile coach is providing training and guidance to the team helping them understand not just how but why we work in certain ways. The coach is helping the team understand the Agile principles and how it relates to the framework they are following. During Shu, the coach is also acting in a command and control style in that they ensure the team follow the framework and principles. Whilst the coach is not giving the team freedom to alter how they work, it is extremely important that the rationale for the techniques is explained, and how they relate to each other and the Agile principles. This has to be done at a team and individual level.
Often teams react negatively to this follow the rule approach so it is important that the team understand why this follow the rules approach is being strictly enforced and the conditions when the team will be enabled to start experimenting. More on this below, in the moving to Ha section.
Before asking the team to start using Agile, we train them in the basic techniques. So if the chosen framework is Scrum we train them in the ceremonies (stand-ups, Spint Planning etc.), estimating etc. Alongside the training, we must also start them on their journey of moving to teamwork.
Many Agile implementations fail at the interface between IT and the rest of the business.
To reduce this cause of failure, we must train other people in the organisation.
Along with the team, we must also train and coach the Product Owner [PO] in their role within Agile. The Product Owner should be someone who is responsible for the business outcome of the project. This means they will be reasonably senior otherwise they will not have the standing in the company to be seen as having authority to make decisions on behalf of the organisation.
Often these Product Owners will be managers whose behaviour and success within the organisation is grounded in command and control. We need to move the Product Owner to focus on business value delivery rather than managing the team’s work with a focus on the schedule. The priority here is on helping the Product Owner provide the vision for the project/product and identify value for the business. We need to help the Product Owner build trust between them and the team, with both working effectively together in refining the backlog.
To enable the PO to make this transition we must also work with the project sponsor, so they understand Agile working practices, roles and responsibilities. Ideally the PO and the Sponsor must be totally in line with regard to the project/product direction and business benefits.
In addition to the PO, the other major impact on the team are the team’s management.
- Do they still tell team members what to do?
- Do they reorganise teams without consultation?
- Are they making technology decisions on behalf of the team?
To solve this impediment to the effective implementation of Agile we need to start taking these managers on an Agile journey. Managers need to start thinking in terms of removing obstructions for the team and waste from the organisation’s processes, they need to become Lean managers. This means training them in their role and what behaviours will help the team, and what will be detrimental. The most important change we need to make is to allow the team to solve problems, themselves. This is difficult, as most managers became managers because they were good at solving problems and changing this behaviour is difficult.
Many people in IT are used to working within a team, a project team. These teams are often directed and managed in a command and control manner by a project manager assigning work and monitoring progress at an individual level. Agile requires a different model. The members of the team manage themselves. This requires the members to behave in a different way. To help them make this transition we can run workshops where the team are encouraged to discuss what makes for a good team. We ask them what behaviours they wish to encourage, how they will handle inappropriate behaviour. The coach helps them adhere to their agreed behaviours, and assist them modify the rules as required. This will happen as the team goes around the forming, storming, norming, performing cycle.
This transition is often difficult for the team, so coaching needs to happen both at a team and individual level, with the coach helping individuals to adjust to new working patterns and relationships.
As part of this initial set-up the team will also question how long it will be before they can control the way they work. Sometimes coaches answer this with a time period. In my experience this is not the best way of managing a situation, as different teams take longer to make the effective change than others. I find that setting a productivity target is appropriate.
The first sprint, assuming Scrum, will have very poor productivity, as the team are just learning and the development/test environments are unlikely to have been set up correctly. Over the course of a couple of sprints they will start to get over the teething problems. The second sprint will start delivering and I like to use this as the baseline velocity. Once the team has achieved a 300% improvement on the baseline velocity they are probably moving into the Ha stage. More on this can be found in the paper “Shock Therapy” by Jeff Sutherland, Scott Downey and Björn Granvik.
To achieve the improvement, the team needs to remove impediments and start experimenting with improvements. The coach needs to ensure that these experiments are in line with the Agile principles and that the team can measure the impact of the change. Implementing a data based improvement regime early in the teams development builds good practice for later improvements.
Moving to Ha
The team has been steadily been building their knowledge of Agile and the velocity has improved significantly. To continue their journey and development the coach now needs to take a less hands on approach, seeding more autonomy to the team. Coaching is still on-going but the command-and-control behaviours are no longer appropriate or used. Decisions are 100% with the team.
The team needs to start experimenting with the framework to see if they can improve their capability further, within their organisation’s situation. At this stage the coach reflecting the teams problems back to them and assisting them with new tools and techniques when they raise an issue they wish to solve. The coach helps the team experiment with the techniques to help them find what works for the team.
For this stage to be successful the team need to have confidence they will not be blamed when an experiment does not work. The coach needs to spend more time outside of the team, working with others in the organisation, helping them understand and adopt Agile and Lean practices.
At this stage the team have mastered Agile practices and the coach is no longer needed, indeed the coach may be learning from the team as they continue on their Agile journey of discovery.