Applying Agile Transformation from book “Switch”- A Must book for an Agile Coach

Chandan Lal Patary
7 min readNov 1, 2020

--

As a Change agent, what are we working out?

Essentially, as an enterprise agile coach, we are bringing change to the prevailing system.

We require to know-how can we simplify these change initiatives.

One of the game-changing books I have read last year is Switch, written by Chip and Dan Heath.

I am applying the concepts on an everyday basis; I would like to continue reading this book repeatedly and further so that it empowers me to become better change agents.

I have listed down all these points for myself to refer back to again and again.

Switch tries to answer the question:

What makes the change so hard to accomplish?

The elephant: our emotional side

The rider: our rational side

The rider controls the elephant and seems to be the leader.

But the rider is small compares to the elephant that at any time can disagree and go another way.

If you want to change things, you have to appeal to both the rider and the elephant.

The rider provides the planning and direction, and the elephant provides the energy.

Our emotions can overwhelm our rational thought while relying solely on rational behaviour can “overanalysed and overthink things.”

What looks like a people problem is often a situation problem. The book considers change at every level- individual, organizational, and societal. All change efforts usually have something in common: “For anything to change, someone has to start acting differently.”

What looks like laziness is often exhaustion.

When a task feels too big, the elephant will resist.

The Elephant and Rider are usually on two different pages and trying to persuade the Elephant often exhausts your mind. The Elephant will usually win over the Rider.

The Rider part of our minds has many strengths. “The Rider is a thinker and a planner and can plot a course for a better future. But as we’ve seen, the Rider has a terrible weakness- the tendency to spin his wheels”.

The Rider loves to contemplate and analyse and making matters worse, his analysis is almost always directed at problems rather than at bright spots.

Keep the Switch Going.

Few samples of recommendation from the book for us to apply for the Agile Transformation Journey.

We are not going to overcome the change issue by communicating to the Rider. Instead, we have to identify the feeling elements. Need to identify a feeling that will get the elephant moving.

In one of the assignments with the team, they were struggling to use the Test-Driven Development and Behaviour Driven Development. They were thinking it will slow down the execution speed. What we have tried every TDD & BDD practices we compose, the Product Owner will give points by the impact those were constructing. At the end of every sprint, we have an appreciation for the best number of TDD and BDD cases completed among teams and Team members. So, there was an understanding spirit that inspires such Shift Left practices to expand.

We have to create empathy. We need to show people’s problems with not changing.

In one of the Illustrations where the Product owner was not at all participating in our team Scrum Events, we discover that the Product Owner is also heavily loaded with the Business side other product delivery responsibilities. Initially, we were just complaining the PO is not participating in our scrum events. We discussed with the PO’s manager and other team members; We demonstrate our unique ways of working, the manager of the PO promised us to provide some solution, and he kept his commitment by withdrawing some of the PO’s other activity and redirect his energy with our team.

We need to find the bright spot that is invented here and clone it.

We search for many opportunities to promote the business collaborations and we just enhanced those. For example, some time on a smaller scale we used to do a Requirement brainstorming workshop with a Design thinking approach that too with limited time. We realized that it helps to discover the world of the end-users better. We started doing such thing more and more. and it helps the team to build the right product.

We need to create a destination postcard. How to go from point A to point B. Give it to the rider. Let the rider use it.

Our transformation journey was strengthened with many Cheat sheet. e.g. There are many levels we specified: Initial practices, Intermediate practices, and Advance practices. We clearly defined entry and exit criteria and elaborate interpretations of each of those so that there is no confusion among team members. We coach and mentor that team so that they understand all these steps and outcome goals.

We have to create a new habit. Habits are behavioural autopilot. Script the critical move.

We recognize what inspires us to become better. We note down and bring in some of the new habits. e.g. Daily check-in and frequent code review are critical. We encourage Pair programming. We made this a rule that all the code base has to pair program and code reviewed and daily build must be working without fail. We repeatedly follow through with these practices for a long time until every developer follows through it. If build breaks happen, it has to fix in 12 hrs. And this habit every developed has to embrace.

We have to create a smooth path so that any unmotivated person can slide into it? Don’t assume the new moves are obvious.

For all the new ways of execution, we have trained; we have mentored, and we have coaches for months with the team members. We were with the team for a minimum of 4–6 months as a coach and mentor to ensure team members understand and follow through.

We have to shrink the change so that we can start today, if not today at least ensure it triggers tomorrow

All our new initiatives are small practices with incremental complexity introduced. The Transformation journey is 6 months to 12 months based on the complexity of the product dealing with. We have many practices to cover. So as a coach we commenced with modest and progress on with all the 25+ practices areas to reach in 6 months to 12 months timeline.

Find a person from the team who thinks it will work, create a free space for them where they can catalyse the change without facing direct opposition.

We have Scrum Masters, technical Leaders, and senior team members who are with the product for a long time, they were our Focal for each practice. We spotted them as our key individuals to pair with us. We are co-creating the specialized exercises with them to convey the key messages so that it gets accepted by the team members.

How can we tweak the environment so that we are forced to change?

How we have done this, we have ensured Business people are associated with us. Business people look into the demo. Business people challenge us about the value and progress. we modify the working model so that the change starts driving us towards that direction. 0 bugs goals set by the business also a change initiative force the team to adopt XP and software craftsmanship related practices.

Behaviour is contagious, we need to find someone else who will be involved with the team in this change process so that he/she can reinforce each other.

We pair up with other coaches, an Agile coach, and a Technical coach responsible for team agile transformation. Both the coaches are helping each other for the right directional changes. We reflect and exchange, distribute our feedback about the transformation we are producing.

Let me focus on building habits. Once we create habits, we get unique behaviour.

At the conclusion of the 12 months of the product team transformation journey, we ensure we concentrate on changes to sustain at the team level what we have been seeking.

We have to keep motivate the Elephant by reminding how much they have already accomplished. A sense of progress is critical because the Elephant in us is easily demoralized.

We have as a team bi-weekly stand-up about the overall transformation progress. We highlight what we have accomplished so far. We look for cooperation from the leadership to resolve any challenges.

We have weekly stand-up with the transformation coaches and seek progress report and share the different achievements and challenges we were encountering.

We have to teach the growth mindset (We will struggle, we will fail, we will be knocked down — but throughout, we will get better and we will succeed at the end).

All the teams are set for the experimental and learn from the failure concept. Everyone was encouraged to celebrate learning from failure.

What looks like resistance is often a lack of clarity.

We have established a central guideline site; we have various 2–10 mins videos. We have a monthly town hall meeting, we have monthly leadership review meetings, weekly stands up a meeting about the transformation progress to share, understand, and discover what we should be working out to address all the challenges. We take action to keep going towards the objective.

Do not speak to the rider when we should be speaking to the Elephant

We always to the coaching circle to reflect as a coach where we are going right and where we are going wrong. We communicate to the team members in weekly transformation progress meetings so that we observe and capture the corrective action, we have a pair coaching session, where 2 coaches will drive some of the discussion, we are constantly studying and stimulating the changes so that we understand the elephant and the riders.

Please share your comments, if you have tried something like this in the transformation journey…

--

--

Chandan Lal Patary
Chandan Lal Patary

Written by Chandan Lal Patary

Author:-The Agilist’s Guidebook | The Scrum Master Guidebook | Personal Leadership and Self-Coaching Guidebook | High Performance Team Coaching Guidebook

No responses yet