Category Archives: Kanban

May 19-22: Global Scrum Alliance Gathering | AUS-TX

An amazing 2019 Global Scrum Alliance Gathering (May 19-22), organized by SA staff that brought together a record-high number of professionals from around the globe and had countless amazing events – too many to describe them all in one newsletter. 🙂
Here, I would like to  recap what committed to my memory the most:
  • Keynote presentation by Daniel Pink
  • My personal experience from servicing the ‘Fans of LeSS’ booth, attended by hundreds of people
  • Highlights of my own presentation that draw more than 100 people: “How to Stop Deterioration of Coaching Quality: Industrially and Organizationally” and feedback from the room
  • Coaches Clinic and Coaches/Trainers Retreat highlights 

Keynote Presentation by Daniel H. Pink

During his keynote presentation, Daniel H. Pink (the best-selling author, contributing editor and co-executive producer, known world-wide) shared the highlights of his new book: The Scientific Secrets of Perfect Timing.

Pink’s Synopsis: “We all know that timing is everything. Trouble is, we don’t know much about timing itself. Our business and professional lives present a never-ending stream of ‘when’ decisions. But we make them based on intuition and guesswork. Timing, we believe, is an art.  But timing is a really a science – one we can use to make smarter decisions, enhance our productivity, and boost the performance of our organizations.

Some highlights from Pink’s talk:

Scientifically and statistically, both humans and apes, have the lowest well-being at mid-life.

Therefore, D.Pink’s recommendation on how to deal with such unpleasant mid-points, are as follows:

  • Beware [of such mid-points]
  • Use midpoints to wake up rather than roll over
  • Imagine you’re a little behind

Then, D. Pink also stressed that there are hidden patterns of how time-of-day affects our analytic and creative capabilities – and how simple work rearrangements can improve our effectiveness. For example, when a person makes an appointment to a physician, it is best to ask for a morning time slot, instead of afternoon slot, since physicians tend to have more analytical capabilities before lunch.

D. Pink’s next point was that as individuals get older, at the end of each decade, they are more prone to take certain actions that psychologically make them feel younger. As an example, he used statistical data of marathon runners: people are most likely to run their first marathon at the ages that are just at the brink of next decade: e.g. 29 or 49 years old.

“Because the approach of a new decade… functions as a marker of progress through the life span…people are more apt to evaluate their lives as a chronological decade ends, than they are at other times.”- Daniel H. Pink
How about psychological reaction to the fact that something will be GONE and the time when it will happen is coming up shortly?

In one case study (left image), when a person was given one chocolate candy at a time, and was asked to give feedback about its taste, a response was usually consistent, for each subsequent candy. However, as soon as a person was told that it was the last candy to taste, feedback about how a candy tasted became significantly more positive.

In another case study (right image), when a group of people was asked to fill out a survey, in order to receive a certificate, before it expired, responses were different, when conditions were set as “will expire in 3 weeks” vs. “will expire in two months”.  Apparently, proximity of expiration date made people much more responsive to the request to fill out a survey.

D.Pink’s next point was about how half-time checks can shape our behavior and impact final results. According to D. Pink, scientists and researchers really like statistical data from sports because it is ‘clean’.  Here, using an example of basketball teams, when teams play a game, the following can be observed, depending on half-time results:

  • Being significantly behind – usually results in a loss
  • Being significantly ahead – usually results in a victory
  • Being slightly behind – motivates people to step up and put an extra effort, which results ultimate victory
  • Being slightly ahead – makes people relaxed, less focused and less persuasive, which results in ultimate loss

As such, there is a conclusion:

“Being slightly behind (at half-time) significantly increases a team’s chance of winning” –D.Pink

Fans of LeSS Corner
A small group of Certified Scrum Trainers and Certified Enterprise-Team Coaches, supported the Large Scale Scrum (LeSS booth):  Fans of LeSS.

At least a few hundred people has come by the booth, asking for information about LeSS.
The booth servants received the following three biggest take-away points:

  • Unfortunately, still not too many people are aware of LeSS.  This is not to be confused with attempts or successes of adoption.  Rather, this is about general knowledge of what LeSS is. Ironically, the booth was labeled “Area 51” – the world’s best kept secret :).
  • Once being explained what LeSS is, how simple and common-sense it is, for many people, it has become an ‘AHA’ moment. The most awakening moment was understanding the difference between ‘global and local optimization’, ‘deep and narrow, as opposed to broad and shallow’, ‘owning vs. renting’.
  • Amazingly, how many people shared the same, almost standard complain/pain-point: “… we are currently using a very complicated, monolithic and cumbersome process (usually referring to some widely marketed XYZe framework), with multiple organizational layers involved,… and it creates lots of overhead, waste and friction,… practically nothing has changed in our workplace since the time we adopted it…same people, same duties and responsibilities (practically) BUT different terms, labels and roles … We really don’t like what we have to deal with now and our senior management is also frustrated but it seems that there is really nothing we can do to fix it at the moment…“.

“How to Stop Deterioration of Agile Coaching Quality: Organizationally, Industrially?” (my own presentation)

The goal of my presentation (Gene is here) was to discuss with the audience:

  • What is the problems’ origin [as it is derived from the title]?
  • Examples of the problem’s manifestation?
  • How can we solve the problem?

Throughout the course of my presentation I:

  • Exposed some classic systemic dysfunctions that sit upstream to the problem in scope.
  • Gave some examples of the problem, by using cartoons and satire
  • Delineated between the problem aspects, coming from outside organizations vs. siting on inside
  • Described types of internal (organizational) coaching structures that are to be avoided vs. tried
  • Gave some suggestions on what to avoid vs. what to look for in a good coach
  • Gave additional recommendations to companies, coaching-opportunity seekers and companies’ internal recruiters

“Download Presentation as PDF”


…and a some additional highlights from the gathering….
The Coaches Clinic – for 3 days
This traditional ‘free service’ by Scrum Alliance Enterprise and Team coaches and trainers what at the highest ever: 300 people were served in total,  over  course  of  3 consecutive days.


Certified Enterprise & Team Coaches and Scrum Trainers Retreat – Day 0:

This year brought together the biggest ever number of CECs-CTCs and CSTs.  One of the most important themes that was elaborated: how important it is for guide-level agile experts (CECs, CTCs, CSTs) to unite together in a joint effort to change the world of work.

Note: Thanks to Daniel Gullo (CST-CEC), who generously created for each attending Certified Enterprise Coach – colleague a memorable gift: Coach’s Coin with The Coach’s Creed:

  • CARITAS: Charity, giving back, helping others
  • COMMUNITAS: Fostering community and interaction
  • CONSILIARIUM: Counseling, consulting, The art of coaching
2020 Global Scrum Alliance Gathering is in NEW YORK(registration is not open yet)

Sept 13 -14 | 3rd Global LeSS Conference | NYC


Unforgettable 2 days at the 3rd Global LeSS Conference, at Angel Orensanz Foundation – the historical landmark in NYC.


Conference Space and Our People
Experience Report by Guest-Blogger Ram Srinivasan

