Category Archives: Training

December 6th-8th: Certified LeSS Practitioner Course With Craig Larman | NYC

Another Large-Scale Scrum Training (CLP), taught by Craig Larman in NYC, is in the CompuBox.

More than thirty people from all-around the globe (North America, South America, Europe) came together for this brain-jelling learning experience! The group consisted of product owners/managers, software engineers, managers and organizational design consultants (scrum masters, coaches and trainers) – people coming from different backgrounds and with a focus on different aspects of organizational agility. What has united them all, however, was their eagerness to learn in-depth about principles of organizational design and implications of Scrum adoption at scale in complex organizational settings.

Course Highlights

With exception of a few rare questions/clarifications, the class spent NO time discussing basic Scrum.  It was implicit (assumed) that everyone in class had strong knowledge and hands-on experience with the basic framework.  On occasions, the topics discussed would bump into “…oh this is not even LeSS-specific; this is just basic Scrum…” but those cases were rare.

Not until day three,is when the class took a deeper dive into LeSS Framework and LeSS-specific events, artifacts, roles…. Why was not it done sooner?   Well…

  • LeSS is Scrum. It is the same very Scrum described by Ken Schwaber and Jeff Sutherland in the Scrum Guide, but done by multiple teams, as they are working together, on the same product, for the same product owner.  LeSS is not “…something that IT does, that is buried in a company’s basement, under many layers of organizational complexity…”. LeSS is an organizational design that uses Scrum (team) as a building block.  Understanding basic Scrum made understanding of LeSS very easy for everyone.
  • The class was made of people that have completed all assigned homework (self-study), before attending. People knew what LeSS picture looks like 😉, when coming in.  Everyone in class was an educated customer.  Importantly: there were no attempts to change LeSS (or change training content 😊  of LeSS), to make it better fit conditions of organizations, where people came from.
  • Spending the first two days on understanding system modelling techniques, differences between causation and correlation (as well as other dynamics) among many system variables, made full understanding of LeSS on day three, come more naturally.

The class learned how to see ‘the whole’/full picture of organizational ecosystem and learned to appreciate why Organizational Design is the first-order Variable that defines System Dynamics (followed by everything else: culture, policies, norms, processes, etc.)

One of my (Gene) biggest take-away points (on the top of an excellent LeSS refresher, from Craig himself), that I plan on using immediately, was the fact from history that was discussed at the beginning of the course (and, sadly, forgotten or known known by many).  And it goes as follows:

…Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with what is known today as ‘Agile Manifesto’, the two contending terms to-be-used were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  ‘Agile’ won because of the reasons that are described here.  Truth be told, because the English meaning of ‘agile’ is not as intuitive is the meaning of ‘adaptive’, today, there is a huge number of fads and terminology overloading/misuse that make the original meaning of agile so diluted and abused…. As it was meant to be: Agile == Adaptive ==Flexible.  We all have to be careful with the meaning of words we use, to avoid this painful irony😉.

Here are some Kodak moments from the event:

How Detailed Should Business Requirements Be? Discovery Through Agile Gaming.

Last week, at New York Scrum User Group (NYSUG) monthly event, co-facilitated by  the agile coaches Dana Pylayeva and Emilie Franchomme, there were multiple agile games presented – all for different purposes and for all types of audience.  Above all, what really stood out was  the “Beautiful Meadow” game that helped with making a revealing discovery about handling business requirements.  Below is the summary:

Game Rules:

Team A and Team B, of 8 people each,  were given the following drawing instructions (click on the image below to enlarge):

Team A Team B

The requirements of Team A were very detailed, whereas the requirements of Team B were rather generic.   Each team was given a set of color markers and a  large flip-chart sheet.  Both teams were allowed to review the requirements in silence – for 30 seconds.  Then both teams were given another 60 seconds to draw a picture, based on given requirements, but they were allowed to collaborate in sign language only.

Observations and Results:

For the first 30 seconds of the exercise both teams’ dynamics were very similar: hurdling around the requirement, trying to understand it, orienting yourselves are around the canvas.   Silently,  some people seemed to volunteer to draw various elements of the picture.  For the second 60 seconds interval, dynamics significantly changed:

At a glace, Team A seemed to be somewhere less organized and more hectic.  People seemed to move around the canvas anxiously, trying to pull markers from each other’s hand.  What also became obvious was that each person was trying maximize their contribution to the picture, by drawing in a silo, without much collaboration with others.

Team B, on the other hand, seemed to be much more organized and focused.  Individual work of each person seemed like a continuity of someone else’s effort.  Markers were effectively passed on from one person to another.  There was much more collaboration and common effort here.

After 60 seconds of drawing, the teams produced two images, illustrated below: Team A  – left canvas, Team B -right canvas (click on the image below to enlarge):

Team A has produced a picture that consisted of multiple disjointed elements that together did not seem to fit well.   Oddly it even produced two suns – in two opposite corners of the canvas, whereas the instructions  clearly asked only for one sun.

On contrary, Team B was able to produce a simple, coherent logical picture, with each element enriching the overall composition with  additional relevant detail.


This exercise clearly demonstrated that too detailed requirements, passed on to a group of individuals, as one conclusive document, are executed much poorer than light requirements  passed on to a similar group of people.  In case of Team B, there was a request of “WHAT” to draw, not “HOW”.  The team was able to use all of this innovation and artistic skills to produce what was required.   Oppositely, team A was asked to delivery “WHAT & HOW” and the teams’ ability improvise on-the-fly was significantly reduced.


There were two sets of teams (two Team A and two Team B) and the results produced by the second set of teams were very similar to the case described above.

Relevant Article: Waterfall Requirements in Agile Product Development

LeSS “Construction”: What is it like?

[also, cross-posted on less. works]

Large Scale Scrum (LeSS).  It is the framework for scaling agile development, done by multiple teams, as they work on same product and work for a single Product Owner.   In order to be effective, LeSS requires organizational descaling that means simplification/flattening of organizational design.

What is Organizational Design?  To understand it better, let’s look for analogy in construction industry.  What is required to erect a building? In our analogy, we shall stay simple: bricks (foundation block) and cement (connective material that holds bricks together).

Imagine two buildings: Building A and Building B.

