‘Coaching’ and ‘training’ are two terms which are similar in meaning but quite ambiguous in existence. What do these words mean? Can they be used interchangeably? Is one more desirable than the other? Each of these questions can be debated at length, and the distinction might be difficult to make till one practice as a trainer and a coach. Getting into the skin of the game and experiencing the act of coaching and training will reveal the answers, though not many of us have the opportunity to do so. When we are trained up to become a coach, it is the time to coach someone else to train! Sounds confusing? Let me elaborate on that.
Coaches Need Training
Coaching is an art that needs to be learned and practised, it does not come naturally to us. It is a refined methodology which delivers maximum effectiveness through dedicated and committed practice. Most of us tend to mix up coaching with problem-solving and solution-giving, but coaching is far-stretched from it. It is primarily about ‘listening’ and ‘asking the right questions’ instead of ‘giving answers’. Since it is a learnt behaviour, one needs to learn and practice, which is nothing but getting trained on the subject. So to become a coach you need a trainer, and you can’t be coached to be a coach.
Trainers Need to be Coached
Coaches who are engaged in training their fellow coaches-to-be are not donning the role of a coach, instead of the role of a trainer in this case, as they cannot merely ‘listen’ and ‘ask questions’ to upskill the participants. If they knew all the answers, they wouldn’t need to be trained to become coaches. A trainer imparts knowledge and skills about a specific realm of activity or engagement which a trainee is unaware or unskilled at. He/she has abundant mastery over the subject matter and can convey his learning (fine-tuned by experience) in a structured and coherent manner. However, some trainers may not have the wherewithal to influence their audiences effectively or format themselves in the ways that would ‘click’ with the trainees at the psychological level. Their skills and competences as a trainer are limited in dealing with scenarios as such, and a different skill set is required to fill the gap, for which the trainer may need to be coached!
To Coach or Train?
Simple, let’s answer these questions:
You need a CSM certification to improve your skills at work. Will you seek a trainer who offers training in the subject or will you hire a coach to help you out?
You have difficulties engaging people and leading teams at work and you’d like to be empowered and impact. Who will you approach, a coach or a trainer?
The answers may seem to be interchangeable at the first glance as if one can engage services of either a trainer or a coach in both scenarios. However, it is revealed in the first scenario that one is looking for a particular skill and a latent product (certificate), and he/she needs to acquire the appropriate training to be authorised with specific competence. In the second scenario, the issue one is confronting is what he/she perceives as a problem, which might not be the case or the reason behind it. A coach would be helpful to map one’s behaviour with the environment and allow one to reveal the root cause of the predicament and how to extricate from it. On the contrary, enrolling into a ‘personality development’ course and getting certified may not be as helpful in this case.
Amplifying the Difference
I hope the distinction between a Coach and Trainer is clarified. The differences can be reinforced from the following applications:
Get a trainer when the skills you want to acquire or develop is clear to you
Get a coach when the skills you want to acquire or develop is NOT clear to you
Get a trainer when you seek to achieve an immediate goal that fulfils a particular need
Get a coach when you DO NOT know what goals to target that fulfils your needs
Get a trainer when you need a stamp of authority to earn relevance in your community
Get a coach when you need a stamp of conviction to earn your true relevance in this world
Get a trainer to train you to become a successful coach
Get a coach to coach you to become a successful trainer
As an Agile Coach, the trainer gets to don the role of coach and the coach dons the role of trainer. It distils down to mindset, for example, an Agile leader has to don both hats simultaneously in the process of fulfilling the need of the team members. An agile practitioner gets to live in both worlds and transcends between both roles with ease and dexterity. Agile is all about being flexible, adaptive and participative – significant attributes that are vital for a Trainer and Coach of merit to prosper.
The 17th-century English philosopher Thomas Hobbes had discovered an interesting theory named the ‘Hobbesian Trap’ – when one is gripped by the fear of being attacked, he pre-empts by arming himself, which instils fear on the (would be) ‘attacker’ who in turn upgrades his arsenal. This action escalates the initial fear and forces the ‘defender’ to upscale too, leading to an uncontrolled spiral (the Arms Race). Whilst the analogy may seem off-the-track with Agile and Management, the illusion of the Hobbesian Trap applies to all aspects of human psychology, especially in the realms of coaching and consultancy. When a decision needs to be made between a coach and a consultant, one is put in a dilemma – Who can help the business to improve profitability / produce a higher return on investment / enhance customer satisfaction? The answers to these questions may lead to a spiral of uncertainties. Most business owners face the Hobbesian Trap when it comes to hiring a consultant or a coach, on the sheer premise (or fear) that one is absolutely needed for the business, while having little or no knowledge of what role they play in the company’s growth or what they can help the company to accomplish. The Coach
A Business Coach is a facilitator and enabler. He/she triumphs over your accomplishment and his/her primary job is to enhance and sharpen your skills to ensure you achieve your goals. Coaches work ‘inside out’ – they assist you to develop purposes and reasons, which help to generate desired behaviour in your business. Business coaches also help to address issues with regards to the mind-set or unconsciousness, such as limiting beliefs, fear of unknown and the ‘Imposter Syndrome’. They build a supportive environment with clarified accountability to ensure you follow through your actions to completion. In summary, a coach facilitates you to define your goals for your business and the “plan of action” to achieve them, and he/she stands by you through the process of implementation.
The Consultant
A Business Consultant is a subject matter expert who addresses specific issues to influence your business positively. He/she provides the knowledge, skills and competencies, to analyse your business and propose a solution to the problem, and customises an action plan to implement the solution. A consultant employs his/her extensive experience and knowledge in business planning and strategy to gauge the scalability and direction of your business, course-correct specific domains such as optimising sales and marketing strategies, streamlining systems and processes, reforming organisational structure, and so on. A business consultant brings a fresh opinion, objectively assesses the current state of the business (‘as is’) and helps to shape the target state (‘to be’), creates and implements an action plan to accomplish the business objectives.
Who Do You Need?
The key to unravelling this mystery is to enlist the services of both to support the internal and external mechanisms of your business. That being said, it does not mean that one needs to hire a coach and a consultant – instead, one can be upskilled to step up to either of the two roles with adequate resources. It can be argued that in comparison it is more feasible to be upskilled as a coach than a consultant, as the functionality of the roles suggests. A Coach tends to be more ‘people-centric’ and an Agile Coach operates on the principle of ‘people over processes’, who can be possibly better in understanding this other than the business owner himself?! Of course, the assumption is more appropriate for small enterprises and large organisations would need to engage external coaches to offset bias in work ecology. It is important that the need to be trained as coaches at the Executive level is not dispensed with. It is more to do with people than the task at the senior levels of the organisation, and when it comes to determining a coach/consultant one needs to introspect on three key areas:
The quality of intrinsic knowledge existing in the business
The strength and robustness of the support structure on which the business resides
The quantum and time-sensitivity of the target results
Knowing the difference between a business coach and consultant can help one to avoid the Hobbesian Trap, therefore save costs and avoid disappointing outcomes. Agile enables you to be clear and upfront on the level of knowledge, support and outcome your business desires, and assists you in making the right decision. It obviates you from getting into the trap. It is crucial for one to understand the organisational requirements, and upscale the corporate strategy by deploying an Agile Coach or an Agile Consultant (or get trained as one), or both as per the merit of the situation, to achieve the desired result.
I have been working as an Agile coach for one of the top-tier companies in the world. I want to share my experience working with leaders and teams in regard to Agile metrics. To give a high-level background, one of my clients has adopted the Spotify organisational model — Squads/tribe/chapters and guilds.
FORMING AND TRAINING TEAMS
In the 1st quarter of 2017, I was working an FTSE 100 company, whose objective was Agile adoption and transformation across CIO (more than 2,500 people). We had different domains and subdomains under CIO. A coach was assigned to work with each domain. We started with forming the right teams, doing the right work, and measuring what mattered. The entire 2016 was marked as Wave One — to form the right teams; enable the team members, including the product owner; and train them on Agile principles and values and the basics of Agile (mainly Scrum and Kanban). We also worked on-demand versus delivery management in parallel with forming the teams.
After our teams and workflow system were in place, we worked on capturing the Agile metrics. We agreed to capture the velocity, story points, burn-down/burn-up charts, defect trends, throughput, and cycle time as a few of the key metrics. The Agile Wave One was completed in January 2017, when we (55 coaches across the globe) had finished training 2,500 team members on Agile adoption and implementation.
During the reflection/relearning session from Wave One, we were clear on the metrics we were capturing for the end of each sprint. Leaders were keener on getting the metrics that rolled up into their respective tribes, subdomains, and domains but had no clue on how to interpret the numbers. And leaders were also trying to compare the velocity across squads and tribes; it was just a numbers game at the end of each sprint.
CAPTURING AND COMMUNICATING METRICS
I was interested in discussing with the squads what we should measure. Was measuring velocity and story points helping the squads get better? And did they receive feedback from management on the metrics the squads submitted at the end of each sprint?
The outcome of the metrics discussions was that the squads felt that it was not about measuring the velocity for each sprint that mattered; it was more important to study the trend of the velocity for each squad and analyze the variations/deviations, which would help the team get better and course correct. They concluded that the trend analysis should be done at the individual squad level and not compare the metrics with other squads. A few team members also felt that velocity was more of a predictable number, and the real measure was the value delivered to the customer at the end of the sprint. There should also be a benefits realization of the work done by the team (i.e., Product is responsible for cascading the value and benefit realization to the squad).
KEY METRICS
Metrics are used to measure four key aspects: people, customer, financial, and process. Then balance your metrics among outcome, process, and behaviour.
People: Team morale or team satisfaction; attrition rate or skills gap
Customer: End-user satisfaction or number of defects
Financial: Unit cost per transaction or total cost of whole operations
Process: Throughput or cycle time; the size of the backlog
Takeaway: Don’t focus solely on the numbers. Observe trends. Plot the data over time to determine whether there’s an improvement or fallback.
It is not always about metrics, metrics that matter to the team. Rest all is nonsense!
It is vital that metrics be maintained daily or weekly, and that you are consistent in the way you measure them.
Keep the metric simple: Measure only what matters, not more.
Make big visual charts of the key metrics, and put them up on the walls for viewing.
Leadership Tribe has been helping organisations in their transformation journey and we are here for you. Contact us directly and we can have a quick discussion over a cuppa to support your Agile Transformation.
We all have been studying/doing/practising Scrum ceremonies for years now and we all agree that the Scrum ceremonies are key for the teams and projects success.
I have been working with teams in my organization with regards to Scrum adaption and implementation, as a part of team enablement or training, I thought of applying a different training technique, to understand and learn about Scrum practices/ceremonies. The best I could think of was Simon Sinek’s Golden Circle Theory.
What made me think of using the golden circle theory, were few of my following observations working with Scrum teams, every scrum team in my organization knew ”What” they do as a team, with respect to scrum practices and some of these Scrum teams knew “How” to do it and this very factor made these Scrum teams special from others in the organization, as last very few scrum teams knew “Why” they are doing what they are doing? That’s the outcome or results they are deriving at and it’s the whole purpose of adapting the scrum way of working and scrum transformation.
Here are the ceremonies with respect to ‘Why, How and What’ behind it…
Sprint Planning
Daily stand-up
Sprint review
Retrospective
Let’s look in details for one of the Scrum practice as an example…
Sprint Planning: An event where the team collaborates on the work to be completed in that particular sprint. Entire Scrum team participates in the sprint planning event.
Why we need it:
To understand and establish the sprint goal(Outcome)
Commit to the user stories that help us achieve the sprint goal
Derive at sprint backlog(Output)
To discuss and define the sprint goal
What and How we do it:
The scrum master, Product owner and agile team are part of this meeting.
The Product owner talks about the highest-ranked user stories from the product backlog
The agile team derives at the steps required or tasks necessary to complete the committed user stories
Planning continues while the team can commit to delivery without exhausting or exceeding the capacity.
Sprint Planning is time-boxed to a maximum of eight hours for a one-month Sprint.
Sprint planning answers two things: What can be delivered in the Increment resulting from the upcoming Sprint? And How will the work needed to deliver the Increment be achieved?
Why we need it:
Stand-up unifies team
The team holds each other accountable for their commitments
Teams are transparent about the challenges, success stories and failures
Respect for individual irrespective of their position and performance
Stand-up meetings help the team to focus on a few
The team helps each other
What and How we do it:
Tell about “What you accomplished yesterday”, “What are you planning to accomplish Today” and “Obstacles/impediments which are blocking you to perform”
Try using the following format:
What did I accomplish yesterday?
What will I do today?
What obstacles are impeding my progress?
Any other discussions to be taken offline after the daily stand-up
We walk the wall- talk our cards
Meet at workspace before your scrum/Kanban board, so that you can update the board as you talk.
Time the meeting to <= 15mins
Rotate the facilitator based on the agreed-upon rules. (Every 3 sprints)
Don’t wait for the entire team
The team should be prepared ahead of the meeting
Have agreed on rules about who speaks when
Avoid talking about technical details in the stand-up
Core team, BA and PO/PPO to be part of the daily stand-up
Sprint Review: Sprint review is simply the meeting where the team demonstrate the work done or functionality built during the sprint.
Why we need it:
To inspect and adapt the work done during the sprint.
Assess the work done against the sprint goal, which was agreed upon during the sprint planning.
Make sure the team delivers a potentially shippable product increment of working software
What we do:
Setup the expectation at the start of the meeting, with regards to what will be demonstrated.
The team members will demonstrate the new functionalities built/developed in the current sprint.
Can also talk and discuss the upcoming product backlog.
How we do:
Either the product owner or Scrum master will facilitate the sprint review meeting.
Can last up-to 2hrs for a 2-week sprint.
The entire team participates in the meeting
Close the meeting thanking every participant.
Retrospective: At the end of every sprint, the scrum team reflects on how to work more effectively and adjust their actions and behaviour as needed.
Retrospective Prime Directive:
It’s crucial to have an open culture in an agile retrospective, where team members speak up. In his book Project Retrospectives, Norm Kerth defined the Prime Directive, it’s purpose is to assure that a retrospective is a positive and effective event:
Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
Agile Teams primarily operate from a ‘people-centric’ paradigm, hence, where humans exist there shall also coexist dissent and disagreement. Often, well structured and motivated teams are bound to enter into a zone of apparent ‘disarray’ because of the uncertainty principle of reality. Things often will not go as per plan. How do we ensure this disarray does not escalate to disruption? What should we know that will ensure matters do not spin out of control? For the Agile team, conflict management gets regulated and controlled to a significant degree. Let me amplify how:
Congruence of Outcomes
Agile facilitates the possibility of allowing team members to be in perfect congruence to the stated vision/mission of the project. Ensuring clear communication channels and propagating the cause on which the success criteria is leveraged creates an opportunity for each member to develop personal ownership towards the planned outcome. This creates a healthy psychological culture which ensures congruence between the perceived outcome and the stated one.
Shortening the “Storming” Phase
The ‘Storming’ phase (Bruce Tuckman Model of Team Building) of team evolution gets significantly shortened with the common vision. Storming occurs where there is a conflict between team members’ natural working styles, opinions or when authority is challenged. People have a natural style of doing their work; this differentiation may cause unforeseen behavioural fallouts and may result in frustration and heart burn. While such an occurrence is inevitable, Agile helps in mitigating the manifestation of conflict in such scenarios to a great degree.
Role and Task Ambiguity
Team members tend to jockey for position as their roles get clarified. A similar pattern may occur if the task hasn’t been defined clearly how the team will work. This results in members getting overwhelmed by their workload or uncomfortable with the leadership approach being administered. Agile, with its inherent people over task centricity, obviates such as uncongenial workspace situations.
Perceptual Variance
How are individual perceptions dealt with? How are stakeholders perceptions addressed? Is there room to accommodate human perceptual precepts? Agile provides an allowance to monitor and respond to the variance in human perception.
Felt Need of Client
The felt need of the client often gets obscured by the overwhelming presence of jargon, false assumptions and legal fine print. Agile, provides space for client needs to be freely expressed and taken due cognisance of.
Conflict of Beliefs and Values
People operate within different value systems and experiences that lead them to handle situations in varied ways. A robust Agile team collaborates and is responsive to change, hence devoid of anchored belief and value sets.
CONFLICT MITIGATION
It is best to predict and be responsive to conflict initiation and achieve conflict termination most quickly and efficiently possible. Being pre-emptive is the essence of sound Agile practices. It is not that we should avoid conflict when it is necessary, but endeavour to make the conflict in itself an unnecessary occurrence. Agile lends itself to a collaborative, responsive and collegial atmosphere for teams to operate in.
While we address the issue of obviating conflict, the occurrence of conflict within the various networks in the team cannot be accurately predicted. Hence, conflict mitigation needs to be achieved by planning and foresight. This can be achieved by Agile teams in the following manner:
SHARED VISION AND MISSION
Whether it is creating a brand, working on a design project, or building your organization, creating a shared vision and mission enables everyone on the team to understand the objectives and outcomes clearly. The vision can’t simply be imposed from above. Everyone on the team needs to be enrolled in it.
Create a Team Manifesto
The manifesto is a living document that describes the intentions, motives, and methods within which the team will work. The team works according to the manifesto envisaged. If any part of the manifesto isn’t implementable, the team examines the unworkable parts and modifies the manifest. The important thing is for the team to hold itself accountable to the manifest.
Primacy of Retrospectives
The primacy of feedback and retrospection needs no further elaboration.
Profit in Trust
Operating within the realms of tacit trust is the reason d’être of the Agile mindset. Without implicit trust and explicit collaboration, Agile shall remain an untenable goal.
CONFLICT RESOLUTION
Whatever may be the organisational structure, conflict flash points will occur and will need to be immediately resolved. Such conflict can occur without prior warning. In such cases, team members experiencing conflict, need to be sensitised to the following issues which merit attention:
Highlight Genesis of Conflict: What is the belief and value set of participants in the conflict? What is their perception of the issue being endured? Is there a communications breakdown? Is there a dissent arising out of differences in business priorities? The genesis of such behavioural components needs to be marked and highlighted.
Personality Equations: Only by addressing the psychological standpoint of the parties under dispute can one get to the core of why they are holding on to their position so passionately.
Zones of Agreement: Create zones of agreement where there is a possibility of views being communicated and expressed to help put the conflict in perspective.
Find Creative Avenues: Create avenues where the team and stakeholders can think of new solutions to their conflict through creative media. Standard brainstorming rules apply. Accept all perspectives and negate nothing. Write every idea down without bias. This can lead to a shared solution that has common acceptance and original in creation.
Negotiate for Agreement: Negotiate to find common ground if all other passive forms of persuasion get exhausted.
Enforce Authority: When nothing works, the authority needs to be enforced to arrive at a viable decision. This is necessary when the time is of essence or when reasonable consensus just cannot be reached. Robust Agile teams seldom will need the use of authority to get matters sorted out.
CONCLUSION
Agile facilitates the creation of a psychologically safe and growth enabled cultural environment where everyone feels safe to talk without being coerced, demeaned or rattled. A facilitator or coach who can promote a productive conversation while remaining neutral would be part of the conflict mitigation and termination strategy. Conflicts must be resolved quickly, effectively and fairly lest teams get into the inertia set by never-ending squabbles, low morale and sapping team cohesion and effectiveness. However, it is to be known that the existence of conflict is also a sign of a healthy Agile team. It means that issues continue to be brought to light, groupthink is absent and the team agrees to disagree to all sides of the issue if need be. When no one cares, apathy sets in. When the team takes the time to resolve emerging conflicts, they become proficient at it and can move on to taking on even more significant new challenges, and that is the essence of an effective and efficient Conflict Management Process in place.