Though I have been associated with the Large Scale scrum (LeSS) community for about five years (though the “community” did not exist,  I can think of my association with like minded folks) this is my first LeSS conference. While I used to attend a lot of conferences in the past, I have started focusing more on deep learning (by attending focused workshops) than focusing on conferences. But this year, I had to make an exception for the LeSS conference Why (a) it was the first LeSS conference in North America  (b) It was not very far and (c) I was thinking that I might meet some of the smartest people in the LeSS community whom I may not meet otherwise and (d) I have heard that it is a “team based” conference (unlike other conferences where you are on your own) and I wanted to find out what the heck it was. I was not disappointed.

The venue itself was very different from the conventional Agile conferences  – not a hotel. That definitely caught my attention !! I was pleasantly suprirsed to see both Howard Sublet (the new Chief Product Owner from Scrum Alliance) and Eric Engelmann  (the Chairman of the Board of Director of Scrum Alliance ).  Howard and I had good discussions on LeSS, Scrum Alliance, the marketplace, and scaling
Some sessions that I attended and major takeaways:
  • Day 1 morning keynote –  Nokia LTE  implementation  – Takeaway – Yes, you can do Scrum with more than 5000 engineers
  • Day 2 keynote  by Craig Larman. I always find Craig’s thinking fascinating and learnt quite a few interesting facts about cognitive biases (and strategies to overcome them).
  • LeSS Games – component team and feature team simulation lead by Pierluigi Pugliese – very interesting simulation – I used a variation of this in my CSM class past weekend and people liked it. I hope to write about sometime, in the coming days
  • LeSS roles exercise by Michael James –  I have always been a fan of MJ. Very interesting exercise which reinforces the concept of LeSS roles
  • TDD in a flip chart – Guess I was there again, with MJ. Well, just learned that you do not need a computer to learn about TDD.
  • An open space session with Howard Sublett on LeSS and Scrum Alliance partnership (yours truly was the scribe) – Lot of interesting discussions on market, strategy, and positioning of the LeSS brand.  I personally got some insights from Rafael Sabbagh and Viktor Grgic.
Two days was short !! Time flew away.  It was a great experience !! And  I wish we could have a North American LeSS conference every year !!

Experience Report by Guest-Blogger Mark Uijen de Kleijn

I’ve attended the 2018 LeSS Conference- my first – in the Angela Orensanz Center in New York. I was really inspired by the many great speakers, experiments and experiences and was glad I could help Jurgen de Smet by his workshop on Management 3.0 practices that can complement LeSS with experiments.

A couple of notes on the Conference; it has been the first Conference I attended in years where I actually learned a lot, either from the many speakers, experiments and experiences, but from my ‘team’ as well. As the LeSS Conference is a team-based conference, we reflected on the content and our insights during the Conference, which accelerated my learnings.

As I use many games and practices in organizations or courses, I’ve seen several great new games that I can use myself. The ‘building agile structures’ game of Tomasz Wykowski and Justyna Wykowska was the most outstanding game for me, because it makes the differences between component and feature teams very clear when scaling work, and I will use this for sure in the future. The experiences at Nokia by Tero Peltola were very inspiring and especially the focus on the competences (of everybody) and technical excellence I will take with me.Thoughts that will stick with me the most after the conference: the focus on technical excellence (including e.g. automation, code quality, engineering practices etc.) and the importance of the structure of the organization, following Larman’s fifth law ‘Culture follows structure’. The latter I’m already familiar with, but needs to be reprioritized in my mind again. The former will be my main learning goal the coming period and I will need to dust off my former experiences.

Interesting quote to think about, by Bas Vodde: ‘we should maximize dependencies between teams’ (to increase collaboration between teams).


Games and Team Activities

LeSS Graphic Art


My partner in crime (Ari Tikka) and me  – Presenting on Coaching

Click here to download presentation: Ari’s deck | Gene’s deck.


Personal Memorable Moments


Next LeSS conference (2019) – Munich, Germany

Agile Flyer – 03-25-2017

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 private 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
  • Training “Certification Collectors“
  • Influence of Past Quasi-Agile Experience or Misguidance
  • Lack of Pre-Training (Self-Study)
  • Attempts to Change Training Content to “Conform to Reality”
  • Attempts to Steer Training Content towards “Unique Situations”
  • Requests for Exemption from Training by “Special” People
  • Lack of Classroom Participation
  • Too Much Reliance on Training Materials

-Read more…

 


More Selected Periodicals:

Scrum and Kanban at the Enterprise and Team Levels

Scrum, as the most structured of all Agile frameworks, is a great way to ensure predictable, strategically planned, incremental product delivery.
Scrum ensures good responsiveness to frequently changing market demands.
Although nonprescriptive, Scrum clearly defines certain roles, responsibilities, and ceremonies.

Kanban, for the most part, is silent about certain aspects that Scrum suggests explicitly (e.g., team size, velocity, story point estimation, timeboxing,
Scrum ceremonies, etc.). Kanban is less structured than Scrum. Being a true pull-based system,
Kanban is a great work-flow visualization tool that can be effectively used for WIP management.
It is a great tool to use in production support or the gradual redesign of legacy systems; business priority-driven new product development
is not the main goal….

-Read more…


Motivation 3.0 Is Required to Transition from Tribe Stage 3 to 4

In his book Drive, Daniel Pink says that when it comes to motivation, there’s a gap between what science knows and what business does.
Our current business operating system is built around external, carrot-and-stick motivators — which don’t work and often do more harm than good.
We need a system upgrade. And the science shows the way.

This new approach has three essential elements:

  1. Autonomy: The desire to direct our own lives
  2. Mastery: The urge to make progress and get better at something that matters
  3. Purpose: The yearning to do what we do in the service of something larger than ourselves

-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:

 

Agile Flyer – 02-05-2017

 


Unspoken Agile Topics

/re-printed from its original version/
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.

The reader will most likely focus on the section that best represents his primary interests and concerns.
However, it is recommended that both sections are read in full, as in unison they create a better holistic perspective of the industry changes brought about by Agile-mania.
Read more…


Mentoring Coaches
(New Virtual Mentoring Program)

“How can credible, guide-level agile professionals that have sufficient amount of experience and a proven track record in coaching and leadership make themselves stand out?”
Read more…

Agile Self-Assessment Maturity Matrix
(…or how people self-reflect on their agile journey…)

A few weeks ago, I had a pleasure attending Scrum @ Scale course, taught by Jeff Sutherland.  One of the in-class exercises that spanned across the entire duration of the class was having students make an assessment of their respective organizations, in various dimensions of agile maturity,
as they were discussed in class. The areas covered are displayed in image (below), in the left column.  The dimensions of agile maturity discussed were: Prioritization, Delivery, Refactoring, Continuous Improvement, Strategic Vision, Release Planning, Release Management, Feedback loops, Metrics/Transparency and others.
To “grade” (assess) the state of maturity for any given dimension, people used a grading legend (right image below).
Post-it notes of different color were used to make graphic illustration more visual.  It was pretty revealing to see so much orange color on the wall – indicative of situations with partial blockage/impediments.



(The next Scrum @ Scale course taught by Jeff Sutherland is on March 2-3, in Boston, MA.)

More upcoming Agile Events in NYC:

Agile Flyer – 01-08-2017

 