Building A uses brick as its main foundation block.  In fact, when looking at the building’s facade, the most prevalent object, caught by a naked eye, is a brick.  Bricks are positioned next to one another, with just enough cement in-between to glue them strongly together. There is no excess of cement anywhere: the connection layer is very thin/lean.

Architectural design of building A is simple and flexible: the structure is flat (one-story high) and it sits on strong foundation, also made of brick.   Because of its design, architectural adjustments are possible in various sections of the building, independently, with little additional labor.  Due to such modular structure, the building can be expanded laterally, just by adding more bricks to the wall.  Of course, due to its flat structure, the building is also very stable and can withstand a strong wind, flood or an earthquake: practically nothing can be shaken off or washed off the building.

When waste is produced inside the building, it becomes noticeable immediately. Waste disposal is also very simple: it does not require complex chutes or automated waste ‘packaging’ systems.  Waste removal can be mostly done manually, by building residents.  Any necessary supplies (e.g. food, water, furniture, other materials) can be easily delivered to any building area, without the need of advanced technology or mechanics.

Finally, building inspection and maintenance is a very easy process, because of flat structural design: foundation, walls and floor assessment – all can be performed with a naked eye; corrections can be done timely and efficiently.

This is what building A looks like:

Building B is made of a very few bricks and a lot of cement in-between that holds bricks together. In fact, the ratio (by weight) of bricks-to-cement is very low.

Architectural design of building B is rigid. It has many floors, with top floors made primarily of cement.  The building represents a heavy and monolithic structure, and although it also sits on brick foundation, as building A, the bricks are widely spaced with lots of cement in-between.  This means that the overall weight of building B is dangerously high (foundation can crack).  The building’s expansion limit, to accommodate growing occupancy demands, is low: it cannot be easily extended (scaled) horizontally with a couple of extra bricks added to the side, because the bottom brick layer would require multiple horizontal cement layers added on top – to follow the originally intended building design.  If additional cement layers are added on the top of foundational brick layer this will further increase risks of foundation cracking.

Waste disposal is a serious issue for Building B.  While waste can be relatively easy removed from the bottom floor (it is also not in abundance there) and, to some extent, from top floors (by taking it to the roof and using a waste removal chopper 😊), there is a huge amount of waste that gets accumulated at middle floors – and it sits there.  It is extremely challenging to remove this mid-section waste and what building management does from time to time, is ordering for this waste to be moved from one floor area to another (the building is very compartmentalized).  Sometimes, waste gets moved to floors above; sometimes – below.  This creates an illusion of waste removal. But waste remains.

Delivery of supplies and food to Building B occupants is a real challenge, especially if elevators are out of order.  This makes occupants angry and frustrated and sometimes they turn onto each other; become competitors and rivals.

Finally, building inspection and maintenance is a nightmare for Building B.  Many living units are out of compliance with building codes, but violations (and violators) are hard to identify and remove because true facts are well concealed and numbers are gamed by building occupants.

This is what building B looks like:

Large Scale Scrum requires organizational design that is analogous to the construction represented by Building A.

In LeSS:

Team represents the main building block (a brick). Selected team representatives (developers) and mentors-travelers–ensure effective coordination/connection between teams.  There are no additional roles required for coordination.  Cross-team events are minimal (Overall Product Backlog Refinement, Sprint Review, Overall Retrospective).

If product definition widens and more developers are included, another team can be formed and positioned laterally to existing teams – just like a brick.  Should product definition become too wide and the number of required developers exceeds 50-60 people (8 teams), another product area can be identified (new independent module, made of bricks).  Now, LeSS becomes LeSS Huge.  The only additional coordination that would be required in LeSS Huge is between Area Product owners and Overall Product owner – for strategic planning of Potentially Shippable Product Increment (PSPI) at the end of every sprint.  In both, LeSS expansion from 2 to 8 teams, and LeSS Huge expansion beyond 8 teams, there is no need for additional coordination that is different from what is described above (no extra cement needed to keep bricks together).  Also, in LeSS Huge, when one Product Area expands and another one shrinks, moving the whole team from one area to another, does not require expansion or shrinkage of any additional “supportive” organizational layers.

By design, LeSS foundational structure is very lean: flat, fungible and cross-functional.  There is no waste or overhead with roles, responsibilities, events or artifacts.  Everything is very minimalistic.  If any waste is generated in LeSS, it has practically nowhere to hide.

Because there is so much transparency in LeSS, waste is seen immediately.  Any findings of waste or any other required improvements to individual teams or LeSS framework, can be effectively done in Team Retrospective or Overall Retrospective, respectively.  Thanks to its flat organizational structure, LeSS (and LeSS Huge) don’t have to worry about waste removal from additional organizational layers – they [layers] just don’t exist.   There are fewer layers that sit between LeSS teams and LeSS Product Owners and these layers are much thinner.

What happens with LeSS organizational structure during rough times: slow down in business, increased market competition? Arguably, because LeSS is so lean and there is continuous learning, it is much less likely that LeSS people will be displaced. LeSS is also more likely to withstand other types of reorgs and shake-ups because LeSS has very few moving parts, loose pieces or weak links.

Organizational designers that support LeSS think like building architects that want to build strong, reliable, easily-maintainable, low-waste, cost-effective and long-lasting structures!!!

Many thanks to all LeSS Trainers, Coaches and Practitioners building reliable structures 😉.

Signed: ____________The Organizational Building Management 😉

You Get What you Ask For: Agile Coaches-“Centaurs”

Why are there so many troubled agile “transformations”?  We frequently hear the following answer: “because companies lack senior leadership support”.  True.  And let’s not trivialize this: without strong and genuine support by senior leadership (beyond slogans and “support in spirit”), without selecting a deep, systemic approach to problem resolution, companies can only expect localized, peripheral and, most likely, short-term improvements.

But is there anything/anyone else that can be conveniently held accountable for failed agile transformations?

How about ineffective agile training and coaching?  [Note: If you are interested in learning more about some of the most common challenges with agile training, please visit this page.  This post is about coaching .]

…There is a vicious cycle that hurts so many companies (can be also considered as a self-inflicted wound):

