Close enough and far enough: Difference between revisions
Jump to navigation
Jump to search
(Created page with "=Description= 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: #. 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 #. Far e...") |
No edit summary |
||
| (One intermediate revision by the same user not shown) | |||
| Line 3: | Line 3: | ||
While there is no standard recipe, we suggest: | While there is no standard recipe, we suggest: | ||
# | #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 | ||
# | #Far enough not to get entangled in the organisation’s dysfunctions and to work independently to help the Organisation. | ||
# | #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. | 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. | ||
| Line 14: | Line 14: | ||
Evidence/Impact | Evidence/Impact | ||
Here are two examples to highlight the issues: | Here are two examples to highlight the issues: | ||
# | #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! | ||
# | #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. | ||
=Related Principles= | =Related Principles= | ||
Foster a high trust environment | |||
Maximise | * [[Foster a high trust environment]] | ||
Cultivate learning between teams | * [[Maximise engagement]] | ||
* [[Cultivate learning between teams]] | |||
Catalyst for change | * [[Catalyst for change]] | ||
* [[Create a Learning Organisation]] | |||
Create a Learning Organisation | |||
Latest revision as of 22:54, 26 January 2024
Description
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:
- 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
- Far enough not to get entangled in the organisation’s dysfunctions and to work independently to help the Organisation.
- 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.
Rationale
Evidence/Impact Here are two examples to highlight the issues:
- 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!
- 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.