My Journey as Agile Coach guiding Agile Transformations

During my agile coach journey, I am fortunate to work with customers across the world & able to see different flavors of agile adoption. One thing I learnt is that each team is different & have their own set of challenges & there cannot be best practices which can be implemented across. Only by making a connect & having effective conversations through thought provoking questions we can unleash team’s full potential.

Sharing a similar coaching experience where teams were facing various challenges with respect to agile scrum adoption. Here one of the major challenge highlighted by my organization leadership & Customer was:

Problem: Agile Teams were consistently not able to meet sprint goals. Due to this, customer was unable to plan his releases.

It was very easy to be confused over symptoms of the problem & missing the underline problem/impediment. At high level it looked like:

1) Team is over committing or PO is making the team over commit

2) There are issue with team productivity or throughput

3) Team lacks technical excellence

4) Sprint length is inadequate for delivery

5) Issues with respect to estimation & sprint planning & so on….

I used the Empathy Map technique to get a closer look at the issues faced by the customer, gauge the customer expectations, identify gaps in our understanding & things we did not know. I facilitated meetings with the development team & PO where an empathy map was created on reasons behind not being able to meet sprint goals & then presented this empathy map to the higher management and stakeholders. So the leadership was able to visualize the team thoughts & was able to understand the reasons behind the team’s inability to meet the expectations.

Why an Empathy Map?

It shed light on which customer problems to solve and how, thus helping us focus on the most important set of problems. It provides a good platform to get a candid customer feedback & create action plan based on it. Agile is a way where problems automatically surface & once we know we are not working on the symptoms but the actual problem, a solution can be generated easily through experimentation, feedback & a systematic approach.

Empathy Map Outcome: Teams & leadership were working with traditional mindset or lacked Agile Mindset. In terms of adopting scrum practices, team was mature but in terms of understanding & the way practices were implemented, they exhibited the lack of an agile mindset.

Question which may came in your mind, what exactly is Agile Mindset? An Agile Mindset is about being passionate about agile values, collaboration, team work, empowering people without compromising on ethics, a strong desire for continuous learning & embracing challenges without any fear of failure.In short when a person believes he is always Learning & Not Failing.

Term coined where Scrum is followed without Agile Mindset Where scrum is implemented without team mindset transformation can be termed as “Technical Scrum”. So here due to lack of agile mindset, scrum adoption part is done but team struggles with transformation, which leads to various issues, one of them being inability to meet Sprint Goals.

Below is the difference highlighted b/w adoption (Technical Scrum) & transformation (Scrum with mindset change).

Is it difficult to develop an Agile Mindset?

Incorporating an agile mindset is like a New Year resolution, where an individual makes a promise to improve his self & knows what he should do but is unable to break his habits.We can acquire the mindset by practicing Scrum. Agile Manifesto can also inspire the mindset shift, but it’s in actual following the practices where we acquire the mindset & then it can be called a progression.

Two barriers identified after the empathy map presentation on why agile mindset not developed were:

1.    Customer & my organization management wanted to implement agile with micromanagement (Command & Control Mindset) where teams were supposed to make changes with respect to agile implementation but not expecting any changes in terms of their own hierarchy, behavior & current way of working. They were still interested in looking at Gantt charts & color coded trackers.

2.    Team having misconceptions about Agile, scrum framework with no clarity on project & agile goals the customer wanted to achieve. Customer command & Control mindset is leading to state where teams were not empowered, the environment was unsafe to experiment, restricting the teams from being self organized. All this was leading to lack of team accountability towards sprint goals since team believed it’s the goal of the product owner & not their own. We were violating the two agile principles here: 1) Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 2) The best architectures, requirements, and designs emerge from self-organizing teams.

Team members had misconceptions about agile & had no awareness of project goals/reasons behind agile adoption. It was similar to throwing a Gala but the host still being unsure of the who the guests should be and why he threw a party in the first place. Yes it is that bad.

Here it lead to:

In order to resolve mindset issues & to lead the Team/leadership from Agile Adoption to Transformation, I adopted the following strategy:

       1.    Formal Training, town halls, workshops to enhance the team’s understanding of Agile

       2.     Coach for Action

       3.     Convinced top leadership to move from bureaucracy to adhocracy (Flexible Governance Structure)

       4.    Measuring Progress by KPI Base-lining

       5.    Follow up and support for team emotions

 1. Formal Training, town halls, workshops to enhance the team’s understanding of Agile

I believe in enabling navigating and exploration by focusing on the discovery of knowledge, rather than the mere transfer of knowledge as complete transformation requires mindset change. But here hidden wrong assumptions and beliefs must be unearthed for the teams to be agile & since leadership were new to agile they did require some basic formal training.

·        Formal Coaching Conversations with the team: Conducted formal coaching conversations to gauge their belief value system, mindset & then create a strategy to move them from fixed to growth/agile mindset. I made sure that I do not come across as prescriptive or directive during my conversation but as a catalyst.

·       Workshops to cultivate Agile Mindset: Since the team was not collaborating much, conducted workshops focusing on Agile Mindset so as to enable them traverse from a fixed to a growth mindset.