initially, companies set a low bar for coaches, based on poor understanding of a coaching role  low quality coaches (quasi-coaches-“centaurs”) are hired, most of whom are not even coaches, but rather people that have mastered agile jargon and know how to impress HR and uninformed hiring managers  weak coaches (most of whom have minds of conformists, not challengers) cannot effectively guide companies to fix systemic weaknesses and dysfunctions  teams and departments  don’t really improve; rather create a superficial appearance/illusion of progress (often, to impress senior management)  companies lose faith and stop seeing value in coaching → companies start trivializing a coaching role  companies decide not to spend more money on high quality coaching cheaper, even less effective, coaches are hired (or internal, misplaced people are refurbished into coaches, overnight, as per Larman’s Law # 4) initially, low-set coaching bar, is lowered even further…and so on….

Graphically, it looks something like this:

As a result, what was initially meant as a strategic organization- improvement effort, now takes on a form of just another system-gaming change management fad that ultimately leads to a failure and responsibility/blame-shifting.

What are some of the reasons why the above happens?  Here are some suggested reasons:

  • Companies don’t understand the essence of agile coaching role: it is viewed as another “turn-on switch” management function
  • Leadership does not feel a sense of urgency (p. 14) to make changes and exempts itself from being coached: people are too busy and too senior to be coached; they find coaching trivial
  • Certain organizational pockets are genuinely resistant to/feared of changes that can be brought about by real coaches (as per Larman’s Laws 1 – 3)
  • Market over-saturation with unskilled recruiters that hunt for low-quality coaches and contribute to the above cycle: this further lowers a company’s chances to find a good coach
  • This list can be extended….

Who is responsible for initiating this vicious cyclic dysfunction?  Does it really matter if we identify guilty ones?  Maybe it does, but only, as a lessons-learning exercise.  What probably matters more is how to break out of this cycle.  Where to start: discontinue low-quality supply (coaches) or raise a bar on demand (by companies)?  Usually, demand drives supply and if so, for as long as companies remain complacent and reliant on outlived staffing/head-hunting approaches, cold-calling techniques, and ineffective HR-screening processes, performed by people that poorly understand the essence of an agile coaching profession, while trying to procure cheap “agile” resources or treat seasoned professional coaches, as “requisitions to be filled”,  a coaching bar will remain low, and companies will be getting EXACTLY  what they have paid for: coaches-centaurs (p.17).

Big question

What should companies be looking for when hiring a coach?”

An organization should be looking much father and beyond of what is typically presented in a resume or a public profile of a candidate: usually, a chronological list of an employment history or a long list of google-able terms & definitions,  popular jargon or claims of experience in resolving deep, systemic organizational challenges with Jira configurations 😊.  Much more attention should be paid to the following important quantitative characteristics of a coach:

Coaching Focus: What is an approach and/or philosophy to coaching does a coach have?  This will help a company understand an individual mindset of a coach.

Coaching Education AND Mentorship: What active journey through education, mentorship and collaborative learning in coaching and related activities over significant period has a coach taken?

Formal Coaching Education: What has contributed significantly to a person’s coaching journey, including courses on topics of facilitation, leadership, consulting, coaching, process, and other related activities which have influenced a person’s coaching practice? Such education may not have to be degree-related (training and/or certification from any recognized institution could be sufficient).

Coaching Mentorship & Collaboration: How a coach developed a skill/technique or received guidance to a coaching approach and mindset?  Respect and recognition of mentors – matters here.

Informal Coaching Learning: What important topics outside of Agile/Scrum literature have impacted a person’s coaching philosophy?  This increases chances that a coach is well-rounded, beyond standardized book learning.

Agile Community Engagement & Leadership:  Does a coach engage in agile user groups, gatherings, retreats, camps, conferences, as well as writing, publishing, reviewing, presenting, facilitating, training, mentoring, organizing, and leading agile events?  An active participation and leadership in the agile community is a good demonstration that a coach has not developed herself within a unique organizational silo, by self-proclaiming and self-promoting, but rather has diverse and ‘tested’  industry experience.

Agile Community Collaborative Mentoring & Advisory: Does a coach mentor or advise other individuals (not for pay) on how to increase their competency or development?  Is a relationship on-going, purposeful and bi-directionally educational?

Coaching Tools, Techniques and Frameworks: Does a coach develop awareness and understanding of tools, techniques and frameworks while engaging with organizations?  Has she customized or developed anything that was client/engagement-specific?

In addition to quantitative characteristics , here are qualitative characteristics of a good coach:

Coaching Mindset
  • How does a coach react when an outcome of coaching was different from what she had desired? In the past, how did a coach address this situation?
  • How, based on clients’ needs, a coaching mindset had to change? In the past, what compromises did a coach make? What was learned?
  • What new techniques or skills did a coach learn, to meet a client’s needs?
Coaching Competencies
  • Assess – Discovery & Direction
  • Balance – Coaching & Consulting
  • Catalyze – Leadership & Organizations
  • Facilitate – Focus & Alignment
  • Educate – Awareness & Understanding
Coaching Specialties
  • Lean / Kanban
  • User Experience / Design
  • Scaling Agile / Enterprise Agility
  • Technical / Quality Practices
  • Organizational Structures
  • Lean Startup
  • Product / Portfolio Management
  • Organizational Culture
  • Learning Organizations
  • Non-Software Application
  • Business Value / Agility
  • Technical / Product Research
  • Multi-Team Dynamics
  • Organizational Leadership
  • Organizational Change

[Note: The above, is based on guidelines provided by Scrum Alliance application process for CTC and CEC.]

While running some risk of sounding self-serving (very much NOT! the intent here) : please, be mindful and responsible when you select guidance-level professionals in your agile journey 😉.

Bad Choice of Verbs Associated with “Agile”, by EFL People

These days, almost everyone knows that organizations cannot “do” agile; they can “be” agile.  And today, this contrast is used not just by agile coaches and scrum masters.   Everyone likes building this fancy figure of speech in their daily lexicon: managers, analysts, developers.  Great!!!  Below is a snippet from Wikipedia, defining the word “agility“, using the most natural reference:  a human body.

From reading the definition, it appears that body agility is equivalent to a body fitness/health.  And if so,  it would be fair to assume that when we talk about organizational agility, we also talk about organizations, being fit and healthy (organizational fitness/health). Just like a body cannot “do fit” or “do healthy”, organizations cannot “do fit” or “do healthy”.

But while wrongfulness of “doing agile” is mostly admitted today, there are many examples of using other sophisticated synonyms of “doing” that hint to the fact that people are still NOT clear about what “agile” is.

As the title of this post suggests, and this is where the biggest irony comes from,  the most advanced EFL people (EFL = English First Language 😉) have been making the most noticeable language omissions, while attaching “sophisticated/fancy corporate terms-verbs” (other than “do”) to the word “agile”.

Below, is the list of verbs that are not advisable to be used in conjunction with the word “agile”:

  • “Implement Agile”
  • “Adopt Agile”
  • “Use Agile”
  • “Introduce Agile”
  • “Accept Agile”
  • “Follow Agile”
  • “Move TO  Agile”
  • “Transition TO Agile”
  • “Transform TO Agile”
  • “Install Agile”
  • “Administer Agile”
  • “Leverage Agile”
  • “Upgrade to Agile”
  • “Practice Agile”
  • “Establish Agile”
  • “Experiment Agile”
  • “Standardize Agile”
  • “Execute Agile”

Question: So, what can be done to protect yourself and your organization from a misuse of the above jargon? 

Lets turn our attention to history….

Back in 2001, at Snowbird, UT, where the group of seventeen entrepreneurs-product-developers have met and came up with, what is known today as ‘Agile Manifesto’, the two contending terms-to-be-used, were adaptive (suggested by Jim Highsmith, the author of Adaptive Software Development) and agile (suggested by Mike Beedle).  

‘Agile’ won because of the reasons that are documented here

So, truth be told, because the English meaning of ‘agile’ is not as intuitive as the meaning of ‘adaptive’, today, there is a huge number of fad/jargon and terminology overloading/misuse that make the original meaning of agile so diluted and abused.  

As it was meant originally: Agile == Adaptive ==Flexible.   So, here is a great litmus test, if a the word “agile” is being used correctly: can it be seamlessly substituted with its synonym “flexible”, without losing a meaning?  (Ironically, being “flexible” is also an indicator of being healthy, physiologically, as well as organizationally).

05/26-28: Scrum Coaching Retreat | Kiev, Ukraine

2017 Scrum Coaching Retreat in Kiev  is in the books!!!  The event has brought together a few dozens of agile coaches and trainers from nearby and far away.

The participants came from different backgrounds and focus areas but due to everyone’s extensive experience in self-organization and self-management, got the show on the road very quickly.  After a short round of self-intros, each participant introduced a few topics that they wanted to discuss. By using a combination of dot-voting and affinity clustering techniques, the group came up with a handful of key topics that everyone wanted to deep dive into.  The group broke up into four teams, with each team picking one high-priority topic – to be worked on in consecutive three (3) sprints.

The team I joined (“Happy 7”) picked up the topic “How to influence decisions of senior management directly, from the bottom of organizational pyramid”.  The team consisted of experienced ScrumMasters, Team-level and Enterprise-level coaches.

The problem statement that defined our team’s effort was:

“There are so many instances, of challenges and obstacles that teams face, are not being heard at the top of a food chain.  And even when they are heard, often, original messages get distorted and lose urgency, as they travel up through multiple “translational” layers.  What can be done to fix this problem?  What techniques could be used to effectively segregate impediments that are local and can be resolved by teams and the ones that are systemic/organizational – and must be aggressively escalated upward?” 

The problem above has direct dependency on organizational design, specifically, on its thickness: the number of organizational layers between working teams (on one hand) and senior leadership/paying customers (on the other) – is a well-recognized challenge today.

Our working group has identified the following organizational design scenarios that define dynamics and human interaction in modern Product Development:

  1. Development teams and Product Owner belong to the same organization and end-Customer is positioned internally
  2. Development teams and Product Owner belong to the same organization and end-Customer is positioned externally
  3. Development teams represent Vendor-company and Product Owner represents Client-company and relationships between Vendor and Client are based on:
    • Out-staffing model – when a vendor provides human assets (developers) that are then owned by a customer, from management perspective, whereas legal ownership (e.g. insurance, taxes) is still by a vendor
    • Out-sourcing model – when an entire project gets outsourced to a vendor and a paying customer has no or minimal interaction directly with human assets (developers) that do work (most of communication flows through Engagement Management)

Interestingly, since many of our working group members had a lot of experience with #3 option above, the primary focus of our discussion was about how to bring closer senior leadership of paying customers and agile teams of delivering vendors, closer together, despite multiple “anti-agile” organizational layers that frequently reside in-between the former and the latter.

The ultimate result of our brainstorming was the invention of a non-commercial, collaborative game that was given the name of Influence Poker.

Our game’s purpose was:

  • To identify challenges that delivery teams often face
  • To classify challenges, based on origin, severity and implications
  • To discuss potential ways of resolving and/or escalating challenges
  • To ensure resolution ownership and transparency on its progress

Note: The initial contributors to the game creation were: Serhiy Lvov, Kiryl Baranoshnik, Artem Bykovets, Alexander Karitsky, Mark Summers, Jonas Mann and Gene Gendel .

The most serious organizational design challenge, when a paying customer engages with a vendor-company, is seen with an out-sourcing model.  Here, no matter how agile/robust technology teams are, their ability to deliver effectively is hindered by:

  • Involvement of Delivery Manager (usually, placed on a client site) who owns a relationship with a customer, serves as a single filter-channel of communication between a customer and teams, makes commitments and furnishes progress reporting on behalf of teams. The same person also streamlines feedback from a customer back to teams and frequently assigns work to team members.  This is usually accompanied by micro-management and command and control behavior.  The situation can be further worsened by the presence of Vendor Management function (customer side) that enforces SLAs, SOWs and other formal contracts between a customer and vendor: this just adds additional tension to a relationship and moves further apart end-customers and delivery teams.
  • Weakening of Product Owner role – the importance of this critical Scrum role gets downplayed, because a customer company no longer sees value in direct communication with technology teams.  Instead, Delivery Manager is treated as a single person, responsible for project delivery.  This dramatically narrows all communication media that are used in Scrum (holding events, sharing artifacts).

The above two challenges are inter-related through a positive feedback loop: the less disengaged Product Owner becomes, the more pivotal the role of Delivery Manager becomes.  The opposite is true too: strengthening the role of Delivery Manager, leads to further “excusing” Product Owner from stepping into the game, as Scrum requires.  This is a viscous, de-stabilizing loop that continuously weakens Scrum.

Please, look out for the Influence Poker.first official release that is coming soon! It may greatly help your teams visualize their organizational problems and discover potential workable solutions.

Note: For attendees and participants, here are additional shortcuts:

Are there better ways to teach?

Whether you are a high school teacher, a college professor or professional training instructor you probably always look for ways to increase value you bring to a classroom and some of the questions you might be asking yourself are:  “how to enrich students’ in-class experience?”, “how to ensure information retention by students?” and “how t make in-class learning more applicable to real life?”.  This summary focuses on the following three aspects of teaching: dynamic teaching, teaching focus, feedback loop between teachers and students.


Dynamic Teaching

Every instructor must have a set of Learning Objective, based on which, training content is built.  Meeting these objectives deems a training successful.  But there are different schools of thought about educational learning:

Bloom’s Taxonomy classification model for educational learning (created by Dr. B. Bloom in 1956) implies that human thinking goes through six evolutionary (maturity) stages that, if were mapped to Japanese martial art concept of SHU-HA-RI that describes the stages of learning to mastery, would approximately group-by as follows: SHU (Remembering, Understanding, Applying) = “traditional wisdom”, HA (Analyzing, Evaluating) = “breaking with tradition”, RI (Creating) = “transcendence”.  With this thinking approach, to proceed to a next level of maturity, a person must pass through preceding levels.  This type of learning is hierarchical/sequential and uni-dimensional.

An alternative, and more dynamic, taxonomy of leaning has been proposed by L. Dee Fink of University of Oklahoma, in his The Power of Course Design to Increase Student Engagement and Learning.  With this new thinking approach, instead of looking at learning as a hierarchical and sequential journey, we treat it as multi-dimensional process, where each dimension is independent and can interact/overlap with other dimensions, in a Venn-like style.  The following are learning dimensions (categories) proposed by Fink: Foundational knowledge, Application, Integration, Human dimension, Caring, Learning How to Learn.

All categories are independent of one another and within each category, students can advance to different degree of maturity.   Within each of the categories, there could be a critical minimum of learning objectives that must be met by all students – this is something that is decided by an instructor.  Beyond this critical minimum, learning remains dynamic and conditional and is based on an instructor’s assessment of in-class dynamics (may vary from audience to audience).


Teaching Focus

Truth be told, in comprehensive multi-session courses (e.g. college or university), where a professor has enough ‘runway’ to build-up her audience for more advanced topics, there is a relatively low risk of short-cutting/by-passing basics, in favor of practical learning.

On the other hand, in short, time-boxed professional training (e.g. a few hours or a few days) there is a higher chance that foundation learning could be shortened by an instructor, in favor of topics that appear (only superficially) to have a more direct real-life relevance.  In short training engagements, due to time constrains and a desire to jam as much information as possible in a session, we see these sacrifices primarily made because:

  • Instructors are pressured to deliver “maximum practical value for a buck” by their sponsors
  • Students attend against their will, with superficial goals to “rent” an instructor’s immediate solutions, instead of learning how to find their own
  • Certain “hot” topics that challenge current organizational values and norms are omitted, to avoid inflaming discussions

A good example of teaching focus loss would be an agile training by an agile consultant, where a class immediately focuses on their day-to-day problems and “best” practices (e.g. metrics, tools, techniques and workflows), instead of learning agile values first (e.g. human interactions, relationships, mindset, collaboration, compensation etc.). [More information about typical challenges with agile training]

By short-cutting to immediate practical implementations and offering ready-to-use “unwrap & install” solutions, trainers significantly reduce students’ chances of retaining learning, developing autonomy and capability of creating and owning their own decisions (as opposed to “renting” from instructor).

Instead of working from outside-in (as per the diagram above), instructors should strive leading students from inside-out, by ensuring that students understand core values first, then build new principles upon values, and only then proceed to developing their own practices.

Teaching Feedback Loop

In 2014, in his “Don’t give me Feedback”, Tobias Mayer described how any type of direct feedback, whether positive or negative, is a judgment made by the giver on the receiver.   Being a judgment call, feedback is always subjective and is anchored to a giver’s personal and self-centered views and ambitions.  Here is an example from a typical agile training:

A positive feedback that is full of compliments, excitement and affirmation could mean that a student learned in class how her role will become more empowered, thanks to overarching organizational changes.  This is a great reason to “celebrate” and give positive feedback to an instructor, even though the class itself was not so great! Another reason for a positive feedback could be that a student is trying to build a good relationship with an instructor, for future “at-work” interaction and “special treatment” or with a hope that an instructor will provide her own positive feedback to students’ superiors.

On the other hand, a negative feedback and criticism (this type of passive aggressiveness is sometimes seen in anonymous feedback forms) could mean that a student learned in class about something that will affect his personal daily work in ways that are not desirable by a student (e.g. required additional learning, loss of control or authority).  So, while learning itself is deep and clear, an individual’s conclusions about personal consequences may lead to negative emotions and mental resistance- thus, a negative feedback.

According to Tobias, a much better way to receive feedback from a classroom, would be by simple Observation.  Instead of soliciting students’ feedback directly, an instructor should pay a lot of attention to in-class participation and interaction: student-to-instructor exchange, student-to-student exchange, questions posed by and answers offered by students, students’ desire to look for workable solutions that are acceptable by everyone, etc.  A good way to increase objectivity of observation would be to re-shuffle students during training, to re-create new working groups, and see if in-class dynamics change, subsequently, as well.

Another big advantage of learning by observing is that it allows for an immediate adjustment of actions by an instructor, and re-applying changes made back to the same group of students, without making it too obvious for students.  For example, if an instructor sees one of students being completely disengaged, she can ask a student to change to another table or request him answer a question posed by another student.

To summarize, in this day and age, with so much information becoming a free commodity available on internet, unidirectional and “scripted” in-class teaching is becoming less and less effective. On the other hand, dynamic and interactive teaching, reinforced by short feedback loops between a teacher and students, will be setting high standards in future learning.



2017 Big Apple Scrum Day: Coaching Clinic

The Third Annual BASD (2017) event is in the books.  27 people have been served by the coaches, whose cumulative experience and depth of knowledge were just immense.  Many thanks to Zuzka Sochova, Kim Brainard, Bob Galen, David Liebman and Jim York for making this happen.  This event had the largest every presence of Certified Enterprise Coaches (CEC).

Below is the summary of quotes from the people that attended the Coaching Clinic:

  • “Awesome session. Wealth of knowledge.”
  • “Pleasant convo. Vague question but got some interesting answers.”
  • “Bob helped me with several concerns I had. He broke things down and emphasized the importance of always looking at things with a whole team approach. Will use feedback.”
  • “Dave: – great shaking, -good advice, – will use immediately.”
    “Very helpful and informative, It is always good to learn other perspectives”
  • “Great insight and way to look at personal issues.”
  • “Dave game me some good marketing advice about marketing myself”
  • “Bob listened, provided valuable feedback and helped me walk out with actionable items. Thank you!”
  • “David – useful suggestion.”
  • “Refreshing and very pragmatic session.   Great advice and specific to my exact topic.”
  • “Awesome coaching from Kim. Look forward to taking her feedback to work.”
  • “Practical & useful talk about Scrum roles with development team (PO & SM).”
  • “Great feedback from Dave. Great advice about how to run meetings and to get work done.”
  • “Great pointers to look for next steps. Good and honest advice. Informative discussion.”
  • “Got coaching from Jim on rolling out agile more broadly. Jim was really helpful and got us to the heart of where we should focus. Thank you!”
  • “Dave shared personal experiences that helped me identify possible resolutions to my problem. Very clearly followed the steps from the coaching stance. Got definite actions to try.”
  • “Great advice for retros from Kim.”
  • “Had a session with Jim about career path and my goals. He was extremely helpful. Listened to my concerns and helped with ideas.”
  • “Great therapy session! Was able to get real life examples in the feedback.”
  • “Meeting with Jim was worth every nano-second. He reset my thinking about focus but more importantly, my intention with short-term and long-term goals — but especially humility. Excellent!”

Agile Flyer – 04-09-2017



Public Announcement:
Scrum Alliance® Announces Partnership with LeSS Company


Denver, CO,— SCRUM ALLIANCE® – The news are finally out and public: On 4/7/2017, Scrum Alliance interim CEO Lisa Hershman, has announced that Scrum Alliance,
most established and influential professional membership organization and certifying body in the Agile community,entered in partnership with LeSS Company to support widespread adoption of Large-Scale Scrum (LeSS).

-Read the entire press release…

Join your local LeSS communities today.

Applying LeSS Thinking to Basic Scrum
“LeSS Hexagon of Values”

As per Scrum Guide, “…Scrum is a framework for developing and sustaining complex products…
It [Scrum] is lightweight, easy to understand and difficult to master”.
The guide talks about basic Scrum, or Scrum by one cross-functional team that works for only one Product Owner, on one single product.
The guide also mentions situations when multiple Scrum teams must work on the same product backlog and share the same Definition of Done (DoD) – an example of scrum scaling.

Large-Scale Scrum (LeSS), on the other hand, is a product development framework that extends Scrum with scaling rules and guidelines, without losing the original purposes of Scrum.…”.
Some of the hallmarks of LeSS are:

  • It is the framework that requires organizational de-scaling (simplification), to scale basic Scrum
  • It is the framework that strongly relies on effectiveness of organizational design and system dynamics of multiple organizational layers, departments and spheres of control
  • It is not merely a group of teams doing their own Scrum, while working for different product owners and supporting different products.
    Rather, it is a group of teams (2-8) that works together, synchronously, on the same product and serves the same product owner.

-Read more…


More Selected Periodicals:
Unspoken Agile Topics

This paper, originally written in February 2013, brings to light some of the least-discussed topics and consequences of “broadband agilization” that currently take place in the industry.
The materials of this paper are subdivided into two general sections:

  • The first section describes certain impacts that Agile has on individuals and their personal career advancements.
  • The second section describes organizational-level Agile impacts that pertain more to client companies that undergo Agile transformation,
    as well as service-providing vendor companies that deliver Agile-transforming expertise to their respective clients.

-Read more…

Be an Educated Consumer

You just bought a house and decided to renovate. You brought in a contractor to estimate the work that you want done. What is your biggest fear? Here are a few possibilities:

  • The work will not be done.
  • The work will not be done on time (winter is coming and you need wall insulation before it gets cold).
  • The work will be done on time but it will cost you much more than you can afford and more than this job really costs.
  • The contractor is charging you more than he should; he is taking advantage of your ignorance.
  • The quality of the work will be poor but, unfortunately, you will not know this until all of it is finished and you have to move in (after you pay in full).

-Read more…

Fresh Collection of Ad-hoc Agile References:

I continuously collect articles and publications that come from everywhere: colleagues, coaches and trainers, clients, occasional encounters.
I keep a comprehensive list of resources here, categorized by themes.
Some of my most recent samples from the collection are below:


Connect with a Certified Coach for Online Coaching!
(re-published from Scrum Alliance newsletter)


Challenges with Agile Training: Examples, Reasons, Consequences

Virtual networks of professional agile coaches and trainers is good place to pick up some most thoughtful and provocative agile discussions.  The most reputable networks that I know of, and happen to belong to, are the communities of: Certified Enterprise Coaches and Certified Scrum Trainers (both, from Scrum Alliance), and Candidate Large Scale Scrum Trainers and Coaches (both, from LeSS company).  These communities are great because there we continuously  share our experiences and learn from one another.

The summary below is the result of one such in-network discussions that spans in duration for more the a year. It is focused on in-class training experiences and highlights  – some of the most common challenges that we encounter with our students in pre-, in- and post-classroom situations.  Some of our observations are specific to internal classes, some – to public and some – to both.

Below, are some of the common challenges with Agile Training that we face:

Training “Wrong” Attendees with “Wrong” Intentions

At times, we get training attendees that have never held agile roles (e.g. ScrumMaster, Product Owner, Team member), … nor did they ever have an intention to do so.
While agile education is recommended at all organizational levels and for all horizontal structures (perhaps, with different focus, depending on audience), what is sometimes observed is that certain types of individuals show no signs of desire to truly understand to further implement newly-learned agile principles. Instead, their true desire, seems to be, in understanding agility concepts just enough to be able to figure out a way of creating “anti-dote” against them.  Typically, this is seen with individuals that are concerned with their own role security (not to be confused with job security) as it frequently gets challenged in agile and lean organizations (includes processes, tools and roles).

This situation is rather difficult to control in public classes, where any individual who pays a fee, can attend.  However, it can be (and should be) much easier to control with internal training. By requesting class attendees to come in ‘clusters’, as hands-on technical teams that share work already, accompanied by their respective business counterparts, trainers can ensure that right people are gathered together in the same classroom, at the same table, for shared learning, collaboration, and simulation exercises.  This is the most effective way to ensure that in-class learning will retain its momentum, when people go back to their work areas and start implementing newly gained knowledge in practice.
It is important to note that for any trainer who is planning to engage with trainees for a longer period of time and coach them, it would be especially important to have right people in the room during training – together.

Training “Certification Collectors”

It is not uncommon to see individuals that come to training with the main goal to add another trendy certification to their collection.  This is mainly fueled by job market demands, as hiring companies create job requisitions and look for a “soup of certifications”, sometimes, asking for most awkward and, sometimes, conflicting combinations.  For example: “A candidate must have CSM, PMP, PMI-ACP, SAFe, PRINCE2, etc”.  Most of such jobs are usually poorly described and contain erroneous statements about actual role expectations.

This situation has been observed much more frequently in public training courses, where individuals pay their own money to attend.  Less so, this has been observed with internal training, where students do not pay their own money to attend (nor do they get certified). As such, their eagerness to maximize ROI from attending aa class is much lower.

Also, as a side-effect of this unfortunate pattern, blind pursuit of certifications by non-practitioners who don’t have any intentions to put their learning to practical use,  also dilutes meaningfulness of certifications in the market and adds even more confusion to hiring companies.

Influence of Past Quasi-Agile Experience or Misguidance

Some individuals come to training after prior “agile theater” experience.  Please note that in this post, the emphasis is made on specific cases, when prior agile exposure was of low quality and had created confusion or conflict with new learning.

Bad agile experience may come in various forms.  For example, poor agile implementation “on the job”-  often due to a complete lack of training and misguidance by management.  Another example would be previous low-quality/misleading agile training that was delivered by unqualified guides.  The adverse effects of these types of wobbly foundations are observed equally frequently with public and private training.

It is worth mentioning some well-known sources of unqualified guidance:

  • Vendor companies that lack internal agile expertise or track record of teaching.  Historically, such companies have done mostly staffing/recruiting or management consulting of some sort and just recently decided to step into ‘agile arena’ in pursuit of additional revenue (pretty common these days).  Such companies “get lucky” when their is long-standing clients pull their names off a preferred vendor list and ask to fulfill agile staffing needs.  Usually, hiring companies that use this approach get exactly what they paid for :).
  • Internal employees that have been promoted/fast-tracked into trainers or coaches to fulfill a growing internal company demand for agile guidance.  Such individuals, most of whom do not have any prior field experience as coaches or trainers, are too restrained to existing organizational norms and standards: they are not reformists and challengers by mindset; they are conformists and executioners. Thus, in classroom settings, they present “by the book”, at rudimentary level and steer their followers towards “…this is how things are done around here…lets conform our Scrum to constraints of our organizational design and our internal best practices…”.  Such agile guides are not very effective in handling out-of-the-box situations or addressing serious inquiries that require deep understanding of organizational design and system dynamics.