Kicking off 2017….

Non-IT Kanban Implementation at Scale

/re-circulating my older post/

A few days ago, I went to the happy hour of a local staffing firm that specializes in placing Agile technical and leading resources.
They had moved in to their new office and were treating (I’ve known these guys for a number of years and was not looking for a job).
As I was walking around the office, what caught my eye were a few huge whiteboards attached to the walls.
One of the boards was in the recruiting area, another one in the account-opening area. I moved closer to see what was on them.

Both boards had multiple columns and rows. I focused on the column headers of one of the boards.
Most of the columns looked like sequential steps of one long process: resume submission of a job seeker to a client company.
I took a closer look at the other board and, after a few minutes of interpreting its column headers, realized that the board represented the steps in the account-opening process.
The boards did not seem to be related and they seemed to be maintained by different teams — one by recruiting, another one by account opening.
I looked around for a few more minutes and then asked the regional director to validate my observations and assumptions.

This is what I found out: – Read more…

More upcoming Agile Events in NYC:

July 7 – LeSS Talks: Framing a perspective: LeSS, Nexus, Scrum @ Scale, SAFe

This event was about comparing and contrasting the following four known scaled agile frameworks:

The discussion was very engaging but conclusive and many topics remained to-be-discussed in a future.

Below, please find the post by one of the participants and contributors at the meetup: Sevina Sultanova:


sel_sulScaled Agile comes in different flavors. Knowing the differences and similarities between various Agile frameworks can be largely beneficial, to put organizations at ease BEFORE they get underway with Agile Transformation, while with either of the frameworks: LeSS, Nexus, Scrum @ Scale, and SAFe.

Consider the recent LeSS in NYC meetup event in which attendees gathered around the virtual canvas projected onto the wall with goal of creating a perspective about the frameworks and comparing/contrasting them across multiple Agile dimensions (e.g., dependencies, optimization, overall structure, artifacts, ceremonies/events, teaming, ability to improve system design, roles/responsibilities, strengths, challenges, etc.).

meetup_collaboration

The participants were provided with a lightweight reference for each framework in the form of virtual stickies to “move” around across the table, in order to understand the differences of the various scaling frameworks.

What I found particularly interesting was a discussion about the differences between SAFe and LeSS initiated by one of the attendees. Here are a few highlights from this discussion:

Topics

SAFe

LeSS

Solving dependencies Coordinates people People work with technology
Cost of dependencies Coordination is seemingly necessary waste Learning to work with technology is investment
Optimization Resource coordination Outcome optimization
Batch size [1]  Planning cycle 3 months. Big batch of work to reduce total cost. [1] Planning. Sprint-long iterations to enable fast feedback
Main control mechanism [2] Bureaucratic [2] Clan
Customer contact Intermediated Direct
Organizational maturity Possible with lower skill. Learning for the role “Natural” Development Higher skill needed. Learning what is needed. Skilled evolution,  leading learning

Take away: Embracing either framework is simple yet not easy as technology, competence, identities and culture need to develop.

As Edgar H. Schein says, “There will always be learning anxiety…Learning only happens when survival anxiety is greater than learning anxiety.”  [3] Like with any enduring change, learning requires time though there is sure to be some worry and resistance.

References:

  1. [1] Stefan Thomke and Donald Reinertsen, Six myths of Product Development,” Harvard Business Review. May, 2012.
  2. [2] William G. Ouchi. A Conceptual Framework for the Design of Organizational Control Mechanisms. Management Science, Vol. 25, No. 9. (Sep., 1979), pp. 833-848.
  3. [3]  Edgar H. Schein, The Anxiety of Learning,” Harvard Business Review. March, 2002.

If you have any questions for Sevina, please contact her directly here

SAFe: Market Share Increase. Rapid Growth. What is the recipe?


This top paragraph is an amendment to the original blog post, created by me back on May 7th, of 2016.

What drove me to make this amendment was the recent webinar recorded by VersionOne: How to use SAFe® to Deliver Value at Enterprise Scale Q&A Discussion with Dean Leffingwell).   If you fast-forward to about 23 min, 20 seconds into the recording, you will hear the following statement: “…We don’t typically mess with your organizational structure because that is a pretty big deal…”

This statement somewhere puzzled me.  While graphic representation of SAFe framework does not shy away from supporting organizational complexity, I was still under impression that organizational re-design is included in SAFe teaching.  To me, the ability to influence first-degree system variables, such as Organizational Structure, is critical.  Without this ability, any attempt to improve organizational agility and system dynamics would be short-term and limited.  Even such important second-degree system variables, as organizational culture, values, norms, behaviors, policies, agile engineering practices usually bring limited results if organizational structure remains unchanged.

…But regardless of my recent new learning I had to admit to myself that SAFe still remains a very successful and popular product for many large organizations.   …And at this point, I would like to refer a reader, to my original post below….

Lately, there has been so much buzz in agile arena about scaled agile frameworks.  I just came back from Scrum Global gathering in Orlando, where I heard a lot of discussions about agility at scale and various existing agile frameworks that are in use.  Following Orlando discussions, I have seen a wave of email exchanges and blogs on the same topic, some of which involved seasoned organizational coaches and trainers.  I have noticed that there has been a lot of focus on SAFe (Scaled Agile Framework): opinions, comments, attempts to compare to other agile frameworks.   There are two things, in particular, that strike me as odd:

  1. It seems that some seasoned coaches and trainers don’t explicitly state their views.  When I read indirect statements  or views, I continue wondering how a person really feels about the subject.
  2. Among blogs and other posts that I have seen, I was not able to see any discussions that cover aspects of SAFe that are of particular interest to me.

But before I go any further, here is my personal disclaimer:  I am neither SAFe practitioner, nor trainer or coach.  I have not attended a comprehensive SAFe course… However…I have studied/researched SAFe extensively on my own. And I do know some companies that have implemented SAFe (I have talked with some of their employees).  And I do know significant number of individuals that have been trained in SAFe.  And I do know a handful of respected coaches that recommend SAFe.  So basically, I understand SAFe beyond just knowing how to spell it 🙂 .

Now, let me put “SAFe” topic to the side, for a moment, and shift gears to something else (we will all come back to SAFe in a minute):

I want to bring up the topic that has been a beat to death horse for awhile, for everyone who understands agility: the topic of tooling.

When it comes to discussions of agile tools, most experienced agile coaches have a long arsenal of arguments to use with their clients, prospects or less seasoned agile enthusiasts.  Here some classic examples:

  • 1st postulate of Agile Manifesto: “Individuals and interactions over processes and tools”
  • “A fool with a tool is still a fool”
  • “The best tool in Scrum is a whiteboard (or excel, at most)”
  • “Agile tool is not a right solution for your deep organizational problem“
  • “Never begin your agile education with tools. Always learn principles and concepts first”
  • “Agile tool is a poor substitution for collaboration that you may never have. If you start exchanging information through a tool you will lose the benefit of live discussion.  If you absolutely just to introduce a tool, do it later in a process, when people gain sufficient amount of knowledge and experience”
  • Etc, etc, etc…

