Becoming Agile: Is training enough?

I’ve noticed a lot of people doing some sort of agile training. I’m very heartened by this move. Even designers seem to be starting to understand that working in close collaboration with a small, multi-disciplinary team can both produce and release great products each and every Sprint. But is training enough? Some suggest that you’ve got to change the culture to make it adequately support agile teams. Is this what’s next, or is there something more to help a team and its organisation become agile?
In his book, Succeeding with Agile, Mike Cohn talks a lot about introducing agile to new team and to the rest of the organisation. He notes that for successful adoption, people have to go through what he labels an ADAPT cycle:

• Awareness – that current processes are not delivering acceptable results
• Desire – to adopt agile methods like Scrum as a way to address the problems
• Ability – to succeed
• Promotion – through sharing experiences with others so they can see the successes
• Transfer – of the implications of using agile methods, like Scrum, throughout the company

It’s a great model to introduce the sorts of changes that are required to adopt the processes of Scrum because it’s not just based on management dogma or business theory, but on the behavioural science of the behavioural change. While Cohn based his model on ADKAR, the model dates back to James O. Prochaska who recognised that change occurs in multiple stages of learning — from pre-contemplation through to action and reinforcement.

The model is recognition that not only do we need to change our mindsets about how we think processes in our organisations should work, but also that we need to change our behaviours as well. This also means changing our perceptions of how we learn these new behaviours.

We can’t learn new ‘agile’ skills very well on our own

Social cognitive theory, used in psychology, education, and communication, highlights that “people do not learn new behaviours solely by trying them and either succeeding or failing, but rather, upon the replication of the actions of others”. In terms of learning an agile process like Scrum, Cohn agrees, pointing out that:

“[Scrum is] sufficiently different from traditional [processes] in that training along with on-site coaching or mentoring is usually required” (p33).

The key factors to learning skills from others

Bandura is known for founding social cognitive theory. He established the link between coaches and learners, noting that role models, are an important source for learning new behaviours and for achieving behavioral change in institutionalised settings. In an agile context, this equates to an experienced coach. The difference between a good coach and a great one is in recognising three regulatory systems that help to introduce new, agile behaviour and encourage the right behaviour that will support the transition to agile over behaviours that will impede success:

• Relationship – Previous or existing relationships that team members have with each other, or with others outside the team, greatly influence behaviour. Success and failure will depend on the coach lessening the influence of others on the team. This is likely to include removing the previous power relationship that a project manager might have had with the team and promoting new governance frameworks that put the Product Owner and Scrum Master in positions of influence insofar as roles and responsibilities are concerned.
• Response feedback – Following a response, the reinforcements given by experience or observation, will greatly impact the occurrence of the behaviour in the future. A good coach will be cognisant of rewarding behaviours that align to the agile method and highlighting the positive outcomes that the behaviours had in such a way that the whole team can understand what happened, why it was the right thing to do, in order to emulate that behaviour in the future to reproduce the result. Without response feedback the team may not know the behaviours that support or sabotage their project from being agile.
• Cognitive functions in social learning – Both the physical environment, reactions and associated thoughts are part of memory and learning. All of these elements need to be optimised for agile adoption to progress well. An experienced coach will help the team identify all of those factors — environmental cues that promote the right behaviour — and make them known to the team.

Improving the ability to succeed through four stages of learning

With the three factors for learning taken into account, a coach will then move a team from the basics acquired during training to one where they can operate on their own. These four stages were developed by psychologist Noel Burch in the 1970s while working with Gordon Training International (although they are frequently attributed to Abraham Maslow).

1. Unconscious incompetence

   The team doesn’t understand or know how to do something and does not necessarily recognise the deficit, and in fact may over-estimate their ability. They may deny the usefulness of the skill. The team must recognise their own incompetence, and the value of the new skill, before moving on to the next stage. The length of time an individual spends in this stage depends on the strength of the stimulus to learn.

2. Conscious incompetence

   The team doesn’t understand or know how to do something, they do recognise the deficit, as well as the value of a new skill in addressing the deficit. The making of mistakes can be integral to the learning process at this stage.

3. Conscious competence

   The team doesn’t understands or knows how to do something. However, demonstrating the skill or knowledge requires concentration. It may be broken down into steps, and there is heavy conscious involvement in executing the new skill.

4. Unconscious competence

   The team doesn’t has had so much practice with a skill that it has become “second nature” and can be performed easily. As a result, the skill can be performed while executing another task. The team may be able to teach it to others, depending upon how and when it was learned.

Importantly, the science of this approach reinforces that the team simply does not have sufficient capability after training to be able to expertly apply their knowledge. Repeated failure is most likely to follow. Success is often not repeatable because the team lack the skills to be able to recognise which factors actually contributed to the success and which ones did not. Overall, it shows that individuals are initially unaware of how little they actually know, or unconscious of their actual level of (in)competence.
During initial training an individual is likely to recognise their incompetence. It’s the coach’s job from that point to help the team consciously acquire the right skills by pointing out the right behaviours and the right environmental factors and making them explicit so that the team can consciously acquire the right agile skills, with the knowledge of how best to consciously apply them. Several elements, including helping someone ‘know what they don’t know’ or recognise a blind spot, are important tasks to expect of a coach.

Getting the right coach

A good, experienced, agile software developer might seem like the right person to engage to help a team become agile, but the requirements of coaching go much further than having conscious experience with a process like Scrum. Teachers go through years of tertiary training, learning techniques and adoption practices in order to be able to pass on knowledge of science, maths and english to children. Introducing agile methods successfully requires a similar approach — a professional who understands the science of learning as well as the topic at hand to teach. It means the difference between getting someone to tell you what to do and finding someone who will:

• Model and encourage the right behaviour through social learning.
• Make the environmental factors for success (and failure) overt to the team.
• Shield the team from interference by others who may not understand that their own behaviour impacts adversely on the team’s ability to become agile.
• Introduce new learnings at the pace at which the team can absorb them.
• Lead the team, not dictate to them, to enable them to move from consciously incompetent to unconscious competence.

Conclusions

The overall result of applying this science-based learning approach to agile has meant that, for my own teams that I’ve coached, they have the skills to know what do to, why they should do it, and the factors that contribute to success. They also know what happens when they don’t stick to the process and can make relatively informed decisions regarding when/if they should break the rules of Scrum. This doesn’t stop them from making mistakes — there’s been a number of times one of my teams has called me back to help them get through a specific problem that has impacted their agility during a Sprint — but it does mean they recognise their own limitations and can comfortably rely on mine to get them through. Sometimes this means I’m more of a counsellor than a coach:

• I listen actively.
• I watch behaviour.
• I support their decisions to break rules with the caveat that we’ll review the decision at Retrospective.
• I give advice only when they ask for it.

In the end, just as any psychologist does, I’m focussed on helping the team change it’s behaviour through helping them go beyond their training. Ultimately, it’s this multi-disciplinary approach to coaching that supports the team and its organisation to make the changes needed to its behaviour — processes, policies and governance — so that it can become agile.
M