Make Your Coaching Organization Into A Role Model For The Rest Of Your Organization

In their journey, to become more adaptive (agile), organizations need guidance and support.  Ideally, organizations should own their own agile transformations: experiments, decisions, successes and failures, with minimal reliance on external help, especially, from low quality consultants and large consulting companies (see recommended mix below).  What should internal (to a company) agile coaching organization look like? What/who should it include?  Who should lead it?  How should it be executed?

Unfortunately, many organizations, still prefer a “quick fix” approach to solve this problem, by loosely relabeling existing, traditional structures into “agile” structures, or rebranding traditional roles into “agile” roles. For example:  PMO → Agile PMO, senior project managers → enterprise & team agile coaches, junior project managers → Scrum Masters, etc.  This en-masse/big-bang approach, should be avoided.  As Albert Einstein once said: “We can’t solve problems by using the same kind of thinking we used when we created them.”

One general advice to an organization that wants to build its own internal agile coaching structure, is to keep in mind that the rest of an organization will look up to it, as a role model. Therefore, an agile coaching structure should keep its own bar high and practice what it preaches, in terms of having a lean design, effective communication and healthy internal dynamics.

Agile Transformation Group

For the purpose of this writing, an entire agile coaching structure is referred to as Agile Transformation Group (herein, abbreviated, as ATG).  Here are a few recommendations, regarding its purpose/focus, position and structure: 

>>Purpose/Focus:

The main purpose of ATG is to a spearhead organization-wide effort to become more adaptive.  This includes organizational consulting, training/education, coaching and mentoring capabilities that would be made available widely, to various organizational structures and employees.  The main “deliverable” of ATG should be consistent with main optimizing goals (e.g. better competitiveness, increased market share, lowered costs of changes).  ATG may refer to its own deliverable as service, or product, or combination of both, or anything else, as long as the rest of an organization understands ATG’s main purpose and sees value in what is being delivered.

>>Position:

It is critical to position ATG in a way that it receives executive management support, steady funding and operational safety.  Executive management support and funding must not come in spirit-only (e.g. a town-hall announcement: “we support your agile transformation and here is an unlimited budget for you to spend on this new effort”) but rather with direct and intimate involvement, by executive management that is willing to invest its own time in learning and deep system thinking.  Operational safety implies that ATG should not be placed within a traditional organizational structure that historically has not provided a sufficient support to organizational adaptive-ness/agile: PMO, enterprise architecture, etc.  You also want to avoid creating centralized power-towers that impose/enforce agile onto the rest of an organization – this will just lead to “broad & shallow” results, system gaming and resentment.  When building and positioning ATG, please, consider a healthy balance between centralized vs. decentralized approach, balancing between standardizing coaching approaches, tools & techniques and offering autonomy to coaches that are deeply engaged with teams and products.

>>Structure:

ATG should provide a great role model to the rest of your organization, in terms of its design, relationships, communication and dynamics. If ATG’s goal is to help an organization become more nimble, reduce bureaucracy and silos, eliminate contractual relationships (“me vs. you”), promote cross-functional teaming, etc., ATG should be able to demonstrate the same qualities, within its own space.

Lets review an example, when ATG decides to adopt a lean, agile framework, such as Large Scale Scrum (LeSS), used for large-scale, multi-site product development. If such decision is made, it would have to include the following organizational elements in its own design:

• Head of ATG (an equivalent to Head of Product Group in LeSS), whose responsibility would be to provide an overarching organizational support and protection to ATG. Ideally, everyone within ATG would report to Head of ATG, similarly to how everyone (teams and Product Owner) report to Head of Product Group in LeSS.
• ATG Product/Service Owner, whose main responsibility would be to prioritize organizational requests for agile training, consulting, coaching and mentoring support, would be positioned, on par (same level) with teams, and report directly to Head of ATG (similarly, to how Product Owner reports to Head of Product Group in LeSS, mentioned above).
• Teams (self-organized/managed, cross-functional and long-lived), whose responsibility would be to engage with various areas of the rest of an organization, for training, coaching, consulting and mentoring support.
• Communities (informal, horizontal organizational structures), whose main function would be to support and promote functional learning within ATG. Similarly, to LeSS communities, ATG communities would be matrix/hierarchy – free and by-volunteering.

Please, note that ATG should strive to maximize a number of its own people (company’s employees) that uphold positions within a group (and its teams), with minimum reliance on external support.  If external support is used, external helpers should be cherry-picked individually and thoroughly, for their unique capabilities and expertise they bring to a table (for specialties and capabilities, see below), using high standards. Mass-engaging of consultants, individually, through staffing firms or large consulting companies, is strongly unadvisable.

Agile Transformation Team

For the purpose of this writing, each team within ATG is referred as Agile Transformation Team (herein, abbreviated, as ATT).  Here are a few recommendations about its purpose/focus, position and structure:

 >>Purpose/Focus:

The main purpose of ATT would be providing tailored support to various organizational areas, anywhere ATT is deployed. This includes training, consulting, coaching and mentoring to all/any organizational structures: technology, business, operations, support, HR, finance, legal, location strategies, etc. ATT’s activities, length and intensity of engagement, should be explicitly decided prior to engaging.  It, therefore, implies that each ATT would be capable to perform this function independently (see below).