Internal agile trainers that have been more successful in their work than their peers, usually position themselves in a way that they have, first and foremost, ensured their own security and operational safety that is required to drive organizational changes from within. Secondly, such individuals also have a very strong connection with external professional circles of trainers and coaches, though which they explore horizons of their learning beyond boundaries of a single organization and continuously hone their craft as trainers and coaches.

Lack of Pre-Training (Self-Study)

Almost any trainer will appreciate having in her class well-informed students (a.k.a. “educated consumers”) that have done recommended preparatory self-study before attending training.  Self-study helps normalizing basic understanding of concepts and level-setting students’ expectations from in-class learning.  It also, potentially, reduces the amount of basic, rudimentary questions that unprepared students often ask in class: about terminology, conventional abbreviations, jargon, etc.  By spending less time on explaining basic book definitions, an instructor can spend more time on collaborative activities, role-playing, discussing real-life simulations and doing practical exercises.  This case of low preparedness is more frequently seen with internal training, where a company sponsors an event (even, when an external trainer is hired from outside, employees don’t pay from pocket) or training is totally free (done by an internal trainer).  Just like in the situation described above, students’ desire to maximize ROI is lower than in public training, where people invest their own time and money to attend.

Attempts to Change Training Content to “Conform to Reality”
  • “Is it possible to shorten our training from 2 days to a few hours?”
  • “Can we conduct training just for IT people, since it is hard to justify to our business partners why they need to be away from their desks for a few days?”
  • “Can we conduct training just for business people, since our IT people are already well-trained in agile, “doing stand-ups” and using Jira/Rally to track time spent 🙂 on tasks and they see no value in going through another training, alongside with business?”
  • “Can we review training materials upfront, to make sure that we don’t waste any time on topics that are not relevant to us and ensure that we conform to our existing organizational reality (philosophy, norms, rules)?”

