Category Archives: Behavioral Science

LeSS Talks: July 18: Leveraging LeSS Org Design to Build Competence & Coaching Practice

Materials

Synopsis:
If you want to lead people, be worth following. Erin Perry and JP White will talk about ways to build a transformation leadership team that inspires envy and leads by example in all things. They’ll share techniques that you can use to shape your transformation org, with real examples of teams they’ve built and worked on. Through it all, you’ll see that living agility, through LeSS practices, is not something you tell other people to do; it’s something you lead by example.

Get ready for a candid conversation about transformation, leadership, and integrity with Erin Perry and JP White, Developer Relations specialists.

Relevant reading:

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

In this post:


Introduction:

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.

 

From Maximum Busy-Ness to Maximum Learning, with Esther Derby & Johanna Rothman

Additional Assets:

Questions Asked & Answered
  1. In our organization, there is a lot of emphasis on speed of delivery, efficiency and productivity.  Line managers believe that people work faster and more efficiently, when they are placed on component teams (same skill-set) than when they are placed on feature teams (multiple skills).  What is the best way to convey to our managers that costs and risks of coordination and integration between very fast-moving component teams exceed the benefits of expected speed?
  2. HR norms and values pave the road for heroics and hyper-performance.  Our developers are encouraged to be efficient and fast-moving.  This promotes the ‘I’ culture, as opposed to ‘We’ culture and as such, collaboration and mutual support on teams suffers.  What empirical evidence and education should be provided to HR to stop promoting bad behaviors?
  3. In Large Scale Scrum (LeSS), we are taught to be able to see and hear Local Optimization, everywhere.  There is an illusion that, if everyone stays very busy and moves fast, the system will be moving very fast as well. But frequently, this is not the case.  Are there good coaching tools or techniques to educate senior management that local optimization for speed and efficiency comes at expense of quality, customer satisfaction, etc.?
  4. Today, many job postings still ask for the ability to multitask. This is viewed as a sign of efficiency and proficiency.  This is one of the things that many HR specialists (and managers) still look for. Are there any suggestions on how to manage this expectation, since multitasking and task-switching is not a good idea
  5. Part of my strategy as an SM to encourage self directed teams growth is to give recognition when a member takes ownership “fully” of a task. Do you think this will encourage more “I” culture verses encouraging the team to step up their leadership skills?
  6. In some companies engineers already know that they need to have a SBO (second best offer) to then get counter offers and raise their salary more than say 20% or more. Sometimes when getting that SBO, they actually leave, so this is a big risk. What is the best way to approach HR for them to consider rebalancing compensation to market rates?
  7. Busy people usually are busy for a long time. How much new learning time do they need to start planning in their schedule?
  8. The more I read and learn as an agile coach/Scrum Master, the more I feel at odds with the average manager. Why does this apparent gap about curiosity / emphasis in learning exist? It seems like both roles need to be learning about better ways of working.
  9. How can we evoke a synergy across the organizations to seed the thoughts of Business Agility not just limiting to IT but covering from entry to exit?
  10. What are some specific challenges related to being Remote rather than in office and what are the best strategies to resolve them?

Past events with Johanna Rothman @ LeSS NYC Meetup:

More:

LeSS Talks: May 22: Darwin Theory of Agile Coaching Evolution, with Ron Whitebread



Learn how one company iterated on their coaching approach – from experimentation to big consulting “transformation” to systems thinking enablement (transitioning from being supported by one of Big 5 consultancy companies, with their “push agile” model,  to a reputable, boutique agile coaching and training company) – to become more effective in achieving desired outcomes, what pain points each approach was trying to address, and how to become more relevant to the business side of Agility.

Understand how three different ecosystems played into how our focus and approach kept evolving to fit the prevailing context of that period – the environment, goals, pros/cons and reflection on those outcomes for each approach used.

Ask About LeSS Training & Coaching

01/31 – LeSS Talks: Abusing Metrics for Dummies: How to manipulate data to make us look good?

Today’s  great presentation by Certified LeSS Trainer (CLT) from Israel – Elad Sofer. Please, contact Elad directly for an details.

