Category Archives: Training

May 30th-June 1st: Certified LeSS Practitioner Course With Craig Larman | NYC

Another LeSS Training (CLP) with Craig Larman is in the CompuBox.  This highly engaging training brought together 35 attendees from all over the globe.  One of the attendees was Chet Hendrikson.  A bit about Chet:
Chet has been involved with Agile Software Development since 1996 and is the first signatory to the Agile Manifesto. Along with his long-time friend and colleague Ron Jeffries, Chet has made the following important contributions to the global agile community:
  • Wrote Extreme Programming Installed (also with Ann Anderson)
    In 2009, developed for Scrum Alliance the Certified Scrum Developer program
  • Taught the first Certified Scrum Developer (CSD) course
  • Have been curating the Scrum Alliance’s Agile Atlas website
  • Created the SA’s official Scrum description, Core Scrum
  • Speak at conferences, bringing an interesting mix of humor and deep knowledge, and the odd cat picture.

This is what Chet had to say about the course:

“Chet Went to Craig’s LeSS Course”

Many years ago, I wrote an article entitled “Inside every 100-person project is a 10-person project trying to get out.”  That pretty much sums up my feelings about Agile at scale.

My interests have always been with the programmers and their safety and not with how to “Agilize” the organization.  Some of this was a reaction to the failure of most Agile transformations.
But, as someone deeply rooted in the Agile movement, I feel it is important to pay some attention to the “scaling” end of things.  A couple of years ago,  Ron Jeffries and I took (most) of the four-day Implementing SAFe course.  You can read about that at https://ronjeffries.com/xprog/articles/safe-good-but-not-good-enough/.
I have also been paying attention to Craig Larman and Bas Vodde’s Large Scale Scrum (Less).  So, when I saw that Craig was teaching a LeSS Practitioner course in New York on a week I was not working, I signed up.
There were a couple of reasons for me to take some time away from my wife and cats to do this.  First, after having read the LeSS books, I wanted to learn more.  And, secondly, I have always enjoyed my interactions with Craig and wanted to spend some more time with him.
The course is three full days, 8:30 to 6:00, and involves a great deal of hands on work.  And, I do mean work.
Craigs starts the class by saying that “you won’t successfully be able to return to your workplace and ‘give a summary’ of your insights; it is futile & won’t be understood.”
He is right about this.  But I will try and give you my impressions of the course.
One of the key takeaways from the course is something I already believed, which is don’t scale.  Do everything possible to build your product with one time.  If that is not enough, find ways of descaling your problem.  Only if that fails take the steps required to turn your organization into one that can build large products with Scrum.  Doing this effectively will require many changes.  Most of which are about removing management and simplifying information flows.

Craig’s organizing principle for the course is that in order to successfully use these ideas,  you must own them.  Having an instructor, no matter how good they are, no matter the depth of their experience, teach you something is no where as good as discovering the answers yourself.  To this end, we spent most the the course learning and practicing organizational modeling to derive the practices and structures that align with our goals.

In the course, our goals where to create a learning organization that has the ability to “turn on a dime for a dime.”  You may have other goals, but these tools will help better align with them no matter what they are.
Only on the afternoon of the last day did we turn to a full discussion of LeSS.  This was very insightful and was a fitting way to close out the course.
If you are interested in Scrum at scale, I highly recommend  this course.  If you are interested in bringing your organization into sync with its goals, then this is the place to start.

 

Some more Kodak moments from the event are below:






 

 

 

 

 

 

Centralized vs. Decentralized Coaching

Key Takeaways

Read the original post on InfoQ.

  •  There is a frequently seen confusion with respect to the definition of agile coaching: coaching focus (e.g. enterprise vs. team) is confused with coaching alignment (centralized vs. decentralized) within an organization
  • Centralized coaching departments run the risk of turning into a single-specialty organizational silos that are locally optimized for their own expansion and personal success; they are also removed from real action. The reasoning behind: standardization – has its weaknesses.
  • Centralized coaching is often limited to being “responsible for introducing KPIs, documentation of script-style-one-size-fits-all best practices and cookie-cutting approaches”.  This leads to system gaming by other departments and organizational silos that must “meet numbers goals”
  • Centralized Agile coaching makes sense only when it takes place within an organization that is small enough to be effectively managed front-to-back (including its all organizational layers)  and is genuinely supportive of its own coaches, by providing them with “organizational immunity” and operational safety – to enable them perform their challenging duties
  • The main advantage of decentralized coaching approach is that coaches are close to real action: deeply engaged with products/services, and are intimately engaged with senior leadership.  Decentralized coaching is deep & narrow (as opposed to being broad and shallow) and takes time to cause meaningful and sustainable organizational changes.

Read the original post on InfoQ.

2018 BIG APPLE SCRUM DAY: COACHING CLINIC

2018 Big Apple Scrum Day (BASD)  is in the Copy Box.   This was another amazing  annual event, organized by BASD team of volunteers.

The agile coaches-clinicians serviced more than 30 attendees, by addressing a variety of questions and concerns.  While some of the discussion topics were similar to the prior years’ clinics, there was a noticeable increase in maturity of topics.  My personal (Gene is here) unique experience was with the folks that wanted to discuss:

  • Implementing Scrum in non-IT area, where software engineering aspect is not present (mainly, graphic design, content management)
  • Engaging HR of financial/investment companies in discussions about organizational agility (incentives, bonuses, performance)
  • Using Scrum and “Team of Teams” concept in government projects/contracts in the areas of US Military and Defense (the discussion was conducted with someone who had personal, first-hand combat experience in Iraq).

