Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.
Experience Report by Guest-Blogger Ram Srinivasan
Experience Report by Guest-Blogger Mark Uijen de Kleijn
LeSS Graphic Art
Personal Memorable Moments
Next LeSS conference (2019) – Munich, Germany
- 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.
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.
Some more Kodak moments from the event are below:
- 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.
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.
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:
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:
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
[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.
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 😉
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.
“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:
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 😉.
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).