We, as coaches, are never shy to express our strong views (sometimes, overly strong) about tools, NOT being a good solution to organizational problems and NOT being the best method (by far) to transform organizations.   And I am glad we are not shy about that.   This is why we are called Organizational Coaches – we look at organizations holistically.  For us, tooling is just a tiny fraction of a much bigger organization puzzle.  And personally, I never heard organizational coaches disagree too much about the bullets above: we are all very much on the same page, we stand together on this, and we cannot be fooled.

<SIDE NOTE ON>

But I still want to be very transparent about myself, with regards to tooling, so here is another personal disclaimer: over the last decade, I have been around and have gained a lot of experience with tools like JIRA, Version One, Rally and others…  I consider this as a personal ‘hobby’ but I know how to decouple it from daily work that have to do an organizational coach.  Over the years, I got to know some great software engineers that have built the tools mentioned above.  I could probably easily pass for an in-house “agile tool expert” (that is if I choose changing my profession one day) and find a job that says something like this: “Looking for a strong agile tool expert to transform our organization to the next level. PMP certification is a huge plus.  You must also have a valid H1B Visa 🙂 ”.  Yes, sadly there are many job specs out there that sound just like this 🙁 .

On a brighter side, I could probably also leverage my ‘hobby’, and look at any agile tool, used by a team or a group of teams that claims “to do” agile, and in about 5 minutes find a handful of signs of serious systemic dysfunctions (just in a tool alone!).  So, there is actually some practical use of my hobby.  So, in any case, I think I have earned the right to say that I know very well what tools can and CANNOT do for you.  And this is why, I strongly stand with all other coaches that use the arguments I listed above.

<SIDE NOTE OFF>

Here is my conclusion: “It seems that organizational design experts, and system thinkers, change agents, agile coaches/trainers are pretty comfortable to, strongly and openly, state their views, in cases, where they feel they are stating the obvious – for example, about tooling.”  Let’s hold on to this thought for a moment.

 Now I would like to come back to the topic of SAFe and set the stage to my questions, by stating the following:

High Market Penetration of SAFe:

First of all, lets take a look at some relevant data that has been recently published on InfoQ, with the original source being Version One, 10th Annual State of Agile Survey: while still being a relatively new framework, SAFe has acquired a significant share of market place –23% , while demonstrating the highest rate of growth:  “…the largest increase from 19% in 2014 to 27% in 2015…”

 

My understanding of safety that SAFe brings:

I have heard various opinions about what went into thinking of the acronym “SAFe”: was it an intention to make it sound phonetically as “safe” or was it just coincidental that the words Scaled Agile Framework that begin with “S”, “A” and “F”, respectively, made up SAFe?  I don’t know.  And I don’t want to speculate.  But let  share my understanding of what some more obvious safety factors of SAFe are. But again, this is my view only:

  • SAFe does not seem to be threatening to first-line management. Thanks to its first two layers (Team/Program & Value Stream) and abundance processes and roles that are present in both, everyone can find place to work.  Other words, the degree of fear about being misplaced or losing a job is relatively low.  If we all recall, what happens with implementing basic Scrum, where teams are expected to become self-organized and self-managed, and where the role of Project Manager is not explicitly discussed, we (coaches, trainers) frequently have to answer the following question, usually coming from managers: “what now happens to my role?”  And of course, there are ways to handle this question properly and give good options to those who ask, but this is not my point.  My point is that I don’t expect this question to be asked as frequently with introduction of SAFe.  Why?  Because SAFe seems to be a good way to harbor many existing management roles (role security), although, perhaps under different naming convention.
  • SAFe looks “homey” to senior management.  SAFe graphic is very rich in colors, objects, lines, layers, icons that represent roles, groups, departments, interactions.  At a glance, SAFe appears as a natural fit and a comfortable habitat for many existing organization constructs.  There is no explicit invitation to significantly challenge/simplify existing organizational design; no hints to change/simplify reporting lines or flatten layers (de-scaling).  No need to have unpleasant conversations with employees (!).  Senior managers that are confident that their organizations are well designed and don’t need any major repairs, see SAFe as a safe way to try agility.
  • SAFe does NOT explicitly compete with other agile practices. SAFe uses them all. In fact, a cute yellow smiley-squeeze-toy that many folks picked up in Orlando from SAFe kiosk, explicitly says: “SAFe embraces Scrum“.  same_embraces_scrumIndeed, at its multiple layers, SAFe diagram mentions Scrum, Kanban, XP,…and many roles, artifacts and ceremonies and iterations that support all these practices.  And this, IMO, makes SAFe really safe, in a very special way: if Company X already uses, perhaps inconsistently, some agile practices, it is relatively safe, and actually convenient, for SAFe consultant to come in and say something like this: “we can help you retain most (if not all) of what you have adopted so far but it will be much better structured under the overarching umbrella of SAFe”.  Other words, SAFe consultant does not have to worry too much about upsetting people of Company X, by making them give up what may have grown an attachment to – they can keep it all.  Effectively, in my mind, SAFe acquisition does not have to translate into workforce/practice reduction. To me it seems to be a pretty safe offering.

 

My understanding of SAFe Partnerships and Strategic Goals:

Here, I am listing only the top few references that I found on-line.  But the list could be much longer if I spent more time searching.  I personally have attended a handful of webinars, where concepts of SAFe were presented, along-side with benefits of tools (by companies that hosted webinars).

Please, finish reading the post first and then come back to the links.

Golden Sponsorship by Consultancies (not specialized in Agile):

With TFS/VSTS:

Note: TFS/VSTS are Microsoft products.  Tool design and “logic behind” resemble MSFT Project Plan :)…

With Rally:

With Jira:

With Version One:

Just to be clear for those that may not be as well familiar with these tools as I am (you don’t have to share my hobbies 🙂 ): each one of these tools now has complex Strategic Layers that sit at the top of tools’ “tactical” layers and constructs (epics/stories, backlogs, sprints, releases, team views, agile boards, story/task boards, workflow management, etc, etc) – and they are meant for Project, Program and Portfolio Management. At some companies, where I have consulted, each one of these layers typically had a manager (Project Manager, Program Manager, Portfolio Manager, respectively, etc), someone who was responsible for data collection and status reporting – and that was without or prior to any implementation of SAFe (or any other scaled solution).  Tool complexity alone was sufficient to offer a nice fit to an existing organizational structure.

<SIDE NOTE ON>

What is also probably not a surprise to anyone is that there are so many large companies out there that own tens of thousands of licenses for the above mentioned tools.  I have been to a number of such companies and seen these tools being a “hallmark of organizational agility” to too many people that understood very little about true organizational agility.  Please note that very frequently “best practices of use”, even for agile tools, reside within departments like Control & Governance, PMO, and Centers of Excellenc, where decisions about “what is best” are made in a vacuum and then are cascaded down to organizational domains that are thousands of miles away.

<SIDE NOTE OFF>

So, here is another safety aspect of SAFe that probably belongs to the previous section of my post but I will keep it here:

SAFe is very safe to client-to-vendor relationships  : it does NOT disrupt existing million-dollar (of course, depends on company size) contracts and license agreements between client companies and tool vendors.  It should be pretty safe, imo, for SAFe consultant to come in and say something like this: “if you are using JIRA or Rally or Version One or any other tool that has Portfolio Management layer in it, it will be very complimentary to what we can do for you in terms of agile scaling”.   I think that the links that I have provided above suggest exactly that.