Materials Used

Main points:
  • Data driven organizations are prone  to abusing metrics
  • The word agile has outgrown itself
  • The Observer Effect: the act of observing something, changes it
  • Metrics measurement: manipulates behavior
  • “Velocity is productivity metric” – against basic understanding of what -healthy organization looks like
  • Political metrics example: Transformation % progress
  • Vanity metrics example: # items that are in “dev done” status (but not tested)
  • Taiichi Ohno: “Don’t look with your eyes, look with your feet. A person who looks only at the numbers is worst of all
  • Example of four (4) metrics that count:
    • Deployment frequency
    • Lead time for changes
    • Time to restore service
    • Changes failure rate
  • Understand the difference between Leading and Lagging Metrics
  • Avoid measuring people: it is inefficient and disrespectful
  • OKR: Narrowing the gap between “O” AND “KR”

Additional Learning Assets:

01/24-LeSS Talks: Experience Report: Navigating Self-Incorporated Consulting (Panel Discussion)

Additional Learning Assets:

LESS TALKS: Uncovering the Agile Mindset, with Heidi Araya and John Turley

 

 Materials

Synopsis:

“Agile transformations fail regularly, despite many putting their best efforts forth. And dominant focus continues to be on agile as a process, addressing the important need for an agile mindset and culture only in passing. While Agilists feel that someone’s mindset is absolutely critical to agility, the agile mindset is not actually defined anywhere. Even Steve Denning, in a May 2020 article, said, “is it possible that we in the Agile community have been putting too much emphasis on such an undefined and ambiguous term [mindset]?”

Additional Learning Assets:

Exposing Invisible Organizational Dynamics w/System Thinking & Modelling @ Agile KC

 

Please note: all system models are conditional and not conclusive.  We model a system to have a conversation.


Upcoming LeSS Training 

Additional recommended assets:

My CEC and CTC Journey

(Re-posted on LinkedIn | Scrum Alliance)

This writing is way past overdue. I have been putting this off for, at least, a few years. But it is better later than never😊.

Today, I would like to share my (this is Gene) personal journey of becoming a Certified Enterprise (CEC) and Team (CTC) coach.

About the Programs

Both of them: CEC and CTC – have been developed by the Scrum Alliance volunteers.  The evolutionary path of both programs has been pretty long and full of experiments.

CEC came first. Some years ago (more than 10), what is called today as Certified Enterprise Coach (CEC), used to be called Certified Scrum Coach (CSC). At one point, the decision was made to rename CSC into CEC, for a variety of reasons, with one (big factor) being that CEC was more descriptive of a coaching focus, since at this level, a person coached not only Scrum but much deeper and broader (organization, enterprise).

But it was not just changing the acronym, it was also a complete redesign of the program.  What used to be a binary pass/fail outcome for an applicant (you submit, you wait for a while, you get a verdict), has evolved into a high-transparency, enriched with short feedback loops, multi-stage, iterative, full of learning and self-discovery, process.  Some time, after CEC has been redesigned (around 2014), there also came CTC (about a year later, or so). The main reason for creating the CTC, as a separate program/credential (NB: I was one of the co-creators but more about this below), was that (multi-) team-level coaches, had somewhere different focus than enterprise coaches: CTCs are were focused on multiple teams, CECs were focused on the whole enterprise.