These types of requests are almost unique for internal training arrangements.  Frequently, they come from first- and mid-level managers that get their marching orders to “do agile” (a.k.a. “support-in-spirit”) from senior leadership, and while orders are given, the empowerment to make sure that things are done properly– is not there.  Such corner-cutting and artificial scope reduction has its own reasons. Here are some of them:

Sometimes, agile training is perceived by both: attendees and their managers – as an easy way of meeting personal objectives in order to receive good performance appraisals (when students are asked in class why they are there, they frequently respond that “…it is in our personal development plan and our management wants us to do it, because everyone else is doing it…”.  [Author’s irony: “if everyone was jumping off the roof would you do the same?”].  There is no clear understanding, purpose, vision or goal.  There is no clear strategy on how to put new learning to work, after attending classroom training.

There are other times, when attempts to change training content are caused by a desire to circumvent or avoid sensitive topics that could be perceived by some as politically-incorrect implications of organizational dysfunction.  For example, topics about harm of performance appraisals and monetary rewards, weaknesses of conventional budgeting, inappropriateness of old methods to procure for agile roles (e.g. product managers, T-shaped developers or agile/technical coaches), ineffectiveness of waterfall requirements in agile product development, shifting control and responsibilities form first-line management to teams, etc.).  In these situations, agile training might be reduced to a discussion of “best practices” (agile tooling, metrics collection, agile status reporting, etc.) or reviewing some sort of an internal agile guide for best practices that usually comes in a form collection of publicly available, commoditized (internet) information.  On the other hand, there are situations, when internal agile training turns into a battle field between people, whose hidden friction and conflicts of interest become more obvious because of agile topics and associated  with them transparency.