All in all, SAFe seems to be a great compliment and strategic alliance to some agile tools companies that have gained a lot of  their own market share over years.  And it does not matter that JIRA and Version One and Rally or others, could be competitors to each other. They all seem to be great partners of SAFe (I will not speculate on exclusivity of relationships but based on the links above, there may not be any).

Now, after I brought to light some relevant market data, shared some personal views on what I consider as “safety factors of SAFe” (some people may see them as true benefits of SAFe) and gave a perspective on some possible strategic alignments that may exist between SAFe and industry leaders in the world of agile tooling, I would like to ask the following two (2) questions and make one (1) small request:

  • First Question: Do you think that market penetration of SAFe and its adoption success could be attributed to a personal safety of companies’ managers, as I have described above?  Do you feel that ‘role security’ of first-level management in particular is a significant contributor to SAFe adoption rate?  I stress this last point because the role of first-level manager is in super-abundance today at many companies.
  • Second Question: Do you think that market penetration of SAFe and its adoption success could be attributed to (at least in part) to its direct or indirect alignment with industry leaders that build agile tools?  Do you think that “SAFe + XYZ tool” produces a stronger compounded effect on organizations in terms of SAFe adoption, than SAFe applied alone?
  • Third – Request: I would like to respectively request from my colleagues, coaches and trainers, when they talk about any topic (in this case, SAFe is the topic of choice, but it could be anything else), to be more open-minded and clear in their views.  For example, if someone sees the same system relationships as I described above, and he is comfortable sharing his strong views about tools, would it not be reasonable to expect the same person shares his explicit views on related frameworks? And the opposite should be true too: if there is no comfort to explicitly discuss frameworks, why then be so adamant to state your views on tooling 🙂 ?

The last request, is an invitation to system thinking 🙂 .

I hope this post was safe for everyone to read 🙂 .  Feedback is highly appreciated from everyone who has a view.

Related Publications about SAFe by Agile Manifesto Co-signers and others:

From LeSS Toolbox: Causal Loop Diagrams to visualize System Dynamics

Introduction:

When it comes to scaling, there is a common misconception that “bigger always means better”.  This misconception is also traceable to agile arena, where companies look for ways to expand their agile practices beyond a single organizational domain (e.g. many teams, numerous departments, multiple lines of business, etc.).  Usually, it is an existing (inherited) organizational complexity that becomes the main reason why companies look for complex, multi-tiered scaling solutions.  And of course, if there is a demand, there will be a supply: there is a number of frameworks out there that hand-hold companies to comfortably “embrace” their existing complexity and not feel too uncomfortable about their own internal dysfunctions.

However, not all scaling solutions are as “forgiving”J.  There are some agile frameworks that intentionally expose and boldly challenge organizational deficiencies. One of such frameworks is Large Scale Scrum (LeSS).  In order to set a stage for the rest of this discussion, I would like to summarize a few points about LeSS here.

I also would like to express my appreciation and acknowledgement to Craig Larman (one of co-founders of LeSS) for helping me deepen and broaden my understanding of organizational design and improve my system thinking that I have been developing over years.

 

Brief Overview of LeSS:

LeSS is a very easy to understand.  I like to speak metaphorically, so in describing LeSS, I sometimes use analogy with a legendary assault rifle AK-47 that has the following, well-known characteristics:

  • it has very few moving parts and, therefore, its internal friction is pretty low; also not too many small pieces that can jam or break
  • it is simple to disassemble, inspect and reassemble (inspection & adoption)
  • it is very reliable and adoptable under tough conditions (rarely fails in action)
  • if necessary, it can be modified and “expanded”, at low cost/low effort

But there is something else about LeSS that makes its analogy to a weapon (probably, not just to AK) appropriate: it assaults organizational dysfunctions.

LeSS also has two important characteristics:

  1. It is very simple in design and fully rests on core principles of basic Scrum (Effectively, LeSS is the same Scrum, as it is described in Scrum Guide, but performed by multiple teams)
  2. LeSS teachings rest on the pillars of:
    1. Lean Thinking: “watching the baton, not the runner”, visual management, cadence, time-boxing, managers being teachers, continuous improvement
    2. System Thinking: Weinberg-Brooks’ Law, Queueing Theory, indirect benefits of managing batch size and cycle time, being customer-centric, explain differences between local and system optimization).

Thanks to these two key characteristics, LeSS is a very powerful mechanism that helps seeing an organization systemically/holistically, while identifying and exposing (analogy, to a high power rifle scope is suitable here) its pain points that need to be addressed.

As a framework, LeSS is lean and transparent. It does not have any “secret pockets” or “special compartments”, where organizational problems can find safe heaven. No dysfunctions escape sharp focus of LeSS: ineffectively applied processes or tools, ill-defined roles and responsibilities, unhealthy elements of organizational culture and other outdated norms – all of this gets vividly exposed, when using LeSS. Interestingly, while LeSS is a scaling framework that allows to scale-up (roll-up) efforts made by multiple scrum teams, it requires organizational de-scaling to be performed first.  The metaphor that I often use at here is: “you can get more with LeSS”.  To put it another way, in order to build-up Scrum effectively, an organization must remove whatever extra/unnecessary “muda” (waste) it has already accumulated that gets in a way of scaling Scrum.  It is almost like this: LeSS prefers thin but very strong foundational layer, over thick and convoluted but unstable foundational layer, with the ladder, usually being a characteristic of an orthodox, archaic organizational design.

Another metaphor that I use to describe LeSS is that it is an organizational design mirror.  By adopting LeSS, an organization sees its own reflection and depending on its strategic goals and appetite for change, decides on necessary improvements. Similarly, to a person who takes his personal fitness training seriously and uses a mirror for “course correction”, an organization may use LeSS to decide if any further re-shaping or “trimming” is required to get to a next maturity level.

LeSS is also a great guide to technical excellence.  I have used LeSS teachings extensively to coach the importance of continuous integration, continuous delivery, clean code, unit testing, architecture & design, test automation as well as some other techniques that make agile development so great.  LeSS stresses that mature engineering practices are paramount for effective adoption of agile across multiple organizational domains, not just IT.

 

Discussion

So, how can an organization take advantage of both: simplicity of LeSS construct, on one hand, and its deep systemic views, on the other hand – to improve its organizational agility beyond a single team? How can principles of lean and system thinking – together, and along with understanding ‘beyond-first-order’ system dynamics be leveraged to implement true scrum, without reducing, minimizing or downplaying importance of its core values and principles?

As an organizational and agile coach and someone who has been using LeSS extensively in his daily coaching work, I frequently witness situations when companies have to deal with this serious dilemma.  Here, I want to share the magic “glue” that helps me bring my thoughts together and deliver them to my clients.  This “glue” is one of the most effective tools that I have discovered for myself inside the LeSS toolbox.  It is called Causal Loop Diagrams (CLD).