Position:

Multiple ATTs would be a part of the same ATG. If LeSS framework is used as a guideline for ATG structure, then the following LeSS Structure rules would have to be followed for ATT:

• Total of 50-60 (max 70) members within ATG
• 2-8 ATTs per ATG

Note: The above numbers are based on the recommended number of people in Scrum (3-9), and are based on many experiments and research, collected over many years, with the focus on:  quality of communication intra- and  across teams, as well as communication between teams and Product Owner.

Given that the nature of ATT work would be different from what is typically delivered by LeSS teams (software product development), the above ranges, potentially, could be further experimented with: expanded or constrained, as needed.  For example, given that an average ATT size could be noticeably smaller than an average size of a team in LeSS, the range of 2-8 could be widened, experimentally, to keep the overall size of ATG, within the recommended range (50-60).

>>Structure:

Each ATT should consist of members that have multiple, overlapping and complimentary skills, with each person having deep expertise in one of the required domains, and some expertise in one or more additional domains. This approach would be consistent not only with LeSS but also with one-team Scrum.  Below, is the list of skills and capabilities, each ATT should possess, in order to be able to effectively handle any support request from an internal client:

• Ability to engage at all/any phase: organizational assessment, training, consulting, coaching, mentoring
• Possession of knowledge: frameworks, feedback loops, ability to recognize challenges, utilize organizational enablers, leverage agile and scaling/de-scaling principles, metrics
• Competencies: facilitation, education (training), balancing (e.g. between coaching and consulting), assessing (e.g. between discovery and direction), catalysis
• Specialties: organizational structure/culture/leadership, multi-team dynamics, technical excellence, user experience, marketing/sales, business/operations, HR, budgeting/finance, legal, location/site strategies

Note: Please, avoid diluting/reducing the importance of having the highest quality talent, as members of ATT/ATG.  Low quality experts will lead to low quality service, to your organization, and therefore, a loss of reputation, credibility and trust for ATT/ATG. Please, refer to the highest industry standards available (team-level, enterprise-level), when growing your own, internal, ATT/ATG expertise.

Depending on an initial assessment, you may require cross-functional team members, with various complimentary and overlapping skills, as per the above references.  The goal is to make sure that a self-formed & managed, long-lasting ATT, forms a strong relationship with an organization that it supports. Depending on the size of an organization (recipient of support) multiple ATTs may have to be deployed, in parallel: determining this number is a local decision.  All teams should have similar capabilities and skill set – just like in LeSS.

>> Self-Organization

Similar to LeSS, the aspect of self-organization would be critical, when creating effective ATTs, within ATG.  While defining strategic focus and purpose of ATG, consider also defining the most optimal, based on what you know at the time, blueprint for ATT: “what would an ideal team look like, to deliver maximum value to a customer”?  Based on this knowledge ATG may have to do additional tailored staffing.

Please, avoid using a traditional top-down managerial approach to build teams.  Instead, consider conducting a team self-design workshop, by referencing this publication, as a guide.

Engagement Example (Simple Use Case)

For the purpose of this writing, we shall take a look at how the above described LeSS-like ATG and its supporting ATTs, would support an organization that wants to adopt customer-focused, product-centric software development framework – Large Scale Scrum (LeSS). Metaphorically speaking, this situation could be described as: “forging a hammer with a hammer”:

A LeSS adoption (product development, itself), would involve:

• LeSS Product Group
  • 50-60 developers (on average), grouped into 2-8 teams
  • Product Owner (one)
  • Scrum Masters (seasoned, capable of coaching between 1 and 3 teams)
  • “Undone Department” (remaining functions that did not make into the original Definition of Done)
• Users/stakeholders and/or customers, expected to provide a supportive role to LeSS Product Group (details, clarifications)- from a few, to a few dozen people
• Very importantly, executive management, HR, budgeting, legal, etc. – whose overarching support (in action) would be strongly required

As such, and this is based on the advice of multiple seasoned LeSS adoption experts (coaches, trainers), there will be at least one, or more, ATTs needed, to support a LeSS organization.  This would include:

• Educating/advising executive management on organizational design implications of LeSS adoption
• Training/coaching teams and team members on inter-and intra- teams’ dynamics, including LeSS roles, events and artifacts
• Wide gamut of engineering practices: TDD, ATDD, BDD, CI/CD, unit testing, branching/merging strategies, unit testing, test automation, etc.

Conclusion

Please, remember that every organization wishes to see a great role model in the face of its own agile transformation group (referred as ATG, in this writing).  If ATG is lean, nimble, adaptive and has great internal dynamics, then there is a much higher chance that the rest of an organization would be motivated to follow ATG’s footsteps.

But the opposite is also true: if ATG’s structure is cumbersome, bureaucratic, with silos, redundancies and internal competition,  it will not be too successful in its efforts, will eventually lose credibility and reputation with the rest on an organization, and therefore, will not succeed in leading an agile transformation.