Attempts to Steer Training Content towards “Unique Situations”

Somewhere like the above, this case of uniqueness is more frequently seen with public training, where people come from different companies and pay for training out of their own pocket.  While their intentions to get “more bang for buck” are good and well understood, sometimes, methods are not.  There are instances, when students attempt to steer discussions towards their unique situations at work, by frequently interjecting with inappropriate comments or asking an instructor to reflect, in real-time, on their personal work experiences.  If this happens too frequently, it becomes disruptive for other students and reduces effectiveness of basic learning for everyone.  It becomes a trainer’s responsibility to ensure that special cases and real life scenarios are reviewed at appropriate times, preferably, with participation of other students, in team break-out sessions (could be also facilitated by a trainer).  Such cases of uniqueness are not as frequently observed with internal training because there is much less variance in situations within the same company.

Requests for Exemption from Training by “Special” People

There is a fundamental difference between support- in-spirit (a.k.a lip service) and true, genuine hands-on involvement and support-by-action (a.k.a. gemba).  Unsurprisingly, there is a shared belief among organizational coaches that: “…a coach can take an organization in its agile journey only as far as an organizational leader is willing to go…”.  It is imperative that senior leadership that is behind agile transformation is well informed and educated.  While content of agile education for senior leadership (executive training and coaching) may differ from content taught to feature teams, ScrumMasters and Product Owners, it must be delivered as the earliest phase of transformation, to prepare seniors for inevitable organizational changes: structurally, culturally, processes -, norms – and values-wise.