CLDs – are a great way to graphically illustrate cause & affect relationships between various elements of an organizational ecosystem.  CLDs help me effectively uncover second and third order system dynamics that may not as apparent to a naked eye, as first order dynamics.  CLDs help me brainstorm complex organizational puzzles and conduct deep analysis of system challenges.  Ultimately, I have found that CLDs are a great way to communicate ideas to my customers, particularly, to senior leadership.

Here are some elements of CLDs that I use in my graphics:

  • Goals – high, overarching/strategic goal that needs to be achieved
  • Variables – system elements that have effect/make influence on other system elements (other variables)
  • Causal links – arrows that connect two related variables
  • Opposite effects – “O” annotation near an arrow; suggest that effect of one variable on another variable is opposite to what could be expected
  • Delayed effect – “||” annotation that disrupts a causal link (arrow); it implies that there is a delayed effect of one variable by another variable
  • Extreme effects – one variable has an extreme (beyond normal) effect on another variable; it is represented by a thick arrow
  • Constraints – “C” annotation near arrow; implies that there is a constraint on a variable
  • Quick- Fix reactions – “QF” annotation near an arrow; action that brings about short-term, lower cost effect

 

At this point, I would like to provide an example of using CLDs, to visually illustrate second and third order dynamics between key system variables that I often see cause harm and unrest to organizational: performance-driven, discretionary monetary incentives.  

I would like to follow through the process of interaction between system variables as they come to play with one another and uncover the impact they have on the overall system.

Every year, a company (hypothetical Company X) has to distribute a large sum of money to many of its employees in the form of discretionary bonuses.  In order to make a decision-making process less subjective, a company ties it to employees’ individual performance: reviews and appraisals.  People that have demonstrated better performance, get more money, people that have demonstrated poorer performance – get less (or nothing).  This requires that every employee gets evaluated by her line manager, usually, twice every year, at which time an employee gets some rough idea about “how much she is worth as resource”.  This serves as a guide to how much discretionary money an employee might be expecting to get, as a bonus.  While at its surface, the process of performance evaluations and appraisals may seem to be more objective, than a line manager just simply deciding on his own, it is still very subjective as an employee’s opinion is disregarded, when making decisions.  Furthermore, the process is harmful and causes deterioration of individuals’ morale and relationships, on multiple fronts.  Undesirable effects and short-/long-term damage of performance evaluations and appraisals have been studied for years; lots of research and statistical data is available today.   If a reader is not well familiar with this topic or requires additional background information to deepen his understanding, he may refer to the following resources, prior to proceeding with reading:

 

Moving along with this discussion, I would like to highlight the following three downstream “system variables” that are directly (first order dynamics) impacted by individual performance reviews.  This type of system variables integration is mainly observed among technology groups.  Once we understand a first order dynamics, we shall proceed to some other downstream (“beyond first order”) variables.

 

Employee Happiness Factor

Many research studies have proved that employees don’t like to be appraised.  An appraisal is equivocal to slapping a price tag on someone and is hardly an objective process, as the only opinion that really matters is that of a line manager.  Yet, an official version at almost any company is that an appraisal helps an employee grow and mature professionally and offers a way to improve her individual performance towards some arbitrarily set target.  Truth to be told: was the intent of appraisals to help employees grow and continuously improve, the process would not be implemented once or twice a year, but rather, more frequently, in ways that would allow an employee to make a necessary course correction more iteratively.  After all, why wait for 6 months to tell a worker that she needs to improve?

At the time of appraisal, a manager delivers to an employee her final and practically undisputed decision.  An employee has practically no effective way to challenge or dispute such decision.  Frequently, even a line manager does not have control of the process (although, this is rarely admitted): he or she is presented with a fixed “bag of cash”, coming from management above, and this bag, somehow, has to be distributed among lower-ranking workers.   And just to be fair to line managers that are not delusional about the dysfunction they have to entertain, most of them also dislike the process as it makes them annihilated and resented by their own employees.

 

So, as time goes by, employees become less and less pleased with evaluations and appraisals.  The impact may not be observed immediately due to the fact that it usually takes time for an employee to mentally mature to the point, where she becomes conscious and begins comprehend the unfairness and lawfulness of the process.  (Of course, exceptions exist among people that have longer experience of dealing with this process and understand its ineffectiveness and harm.)

 

While leveraging, CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that annual appraisals have delayed and opposite effect on employees’ happiness.

 

Peer to Peer Support

Peer-to-peer support, willingness to share knowledge with colleagues, collective ownership of assignments and shared responsibility for deliverables – these are the hallmarks not only of feature teams’ dynamics but of any agile environment.  In order for employees to be mutually supportive, they must operate in non-compete environment, where they don’t view each other as competitors or rivals.  This is practically impossible to achieve when every employee perceives another employee (at least within the salary ranking tier) as a competing bonus collector.  And this is exactly what is observed in environments, where bonuses are distributed, based on individual performance: employees compete for the same, limited pool of cash.  But everyone cannot be a winner: even if a group of brightest individuals, working together, someone within that group would have to be ranked higher and someone – lower (and btw, people are frequently explained this upfront).  How could we expect people to be supportive of each other if, effectively, underperformance of one employee and her inability to collect extra money increases chances of another employee to bring home more cash?  Performance appraisals and discretionary moneys drive employees apart, not together.

Again, the adverse results of appraisals may not be immediate: pain points become more obvious after bonuses are actually paid (end-of-year/early-next-year) – this is when employees start developing resentment and jealousy towards each other over paid bonuses.

 

While leveraging, CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that annual appraisals have delayed and opposite effect on peer to peer support.

 

Both variables above, directly (first order) define employees’ Intrinsic Motivation to work and their willingness to stay with a company.  After all, can we expect that an unhappy employee, while being in constant competition with his peers and being deprived of an opportunity to safely experiment, would want to dedicate himself to a company for a long time?  Probably not, and as a result, Employee Retention should not be expected to be high, and as it has been seen in many cases: good employees that always leave first.

 

While leveraging, CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that both, employees’ happiness and their willingness to support each other, are directly related to their intrinsic motivation to work and willingness to stay with a company, and as a downstream effect – this increases employees’ retention.  The opposite would be true as well: lowering values of upstream (left-side) variables will lower values of downstream (right-side) variables.

 

 

“Environmental Safety” and Desire to Experiment

Innovation and experimentation are paramount for success in software development. This is what drives feature teams towards improvement.  Scrum, for example, requires continuous inspection and adoption.  It is expected that, while experimenting, feature/scrum teams may run into roadblocks or have short-term failures, at which point they will learn and improve.  But in order to be willing to experiment and take chances, teams need to be sure that they are safe to do so.  Another words, they need to be sure that they will not be judged and scrutinized for their interim failures.  Such “environmental safety” will be always jeopardized by individual performance appraisals. Why? Because individual success (high individual performance) of an employee is defined by her ability to precisely meet individual goals, set in stone early-on in a year.  The need to follow a “script” precisely kills any desire of an employee to experiment.  After-all, why would a person want to take any chances if her failures will be perceived by line management as underperformance?

Since appraisals make working environments unsafe and kill individuals’ desire to experiment, as soon as an employee is presented with her annual goals, she reacts self-protectively, by starting to “work to the script”, while trying to document every personal achievement “for the record” (a.k.a. “CYA”)

 