·        Facilitated brainstorming discussions to build sense of urgency with respect to agile adoption: Facilitated brainstorming sessions so as the team members could explore the possible options to experiment. Once the teams established the alternatives, I helped the teams pick commitments that they were interested in exploring. Ultimately it created a sense of urgency along with the interest in teams to do tangible activity which will link their actions towards the goal.

·        Facilitated Town halls where leadership shared the organization vision & rationale behind agile adoption to the team. It was carried out in the form of OKR’s, since a strong vision statement, when used in the right way, will motivate the team toward a successful agile transformation.

2.  Coach for Action: Followed below Action Plan to address mindset challenges:

For Team:

·        Used CREATE model to cultivate new thinking in teams & to explore opportunities towards positivity which helped team understand current reality and explore alternatives.

·        One of effective way of coaching I used at customer side was to video record a couple of scrum ceremonies and then asks the team to watch the videos back. It made the team realize the anti-patterns.

·        Created self-awareness in teams by avoiding judgements & helping teams to discover where they stand. Prompted team members to explore possible options to experiment.

·        Focus on “We” over “I” in our communication had been made a norm which created a lot of difference in their mindset and team started collaborating using the term “we” which eliminated blaming culture.

·        I also worked on building the trust between Product Owner & the teams since the reason behind micro management was the missing trust factor. In order to build trust & to make the team realize that Daily Scrum is not merely a status check meeting, I changed the format of meeting from:

o  What they did in this story yesterday

o  what they are planning to do today

o  Any impediments

To recast the questions to focus on the sprint goal

o  What did you do yesterday to contribute to the sprint goal?

o  What will you do today to contribute to the sprint goal?

o  Is there anything out of your control that will prevent you from contributing to the sprint goal?

For Customer/Leadership

·        One to One discussion with product Manager & leadership on their goals & through thought provoking questions make them realize that micro-management is counterproductive & how the team can innovate & be more accountable if they feel empowered.

·        Facilitated Management 3.0 Delegation Poker exercise to allow leaders/management to uncover severed connections in servant leadership.

·        To strengthen connections within the team, facilitated a program-wide retrospective where team members talk openly with the leadership & can find answers to their own problems. Also explained the facts as per neuroscience of engagement which states “Employees are more engaged/motivated if they have clarity in what exactly they are doing & why they are doing it & are empowered to make their own decisions”.

·        Coached Leadership teams on the value of sustainable pace by working closely with them and made them see how employee satisfaction increases productivity automatically.

·        Convinced leadership to encourage the culture of empowering the teams and embracing a fail fast culture so as to build high performing teams by quoting the agile manifesto. The Agile Manifesto includes the principle, “The best architectures, requirements, and designs emerge from self-organizing teams." So made leadership understand that Self-Organization is must for successful agile adoption.

·        Convinced leadership to enable safe environment for teams & focus more on reward & less on threat since safety is a basic human need and is the key to unlock high performance. If people are afraid of changes, afraid to voice their opinions and are afraid of making mistakes, it will kill their performance. If you have a culture of fear, none of the fancy practices help..

3.  Convinced Customer to move from Bureaucracy to Adhocracy (Flexible Governance Structure)        

·        The current organization operates at high levels of unpredictability so decisions cannot be taken by following set rules, procedures & through the hierarchy, so Adhocracy supports experimental approach to decision making. Adhocracy is about minimizing handovers and bureaucracy, and empowering people..

· It’s much easier and more comfortable to add things because that gives you a false sense of control but what you should commit to is a real act of leadership. So convinced the customer to not complicate structure, the processes at least at program level & move to agile ways of working that rely on a “flattened structure”.

·        Advised the leadership to move away from formal meetings, detailed planning and excessive “input steering” in exchange for empowered teams, informal networks and “output steering.

4. Measuring Progress by KPI Baselining We cannot improve if we did not measure.To inspect & adapt we should have some baselines which can suggest that we are making some improvement. So I suggested few KPI’s to capture on sprint basis to see where we stand & track accordingly.

5.  Follow up and be supportive for team emotions Helped team experiment with their choices to help them inspect their actions through facts and support their emotions with empathy. Enabled them to come up with new goals to reach the target by providing Psychological safety to the team making them immune to failure consequences.

Final Outcome Within a quarter, team was able to meet their sprint goals without burning out.Not only this, there was reduction in bug count since technical skills were enhanced, team members were more confident to take up challenging stories & feel more motivated. Since teams were able to deliver what they commit, Product owners & leadership were able to plan their releases well with reduction in Time to market.

During my agile journey, one thing I failed to understand is â€œWhy are we so passionate about pushing one method, tool or philosophy over another, when all we truly want is the final value and outcome of a true transformation?

My Two Cents Don’t fix problems for the sake of fixing problems. Get in the agile journey; as you go deeper, you’ll identify the roadblocks that prevent you from being more successful and then address those problems. Fix it and then go for the next one, rather than trying to create a master design and change everything at the same time.