Unfortunately, there are many cases when senior leaders excuse themselves from agile education.  They delegate this critical activity to more junior people beneath.  Soon, this leads to misalignment and disconnection between teams that are trying to implement agile changes and senior leadership that is trying  to effectively support the effort, but cannot – due to lack of understanding of systemic and organizational implications.

It is a rarity to see senior leadership attending public training – they just find it too difficult to allocate time for this external activity.  With internal training, things are somewhere better, but not by much.  On occasions, senior leaders will attend initial part of agile training, and try to motivate their subordinates by personal example.  While it is somewhere useful to create initial momentum, it is not sufficient.  As a rule of thumb, having a senior leader sit though an entire experience of in-class learning that includes collaboration, system modeling and practical exercises, alongside with a feature team developer or product owner, is extremely rare. As a result of this, leaders leave with superficial knowledge and limited understanding of what their teams will be experiencing on practice.

Lack of Classroom Participation

In public training, it is hard to attribute lack of students’ participation to any specific cause; it is rather situational. Factors may vary from student’s disinterest in a topic (e.g. a person attends only for certification, as described above) to an instructor’s inability to effectively engage with a class, …to anything in-between.

With internal training, however, the situation is slightly different.  Here, in addition to a wide array of factors, suggested above, there is an additional important factor of individual safety.  Existing organizational structures (e.g. reporting lines, chain of command, seniority) may seriously influence in-class environment and dynamics.  Junior folks may feel unsafe and act submissively to others, whose seniority is higher, either by reporting structure or by experience.  It is not uncommon to see first-line managers and team leads attending internal training, alongside with their subordinates and more junior co-workers, and dominating in classroom by trying to set a pace and tone.  What sometimes worsens a situation even further is that, inexperienced internal agile instructors that are also a part of the same organizational structure, are not able (or not willing) to control in-class dynamics to ensure safe and democratic participation by students: they lack their own personal safety and hesitate to put a hard stop to misbehavior of empowered bullies.

