Coaching: Difference between revisions

From go-ELSE
Jump to navigation Jump to search
VisualWikitext
(Created page with "* Single Layer Agile Coaching Close enough and far enough / Connectedness Independence We dream of a world without hierarchies. Yet, in most companies, there are hierarchies. A common question is, therefore, where to connect the Agile Coaching Practice hierarchically in the Organisation. While there is no standard recipe, we suggest: 1. Close enough to the part of the organisation being coached, so they are connected with the organisation they coach and can unders...")
 
No edit summary
Line 1: Line 1:
* [[Single Layer Agile Coaching]]
* [[Single Layer Agile Coaching]]
 
* [[Close enough and far enough]] (a.k.a. Connectedness Independence)
 
Close enough and far enough / Connectedness Independence
We dream of a world without hierarchies. Yet, in most companies, there are hierarchies. A common question is, therefore, where to connect the Agile Coaching Practice hierarchically in the Organisation.
 
While there is no standard recipe, we suggest:
1. Close enough to the part of the organisation being coached, so they are connected with the organisation they coach and can understand the problems they see. However, at the same time, they need to be
2. Far enough not to get entangled in the organisation’s dysfunctions and to work independently to help the Organisation.
3. Organised around value streams.
 
Where to position the Agile Coaching Practice is a balancing act. An excellent place to start is under the VP of Product Development, i.e. in parallel with Product Owners and Developers.
 
A positioning that could also work is under the same Engineering Manager responsible for the Teams. However, the effectiveness of this location depends on the influence this manager has in the Organisation and has often the consequence that the agile transformation is seen as an “engineering thing” rather than an organisational change.
 
Differences at Scale
This question arises only at scale!
 
Evidence/Impact
Here are two examples to highlight the issues:
1. We've seen some cases where the Agile Coaching Practice reports to Human Resources, as they are supposed to work in the whole company. This typically does not work as Human Resources is often seen as very distant from the reality of product development, and, as such, regardless of how helpful the intervention of the coaches are, they are usually discarded as theoretical in favour of the "pragmatism" of the development group. This Agile Coaching Practice is not close enough to the coached organisation to be effective!
2. We've also seen coaches being part of the Team and reporting to a team leader, a Product Owner or some other local manager. This causes the coaches to be too dependent on the daily happenings of that part of the organisation and, as such, forces them to focus on the emergence of the day rather than a long-term strategy of improvement. These coaches are too close and need the advantage point of a more independent positioning in the Organisation.
 
Contending, Balancing and Related Principles
Foster a high trust environment
Maximise Engagement
Cultivate learning between teams
Cultivate an agile culture
Catalyst for change
Involve those affected by change
Create a Learning Organisation




Revision as of 23:51, 26 January 2024


Agile Coaching Pack The Agile Coaching Practice is recommended to work closely together and create synergies to help the company change. One Scrum Master alone cannot change a large company, but a pack of Scrum Masters acting together in a closely coordinated fashion along with the leadership can perform wonders."

The possibility of analysing the issues they see from a systemic perspective, comparing and making sense of what they see from the different vantage points at which they operate, gives them an incredibly effective perception of the company, the critical problems and options for change.

Differences at Scale This is possible only at scale, and this collaboration is the game changer to support agility at scale in an organisation!

Evidence/Impact

Contending, Balancing and Related Principles Cultivate an agile culture Cultivate learning between teams Create a Learning Organisation

Professional Agile Coaching At scale, it is even more important that the Agile Coaches are professionally trained and competent in the various bodies of knowledge related. We expect Agile Coaches to be proficient in - Agile, in general - Scrum - Kanban - Lean, including the Toyota Production System and the Toyota Product Development System - Project Management (while they might not use the ideas of classic project management, they still need to be able to recognise waterfall thinking) - Management theories - Leadership theories - Coaching - Facilitation, Visual Facilitation - Negotiation - Communication - Psychological Safety - Scale Principles - introductory Psychology: motivation, collaboration, goals, ... - ...

Each of these bodies of knowledge is a lifetime study by itself, so obviously, it will not be possible to be excellent in all of them. Still, it is important to stress how helping organisations to change is a long-term commitment to excellence, with a duty to learn continuously.

It is also important to note how there are two primary learning paths: the "technical" one (Agile, Scrum, Lean, ...) and the "human" one (coaching, facilitation, ...) and that a good Agile Coach should strive for a balanced growth between the two paths.

We also expect an Organisation to support the growth of their Agile Coaches, investing heavily in their growth!

Differences at Scale Evidence/Impact Contending, Balancing and Related Principles

Retrieved from ‘https://go-else.org:443/index.php?title=Coaching&oldid=275’