While leveraging, CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

This graphic suggests that when employees are safe and are not feared to experiment, innovation and experiments take place in a workplace.  Inversely, lack of safety in a work place and absence of desire for experimenting reduces chances of innovation and improvement.

In the sections below, I would like to take a closer look system dynamics that are beyond the first order of interaction, by tracing some additional downstream system variables:

 

Team synergy & stability:

In scrum, we would like our teams to be stable and long-lived.  We would like to see team members enjoy being a part of the same team, and do so as happy volunteers, not as prisoners, constantly looking for opportunities to escape.  In fact, best feature teams known, have been created as a result of voluntary self-organization, not as a result of a managerial mandate.

Why do we want our scrum/feature teams remain stable?  Here are some good reasons:

  • Collaborative environment and desire to work together
  • Shared domain expertize and cross-pollination with technical knowledge
  • Predictable team Velocity and ability to plan/forecast more accurately

 

So, how does team synergy and stability get impacted by performance evaluations and appraisals? Here is how this happens, indirectly:

Via low Employee Retention – as employees leave a company, feature teams disintegrate.  This brings together new team members that have never worked together and require time before they can ‘form, norm and storm’.  As feature teams get dis- and re-assembled, velocities drop/become less reliable and system variability increases (estimation becomes less accurate).  The effect is usually immediate.  In my personal experience, I have seen many feature teams breaking lose and falling apart shortly, after companies have announced annual bonuses.

While leveraging CLDs in my discussions with senior management, I use the following graphic representation to convey the concept:

This graphic suggests that high employee retention will lead to elevated team synergy and stability.  Inversely, low employee retention in a work place lowers teams’ synergy and stability.

 

Via high Internal Competition and Rivalry – once employees realize that they have to compete with their own teammates for discretionary dollars, collaboration deteriorates dramatically.  Individuals stop supporting each other in pursuit of common goals. Instead, everyone strives to be a super hero and solitary performer, while trying to demonstrate her own efficiency and hyper-productivity to a manager.  Everyone wants to look better than other peers and teammates.  Race to demonstrate best individual performance has a high cost: it happens at expense of overall team performance.   Since collaboration, swarming and shared ownership of work are critical for healthy scrum, the obvious downstream effect of performance evaluations and appraisals not becomes clearer: lowered team synergy and instability.

While leveraging, CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

 

This graphic suggests that internal competition and rivalry will have an extreme and opposite effect on team synergy and stability.

 

Healthy Scrum Dynamics:

There are many known system variables that interact with one another and define effectiveness of basic Scrum.  Assuming that most readers of this post are familiar with Scrum and in order to keep my focus on other important downstream system variables, I am going to leave detailed discussions of basic Scrum dynamics out. It would suffice to mention that the following classic Scrum-specific variables have to be always considered: feature velocity, # of defects, $ rate at which developers are hired (low vs. common), # low skilled developers, cash supply, ability to guide and improve the system, etc.  If the reader is interested in exploring this in-depth, “Seeing System Dynamics: Causal Loop Diagrams” section of http://less.works site greatly describes these system dynamics, with the use of CLDs.

However, when leveraging CLDs in my discussions with senior management, I still use the following generalizing graphic representation and annotation to convey this common-sense, overarching concept:

This graphic suggests that team synergy and stability lead to healthy Scrum dynamics and a feedback loop is positive (value increase on left leads to value increase on right).  In my experience, the effect is sometimes delayed.  A time lag is usually due to previously gained momentum.

So far we have used CLDs to explore system dynamics that primarily impact technology teams.  At this point, would like to shift my focus on business side of the house and explore the part of system dynamics that involves customers.  In particular, I would like to provide some examples of how CLDs can expose the adverse impact of individual performance appraisals and discretionary monetary incentives on Product Ownership in Scrum.

 

Identification of GREAT Product Owner:

Finding a good candidate for the role of Product Owner has been one of the most challenging tasks in Scrum. Why?

The role of Product Owner combines certain characteristics that are not easily found within the same individual, and it is organizations of high organizational complexity and Tylorian culture, where this challenge is seen most. On one hand, Product Owner is expected to have enough seniority and empowerment to make key strategic business decisions.  On the other hand, Product Owner is expected to get intimately involved in day-to-day, and sometimes, hour-by-hour interaction with technology groups.  When these two sets of characteristics come together in the same person, we hit a jackpot: we get a great Product Owner – a person who is both Empowered and Engaged.  But truth to be told that it is often challenging to identify a person that possesses both “Es”.  In most Orange organizations (the predominant color of most modern corporations, as per Laloux Culture Model), definition of every job includes a fixed set of responsibilities that individuals are obligated to fulfill.  If we look at most job descriptions, as they are defined by HR departments of Orange companies, we will hardly ever see a job spec that has ”slack time” for an person to take on responsibilities of Product Owner, in addition to his primary job, let alone a job spec that in fully dedicated to the role of PO.  For most organizations, Product Owner is still not a well-defined role and as such, it is not perceived by employees as a step towards career advancement.  Today, many organizations that use scrum have to experiment with the role of PO, by looking for right individuals, internally.  Individuals that step up for the role if Product Owner have to make a conscious decision, with full acknowledgement that they will be taking a very wide spectrum of new responsibilities.  For most people, this is risky, because, effectively, it means that attention and focus on primary activities (as per job specs) will be diluted by secondary activities – fulfilling the role of PO.  Of course, this problem could be easily mitigated with full backing and support, from senior leadership and HR, by redefining job specs and explicitly recognizing criticality of Product Owner role.  But it hardly ever happens (and mostly, at product development companies).

It is hard to argue that people have to be recognized for the work that they do.  I doubt that anyone would object to the following statement: nobody should be working two jobs for the same pay check.  People have to “feel safe” about stepping into a new territory, learning new activities and developing work dynamics that they have not experienced before.  This brings us to the same concept that we discussed earlier, when we looked at technology groups: individuals need to feel safe, in order to be willing to experiment with a new role. It would be unreasonable to expect an employee to take on more work that would not be “counted in” when a person gets evaluated for his contribution to an organization.

So again, while leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

As the graphic suggests when employees are safe and are not feared to experiment, it will be less difficult to identify a good Product Owner. Inversely, the opposite is true as well: lack of safety and inability to experiment makes the process of Product Owner selection much more challenging.

At this point, it is worth mentioning one very common Quick Fix that organizations frequently make to compensate for shortcomings in finding a good Product Owner:

Empowerment usually implies that a person occupies a senior organizational position.  As such, a business person’s career has progressed beyond a certain point; she no longer has enough bandwidth (nor desire!) to deal directly with technology. Once reaching a certain level of seniority, a person gets a “bigger fish to fry” and collaborating with individual technology (feature) teams is no longer her priority. So, while still retaining one of the “Es” (Empowered), a person is not able to demonstrate another “E” (Engaged).  In order, to compensate for the missing “E”, another person needs to be “inserted” into the system, to fill in the gap between a real Product Owner and technology teams.  This, poorly-defined (undefined) role is sometimes labeled “PO-proxy” – a surrogate person tries to act as PO but does not have the power. This role is usually occupied by someone from a lower organizational layer: a business analyst, system analyst or another person – someone who is more accustomed to work directly with technology and for whom the activity itself is not perceived as “below pay grid’.  This creates a serious dysfunction in scrum operating model, as communication between a true customer (empowered Product Owner) and technology is now hindered: a surrogate role of PO-proxy usually lacks strategic/holistic product vision and power to make important business decisions within short timeframes, as it is required by Scrum.