Too Much Reliance on Training Materials

This is probably one of the most difficult paradigms that is hard to break: there is often so much reliance on documentation that goes as far as violating the second postulate of Agile Manifesto.  Most commonly, this is seen in internal training, at companies that mostly rely on their internal ambitions and self-confidence to become agile. When it comes to internal communication or information sharing, employees are accustomed to lengthy, “high-density”, corporate-style presentation decks.  They carry this experience into agile training, where now it becomes their expectation of what agile training materials should look like: they look for lengthy pages of instructions and execution plans.

Speaking of training materials, it is relatively easy to distinguish training materials of a professional trainer and materials produced by an internal agile champion, who has little experience in the field.  In the former case, materials are usually light in verbiage, more illustrative, graphical and entertaining; they mainly serve as conversation enabler and a “pacer” for an instructor.    In the latter case, materials are very data-dense, fine-printed and require intensive reading.   Unsurprisingly, when students attempt to follow pages of heavy presentations, they disengage from their classmates and instructor.  This further reduces learning and information retention.  This is also a primary reason why there is so much reliance on slides post-training.  Students mistakenly believe that what has been presented on slides is a prescriptive set of executable instructions.  Upon exiting “deck-driven” training, people end up ‘renting’ decisions that were suggested on slides, instead of deriving and owing their own decisions.  Instead of leaning more towards experimenting, inspecting and adapting, people look for directive guidance and “best practices” from a trainer (whose experience might be also questionable).

A few classic erroneous requests that thrown at internal trainers:

  • “Can we review training materials upfront so we can evaluate relevance of training to how we work today, so we can decide if we should come?”
  • “Can we be excused from training but review training materials instead to get up to speed?”
  • “Can training materials be finalized and standardized across all current and future training for all teams?”
  • “Would it be OK if we joined via audio or video bridge and closely followed training slides, instead of attending in person?”

What some people also don’t realize is that today, the best training/educational information is an absolute commodity and it is freely available on the internet.  Today, a heavy training deck has practically no intrinsic value because it is, most likely, a digest of books and articles created by others with a lot of copy-pasting involved (often, plagiary).  From a standpoint of a professional trainer or coach: if someone is looking for so much reliance on training materials and execution scripts, they may just purchase a really great agile book and read it on their own, instead of coming to class.


Challenges with training (both public and internal) may cause further downstream adverse effects, beyond classroom:

  • For public training, this may potentially lead to bad reputation of a trainer or give undesirable publicity to his/her course value
  • For internal training, especially in situations, where it is followed by longer term coaching (could be also done by the same person that delivered training if he possesses coaching skills), this may lead to inability to effectively assist a team in their agile journey.