The following coaches have provided their personal feedback:

From Peter Green: I love coaching clinic. For me, it is a bite-size, speed dating version of agile coaching: It’s has a short timebox and both parties tend to feel good about the outcome of the session. Even though it is micro-coaching, over and over we are able to generate some good insights, ideas, or new approaches that have the client excited and optimistic.  Today at the Big Apple Scrum Day, I coached a handful of people with questions ranging from how to better help individuals and teams to how to get upper management engaged in Agile adoption. If you are familiar with the various competencies involved in professional coaching, you would observe that these quick sessions tend to lean a bit more toward teaching and mentoring than a typical, long-term coaching relationship. But that’s great! People are encountering challenges for the first time that many of us grizzled vets have seen many times, and so we can give them some insight into patterns that we’ve seen work and the context that made those patterns useful. But, it’s not all advice; in two or three sessions today, I had a chance to do more “pure” professional coaching, where it wasn’t me sharing ideas or suggestions, but asking open access questions and making observations about body language and tone.
From Jim York:  I always enjoy the comraderie of my fellow coaches at the Coaches Clinics and getting to meet the people who come to chat for a 15 minute coaching session. This year’s Coaches Clinic at Big Apple Scrum Day in New York City continued the tradition. While every clinic is different based on who shows up, there are two clear constants. One is the coaches’ earnest desire to help people with the next leg of their Scrum journey. The second is the energy of the attendees in seeking a way forward.Everyone’s Scrum journey is unique and that is what makes coaching such an interesting vocation. Certainly there are patterns — well worn paths that many have trodden in the search for improvement — but these paths crisscross, double back, circle around, and blend in innumerable ways.  For me, this year’s coaching topics ranged from estimation (what a can of worms that one can be!), how to get started with agile, how to improve team focus and accountability when the team is distributed, and variations on how to be a better coach or trainer for the team and the organization.   Read more….
From Amitai Schleier:  I had a great time at last year’s Big Apple Scrum Day presenting with Ryan Ripley in my home market, so it was an honor to be invited back to contribute to the 2018 BASD proceedings in a new way: as part of the Coaches Clinic, where attendees could talk through a situation they’re facing and, in so doing, perhaps gain some new understanding or insight.  These conversations, while brief, can have profound impact. Five years ago, my first visit to a Coaches Clinic transmuted my curiosity about a career option into the resolve to try it. And here we are.  Yesterday, I don’t think I came close to doing for anyone what Roger did for me. But I did make myself useful, reasoning about the needs of the people in Matt’s situation until we found an actionable idea. Gene Gendel, who organized the Clinic, is collecting experience reports from the coaches.  Despite the prevalence of Lego in Agile coaching games and simulations, I still hadn’t played with it much since childhood. I guess I decided to start practicing because Taavi will be Lego-ready before we know it. I tried to stay off the grid.  It was energizing to punctuate the pace of the one-day conference by visiting with friends — especially Joanne Perold and Barry Tandy, who I’d met online via Agile for Humans, and now in person, all the way from South Africa. I also got a kick out of rubberducking my code problem with Doc Norton, though we ran out of time to pair on it. (Jo and Doc both keynoted.).  Read more….
From Mariya BreyterStart with Why Agile community is well known for transparency, supportiveness, and generous knowledge sharing – after all, this is what Agile is about. This is one of the reasons I volunteered for the Coaching Clinic. Having previously coached at BASD as well as the Lean Startup Conference, I expected to meet new people, support them in their exciting challenges and opportunities, and share my experience of nine enterprise-level transformations I was part of – and all of this happened, and much more. Gene Gendel who runs BASD coaching clinic since the first conference four years ago, made every coach and coachee (I am told there is no such word so I made it up 😊) feel welcome and comfortable. Anyone could sign up for any slot for anyone or for a specific coach, and there were always coaches available in the clinic area to answer any questions or to have a friendly chat with participants. It was a great opportunity to meet other coaches who are all great professionals well known in the field, and many of them are good friends since the first BASD. Everyone who came over for coaching was super nice, generous and grateful – thank you all for making this Clinic a success! Now about the specifics.  Read more….
From Aleksandr Kizhner: BASD2018 conference to me is where my mindset meets action, and this was another excellent conference. Being part of the awesome team of agile coaches – clinicians I’ve struggled with how to condense all my positive experiences into a few bullets point feedback; this may have to be the first of many. Over just one day, I was able to create new connections, engage people in enlightening coaching sessions, and start a number of thought-provoking conversations with other agile coaches.

Few of my sessions focused on the importance of the team culture and surprisingly less on the health of the product backlog, user stories, and technical agile concepts. Many emphases were placed on relationships and trust between team members instead of the typical command and control and process quality assurance that found in traditional software development processes. One of the main benefits I took from being at a coaching clinic, I was being able to meet and network with other people who were going through their own organizational agile transformation. There were a lot of lessons learned shared and views on how to best proceed. 

 

Some Kodak Moments:

Our worksheets:

From left to right: Peter Green, Gene Gendel, Jeff Patton

Scrum Alliance Education specialist Alexxis Holquin:

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.

Conclusion:

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.

Disclaimer:

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.