It is worth noting that functional expertize of a business analyst or systems analyst are both welcomed in Scrum and usually reside within teams (although single-specialty individuals are viewed as less valuable than multi-skilled, a.k.a., T-shaped individuals).

The reason why delegation of responsibilities described above is problematic is because it artificially creates unnecessary communicational layers between end customers and technology. This type organizational design causes a variety of additional dysfunctions (miscommunication, hindrance to information flow, confusion of priorities, etc.), and therefore strongly not recommended.

 

While leveraging CLDs in my discussions with senior management, I use the following graphic representation and annotation to convey the concept:

As the graphic suggests, difficulty to identify a good candidate for the role of Product Owner creates the need to look for quicker and cheaper solutions; introduction a powerless surrogate role of PO-proxy is commonly seen, undesirable ‘Plan B’.

The reason why this fix is “quick” – because it usually does not take too long for a real Product Owner to realize that he/she is not able (or willing) to handle additional responsibilities of the role.  In my practice, risks of losing a real Product Owner and getting a proxy instead, did not take too long to materialize: usually a few weeks after Scrum was introduced.

 

Effectiveness of Product Backlog management:

Effective Product Backlog management is paramount in agile product development.  This is the fundamental concept that has been introduced in simple Scrum and it remains as valid in scaled Scrum.  In fact, when an organization scales its Scrum, by involving multiple technology teams, Product Owners and lines of business, effective product backlog management becomes even more critical: work coordination, resource management, impediment removal, alignment of business priorities etc.

As we can guess, effective product backlog management, including work prioritization, story decomposition etc. can be done most effectively with participation of a real Product Owner.  And oppositely, if an organization is missing the critical figure of Product Owner, product backlog management will become ineffective.

While leveraging CLDs in my discussions with senior management, I use the following two graphic representations and annotations to convey these two related concepts:

 

As the graphic suggests, product backlog management suffers from both: lack of true Product Ownership and presence of ineffective surrogate roles.  In my personal experience, the effect is usually extreme.

 

Healthy Scrum dynamics (overall):

At this point, I usually provide senior managers with a partial summary of LCD, by showing how ‘healthy scrum dynamics’, while sitting much further downstream from individual performance evaluations, appraisals and bonuses are still impacted by the latter group via second order dynamics (through secondary variables). CLDs do a great job of bringing many aspects of system thinking together and presenting them visually.

Below is the combined view of how four upstream system variables that we have discussed earlier relate to ‘healthy scrum dynamics’:

As the graphic suggests, nature of the effect (positive vs. negative), time of onset (immediate vs. delayed) and impact (casual vs. extreme) are could be unique for each variable.

 

Scaling Scrum and Organizational Agility:

In this section, I want to describe how I, with the use of CLDs, bring my discussions with senior management to culmination, by painting a bigger picture of organizational agility.

For most large organizations, success by a single team is not the end goal.  Organizations look for “bigger” solutions.  And their reasons are obvious: huge IT departments, many lines of business, many customers, multiple competing priorities, multi-year strategy, and many other elements that make organizational needs nothing less of huge.  Luckily, most of organizational leaders that I have met in my practice, understand that the ability to effectively scale basic agile frameworks (e.g. simple Scrum) will ultimately improve organizational agility and ensure that both customers and employees are happy.

Below is the graphic that summarizes this last, ‘common sense’ relationship:

 

Tying it all back:

What I would like to do at this point, is to make one step back and describe what it takes to scale scrum effectively:

This is where another powerful concept of LeSS comes to rescue: in order to scale Scrum, an organization must be descaled first (please refer to “Less Agile or LeSS Agile?” by Craig Larman).  Other words, to construct a model of Scrum, performed by multiple teams, an organization must remove (deconstruct) its existing organizational complexly first.  As it was stated at the beginning of this post, scaling does not imply making things more complex, but unfortunately, this key concept is not always well understood.  Mistakenly, many people still think that in order to support existing organizational complexity they need to look for multi-tiered, complex agile frameworks that will provide “room and purpose” for every existing organizational element: roles, processes, tools and techniques.

The analogy that I frequently use to deliver the concept of scaling to senior management is that building a sky scraper on a wobbly, porous foundation is dangerous because it will eventually crumble. A surface must be cleaned up first, flattened and hardened, and only then there will be a chance to build something tall and strong.

Below is the graphic that summarizes this concept:

 

At this point, the most common request I get from senior leaders is to elaborate on what I mean by ‘de-scaling’ – and this is my favorite topic.  This question is natural but I usually resist on answering it immediately, since the topic is inherently large, complex and, at times, inflaming and therefore, I request a dedicated discussion for it.

However, I still produce CLD graphic illustration of the concept, as shown below, but offer a follow-up discussion to explore details:

Ultimately, when such discussion is held, I always tie it back to the present discussion and explain why Goal: distribute discretionary incentives” becomes so trivial with identification and removal of system/organizational waste.  This discussion is usually long and it requires challenging many outdated organizational norms and principles that some senior leaders are not willing to give up easily.

 

The CLD graphic illustration is a high-level generalization of the concept of the opposite (inverse) relationship between the two system variables:

As mentioned above, the variable in the dotted circle can be decomposed further into many, smaller system variables that have up- and downstream relationship with one another.

 

Summary:

The best summaries are short.  Therefore, I would like to summarize this post briefly, with one comprehensive CLD diagram that brings together and variables, relationships and annotations that were discussed so far:

Although it may take hours, or sometimes days of brainstorming to produce CLD, when complete, it becomes a great communication vehicle.   A diagram like this one can be created real-time, in collaboration with others, on a white board.  Alternatively, it could be created ahead of time by a coach or trainer and then be used as a ‘cheat sheet’, when appropriate.  CLDs can be also shared with wide audience ahead of time, to solicit questions and provoke interesting discussions at later point.

Global SCRUM GATHERING® Orlando 2016

It was a great event, with more than 1200 people attending from all over the world.  Tons of great presentations and collaborative sessions.  Below, are some captured moments with my peers and colleagues – the people that made my personal experience at the gathering so rich and memorable.  The coaches and trainers of Scrum Alliance have always been the main driving force behind this and many similar agile events around the globe.

With Coaches and Trainers during Pre-Retreat

 peers_3  peers_4  peers_5
 peers_6  peers_7  peers_9
peers_10 peers_8 peers_12
 peers_13  peers_14  peers_15
 peers_16  peers_17  peers_19
 peers_20  peers_27
 peers_23
 peers_24  peers_25  peers_26
 peers_2


 
peers_1
 peers_28

 

Grafic work produced at Gathering

 work_8
 work_10
 work_19
 work_9
 work_3
 work_2
 work_24  work_23  work_22
 work_21  work_18  work_11
 work_7  work_6  work_16

 work_12  work_17