Some Most Common Misconceptions about CEC and CTC
  1. “…there is no degree or accepted global accreditation that provides comfort around the skills and experience needed for the job…“. Not true. Howard Sublett, Co-CEO/Chief Product Owner of Scrum Alliance explains why this is not an accurate assumption, explaining how CEC and CTC have evolved, over years.
  2. CEC and CTC are just two certification badges that a person get, by simply attending a course and then passing an exam. Not true. Both programs are supported by a comprehensive application process that requires a wide spectrum of qualitative accomplishments: well documented coaching experience, formal and informal coaching education, mentoring experience (mentoring others and being mentored), long agile community engagement and contribution, deep knowledge of coaching tools, techniques and frameworks; as well as, qualitative “know-how”: deep agile knowledge, coaching competencies and mindset.  In a way, both CEC and CTC, remind a dissertation, written by a person who tries to capitalize of a long agile learning journey.  CEC and CTC can be graphically visualized as these little blue figures, on the left side, of this image.
  3. CEC and CTC – is a guarantee to easily secure a job with a significantly higher pay.  Not true.  Although in some countries/by some companies, a lot of emphasis is made on certifications, there is no statistical data to support that CEC or CTC holders have a ‘golden key’ to companies’ doors, while making significantly more money than non-holders.
  4. Once a person obtains CEC or CTC, their learning journey is over. Not true.  In fact, the opposite is true: the best part of the journey begins after a person earns the credential. Many people, consider getting the CEC-CTC credential as a tremendous boost to a personal ego – an ego to learn and further advance, in order to be ahead of others and continue elevating a coaching bar.
  5. Since CEC and CTC application process does not involve a multiple choice test, it is prone to errors and personal bias, by application reviewers. Not true.  Although, a personal perception factor is always present, whenever one human assesses another human, both programs, are very carefully designed to minimize/avoid subjectivity, bias and anchorage, as much as possible (multiple reviewers, calibrated score cards, recusing from review of colleagues/acquaintances etc.).  Check out the above links for details of the process.
My Personal Journey

My journey has begun in 2010, about a year after I received my CSP credential. I applied for Certified Scrum Coach (CSC) – the old version of CEC. I was so confident that I would pass it with flying colors…  Oh boy, was I wrong?  I did not succeed. Looking at back now, I realize that the reason was two-fold:

  • Back then, the process was not too supportive of me, as an applicant. Although I was sure that my reviewers were qualified people (I got to know them in person only years later), the whole process was not transparent and not conducive of iterative learning.  For me, personally, it was not a learning journey.  I had to work on my application in a complete silo, without having any idea if I was on a right track, without getting any guidance along the way. Then, I summited, and had to wait, for about 3 months, before I got the result back: not ready.
  • But to be fair, years later, after becoming CEC, when I reviewed my own, old CSC application, I thought: what a mess it was!  I would not pass myself either: style of writing, clarity of thoughts, ability to present content – they were not up to par with what I would consider today as an enterprise-level coach.  After not passing the original CS, I took the feedback from my reviewers at its face value (not without a disappointment, of course) and decided to let some time go by, before resubmitting.  I wanted to give myself a good chance to advance in my own learning and experience, at my own pace, without having the urge to re-apply fast.  Luckily, I did not feel that I needed a credential to find an employer or a client.  My other hope was that, eventually, the application process would improve, before I applied again.

Four (4), long years went by…

…Many more coaching gigs, many more read books and white papers, attended conferences, retreats and public events, tons of professional networking.  I mentored others and was mentored by more seasoned people. I coached, as a part of my paid job and if someone just needed personal help – I would coach for free, one-on-one.

As an agile coach, I also came to terms with the fact that I am an organizational and team design agent, someone who needs to strive towards changing the ‘world of work’ (also, happens to be the motto of Scrum Alliance), not just coach for the sake of coaching.

In the early part of 2014 I learned that the old CSC program had been redesigned (the effort, spearheaded by Pete Behrens and Roger Brown, who later became my greatest mentors) into the new CEC program and a beta-group of coaches-aspirants-volunteers was required to become the first “explorers” to go through the experiment. Being a huge fan of experiments and having a gut feeling that the time was right, I volunteered immediately.  As I recall it now, I was probably the only “scarred” applicant – someone who had experience with the old CSC program…

To make a long story short…it took me close to five months to go through the program. The hot summer of 2014 – it was me, spending many hours each week, reading, researching, writing and re-writing. From time to time, I would get a feedback or request for clarification from my reviewers. I would then jump on it, research it, study it and take another stab at the google document (by then, the application process was put online). I loved being a Guinea pig 😊.  The amount of additional learning and self-discovery that I made, while working on my own application was just immense. It also felt, as if I almost relived all of my professional experience as a coach (by then I already had many years of coaching behind my belt). Along the way, I collaborated with other applicants, sharing our experiences and bouncing around ideas (of course, everyone’s application was filled out independently).

In October of 2014, I got notified by Scrum Alliance that I was granted the CEC credential. This was one of the most exciting moments in my professional career! It was truly a huge milestone for me. In fact, I was the very first beta-group applicant that made it through the newly redesigned CEC program. It was a triumph.

Benefits After Achieving the Goal (becoming CEC-CTC)

Although CEC never became an automatic “golden key” door-opener for me, earning the credential certainly gave me additional self-confidence and boosted my ego.  I recall being asked by my clients and interviewers what Scrum Alliance *certified* enterprise coach meant and how it was different from “un”-certified. Those moments, were my best opportunities to talk about my professional journey and valuable assets that I bring to the table, as CEC.  Some of my more open-minded clients admitted that what they considered as a ‘coach’ up until then, was not even near what a coach is/does.

Becoming CEC has put me in small group of elite-guide-level professionals with privileged access.  I gained the privilege of joining closed discussion forums with Agile Manifesto co-signers and Scrum co-creators. Seeing them exchange and engage in hot debates, as well as being able to freely engage in any of those discussions on my own, was such a great asset.  At times, just following a thread about Scrum, Kanban, organizational dynamics, scaling, product management, technical excellence, classroom dynamics, business aspect of public training – would enrich my personal knowledge by a factor.

Helping Scrum Alliance to Further Raise the Coaching Bar

Some time, after earning my CEC, I learned that the group of volunteers-CECs was pulled together to create the new Scrum Alliance certification-credential: Certified Team Coach (CTC).  I volunteered myself and joined the group (Roger Brown was the leader).  The purpose of our effort was to delineate between the two types of a coaching focus: enterprise and (multi-)team.  After multiple years of research and discovery, it has become apparent that some coaches wish to focus on teams’ dynamics (e.g. multi-team PBR, multi-team Sprint Planning, Overall Retrospective), whereas others – on enterprise dynamics (HR policies, budgeting-finance, location strategies, vendor management, etc.).  Please note, the above are not mutually exclusive.

Rightfully, some of the quantitative (and to some degree, qualitative) expectations from CEC were higher than those of CTC.  However, just like the CEC, the CTC program was designed to be a very rigorous and challenging selection process, to identify guide-level, senior coaches.

In January of 2018, I also decided to gain my own CTC credential, since there were many instances in my career, when I had to coach at multi-team level.  It also did not feel right for me NOT to have the credential, while being involved in its creation😊.

Today, I run my own mentoring program for people that wish to pursue the CTC or CEC credential.  My focus is three-fold: advanced system thinking → improved coaching capabilities  → application success.

Other Important Milestones during My CEC Journey

One of the biggest aspirations throughout my entire coaching career was becoming a better system thinker-modeler – a person who could see and assess the whole organizational (eco-)system, not just its individual parts.  In enterprise-wide and multi-team settings this skill is a must, at least in my opinion.

Right around the time when l did not succeed with my initial CSC application, I zoomed my focus onto lean and agile product development, at scale and in multi-site settings – something that most of my clients had interest in and trouble with.  My attention was drawn to a series of books, written by Craig Larman and Bas Vodde (both later becoming my other great mentors), where they have covered many guides and experiments that I found very applicable in my work.  Since then, I have applied much of my learning (today, a.k.a. Large Scale Scrum or LeSS), while coaching individuals, teams and organizations.  I find LeSS education a significant asset to my own coaching journey (during and post- receiving the CEC and CTC credentials).  Today, I am one of a few (worldwide) Certified Large Scale Scrum Trainers (CLT) – another very unique and valuable milestone in my career that is also very complimentary to being CEC-CTC.

The above is originally posted on my blog.

More about me and my work.

Coaching Tool/Technique: System Modelling (w/ Causal Loop Diagram – CLD)

 

System Model (high level)
System Model (zoom in)

 

Additional Assets:

Note: System Thinking is used in LeSS training & coaching (team & enterprise).