Category Archives: Organizational Design

11/13 – LESS TALKS: NYC LeSS CLP and Meet-Up with Craig Larman

NYC LeSS Meetup with Craig Larman (Video Recording)
Summary by a featured guest-blogger, Enterprise Strategy & Organizational Design expert and Certified LeSS Practitioner – David Stackleather.

I had the opportunity to watch the NYC LeSS Meetup with Craig Larman via video. I attended one of these when Craig was in California, and have attended two CLP training sessions with him, so I have some idea about his message. It’s always useful to hear the news again if for no other reason than to overwrite some of the general nonsense one hears so often in the hallways of the average corporation or on the average Slack channel. Fresh air is good for the soul.
For those who haven’t heard Craig speak, or attend one of his training sessions, the best way I can describe him is that he’s the honey badger of change consultants, he just doesn’t give a, well you catch my drift. There aren’t a lot of weasel words or marketing fluff. Just the simple facts as he sees them. These facts, a description of reality really, can be challenging to hear at times. It’s why you often hear folks giggling uncomfortably in these sessions when Craig says something stark. The thing everyone should understand is, he’s not joking. So pay attention.
Although these sessions only run an hour or so, there is enough content to fill a book, literally. The concepts go deep, and the skills and tactics mentioned in a few sentences can take years to master and fully understand (things like systems modeling, for example). Here are just a few items that stood out to me during this particular session.
Scale Matters
A difficult thing to understand for many is that behavior at small scale is almost meaningless at large scale. Everyone wants to think they can improve their process, or get a little better at their job (or, hope that the other guy gets better at his). Larman makes the point that at scale, it’s the structure that drives change. The root cause of the problems many large enterprises encounter are the result of their design not how good the developer sitting in a cube on the 42nd floor is. Deming taught us this long ago; the workers are not the problem; the problem is at the top.
I like to think of this scale issue from the standpoint of process improvement. In process improvements focused on cycle time, improving the performance of individual processes is unlikely to improve end to end cycle time much if at all. Just messing with the procedures is just as likely to elongate the cycle time as it is to reduce it. The queues and delays between are the story. It’s the structure of the process that must change, not the pieces. Same for organizations. This is a very difficult message for folks to hear if they are not in the mahogany lined offices on the top floor. You can improve locally, and that is all well and good, and I’d advise it, because moving forward is the only way to survive, but it won’t solve your organization’s problems.
The market for deep change
Craig makes the point that the worldwide market for deep change, meaning those companies that really want to change at a fundamental level, is small, perhaps 500 companies total.
I’m not sure how many companies there are but I found online that the total listed companies across all stock exchanges is around 45,000. This is wrong, no doubt. It excludes private companies (some of which can be very large even in countries with deep financial markets where listed would be advantageous), and many of those 45,000 companies are likely rather small. But given that number, we’re looking at one percent of listed companies as being open to real, fundamental, change. That’s a sad state of affairs, but there are deep-seated reasons that there is so little appetite for change at the power center of companies.
Without a profound sense of urgency deep change doesn’t happen. Until leaders are backed against the wall with a real crisis, they are loath to upset the very system that has provided so much. Most large organizations are elegantly designed to provide a steady stream of only what the boss wants to hear. Everyone down the chain of command is in on the game as well, so they want to play by the rules as well. Any information that is raw, real, and innovative is squeezed of real value before it ever gets to the board room. This all feeds very nicely into the strong confirmation bias we all have. It’s very near a closed-loop system in many organizations I’d wager, recycling the same excuses over and over again.
Problems are provoked with fake change
Fake change are those change efforts where the senior leaders are unwilling to fundamentally change the organization, even if they say they are. Instituting change in this environment can provoke existing power structures. When problems inevitably are uncovered, there isn’t the courage to tackle the root cause. There isn’t the courage because that wasn’t the point. The most significant sign that the organization isn’t ready for real change is the avoidance of making the fundamental structural changes necessary. There will often be reasons to retain the old structure or relabel them. If that’s the case, it’s just a show. If you begin a change program in such an environment, you run the risk of awakening a dragon with no ability to slay it, at least organizationally. The problems initially articulated that provided the excuse for the change are not resolved and perhaps made worse by the change chaos. In some cases, it would be better to let the dragon sleep.
Is it hopeless?
Perhaps 99% hopeless. But that means there is a chance! Larman makes a great point about the individual, however. A point I think too many people miss because it’s uncomfortable. If you are in management, or any other specialist function that isn’t directly related to building something customers are willing to pay for, plan your exit. Learn a skill, become valuable. So many people operating in large organizations are intently focused on moving up the hierarchy that they forget that the purpose, at least in theory, of hiring anyone for anything is the skills that person brings to the table. If you never gain marketable skills or let them atrophy after years in the corporate environment, you will find yourself a prisoner. A prisoner of the very same organization you complain about.
Certified LeSS Practitioner –  Feedback From The Room

Summary by a featured guest-blogger, Agile Coach and Certified LeSS Practitioner – Soledad Rivero.

Definitely, participating in Craig Larman’s CLP training has fundamentally raised the bar for me, as a change agent, Scrum Master and Agile Coach. I managed to incorporate new concepts that will not only help me in my current situation, but will also be handy for many years to come. During this course we dont get into a deep dive of LeSS experiments (there are more than 600 of them and for that, there are 3 books that provide guidance, with examples and practical techniques in different chapters).  Instead, in this course we had a very unique 3-day experience with Craig, as he taught how to design your organization in a systemic way, thinking systemically, seeking to optimize the whole and not just locally. This course broke my mindset and perception and then put it back together again.  It opened up my mind, giving me more tools, and energy to keep changing things.

As Craig said in class: “to be an agent of change in an organization you need a lot of patience and big amount of sense of humor“.   It will not be easy, but for sure it will be worthy. Thanks again for amazing learning opportunity!

More Kodak Moments

About Contracts That Support Agile Ways of Working



One of various under-served (ignored) dimensions of agile transformations that frequently limit an organization’s success, there is one that requires special attention.

It is vendor management that can be traced back to legal contracts between a client company and supplier/vendor.

Vendor management norms and guidelines define relationships and interaction between a company’s own employees and external workers, individually and in team-level settings.  Unfortunately, this issue is not always obvious and therefore, is neither explicitly raised by inexperienced agile coaches, nor adequately addressed by senior leadership that is satisfied with limited results (could be also a sign of complacency).

There is a lot of improvement required in how corporate attorneys and vendor managers define, initiate and maintain external relationships with third parties.

This post provides a short summary of recommended improvements – they are  listed below.  It is based on a more comprehensive excerpt: Agile Contracts Primer, by T. Arbogast, C. Larman, B. Vodde.

(Also, please refer to Top-5 high-level recommendations for what to look for in vendors, selected for agile projects, in “Survival List to Vendor Selection on Agile Projects”)

Recommendations for Attorneys and Vendor Managers:
  • Acknowledge that Legal, just like Finance and HR can diminish project success if not considered as a part of agile ecosystem
  • Get rid of false dichotomies around the 3rd Agile Manifesto value: “just because we value customer collaboration than contract negotiation, it does not mean that a contract has no value” 😉
  • Make sure that attorneys understand that a “successful contract” is not the main goal.  It is a successful project or product (delivery) that is the main goal.
  • Draw analogy between software project complexity and your own (if you are an attorney) legal work complexity, to appreciate how difficult it is to do precise upfront estimation on huge, unpredictable body of work
  • Understand how agile approaches can lower (not completely remove) friction around, such areas of contract negotiation as liability, warranty, payments, pricing, deliverable
  • Understand that external legal contracts have downstream impact on internal non-legal contracts – relationships between people
  • Understand repercussions of subjective incentives and rewards (bonuses), given to attorneys for legal outcomes (event if they are successful), instead of focusing on an overall project success
  • Understand/study agile and iterative development (e.g. Scrum, Kanban), system thinking concepts, lean principles and agile project assumptions differ from traditional project assumptions
  • Gain strong grasp of what Acceptance Criteria, Definition of Done, PSPI and MVP mean
  • Study how continuous deployment and incremental development can reduce risk and exposure, as oppose to sequential/waterfall SDLC that usually  increases it
  • Understand positive implications of agile ways of working Limited Liability and Warranty, Deliverable and Pricing
  • Specifically, with regards to Pricing, understand:
    • Variations of T&M contracts and why they are good for agile projects.  For example:
      • Fixed price per iteration (per unit of time), fixed-price per large project
      • Fixed price per unit of work
      • Pay-per-use models
      • Hybrid shared pain/gain models
      • Capped-Price, Variable-Scope vs. Capped-Price, Partial-Fixed-Scope vs. Fixed-Price, Variable-Scope
      • Target-cost
    • Reasons why FPFS contacts are least desirable/most risky and what are some of the ways of lowering such risks
    • Difference between flexible scope without and with penalty (shared gain/pain)
    • Early termination – does not mean failure
Conclusion

Contracts are not necessarily always bad.  Having an external, legal contract between a client and a vendor/service provider/supplier is perfectly normal and even necessary.  It is the form of a contract that matters, as it has downstream effect on dynamics and behaviors between people within a client company, as well as between the parties.

To produce a meaningful contract for an agile project, an attorney should have good understanding of what is valued most in agile work, by agile teams, and optimize his/her own work for the benefit of an overall project, not just for having an amazing contract (locally optimized for an attorney’s benefit).  To gain such understanding a legal professional needs to invest significantly in studying principles of agile/adaptive product development (e.g. Scrum, Kanban), lean and system thinking.

Some of the above listed contract types are more supportive of agile work than others and each once must be explored in detail for suitability, depending on unique organizational settings.

 

Thoughts by Rick Waters, CST

Rick Waters is a Business Agility Coach and Trainer, from Chicago, with more than 15 years of technical software development experience, and almost 10 years of Agile leadership experience.  Rick primarily trains Scrum, Enterprise Scrum Business Agility, and Kanban.
This is what Rick wrote, in support of the recently released book by Gene Gendel (Adaptive Ecosystems: The Green Book: Collection of Independent Essays About Agility):

Nearly every time we talked, my dear friend, Mike Beedle (RIP), would challenge me to think deeper about less conventional concepts that I wouldn’t normally consider having an impact on the subject matter we were discussing.  Often, Mike would come back to Employee Experience.

“Employee Experience,” he would say “is the where we need to focus in order to truly give our customers the amazing experience that we want them to have with us, as a company, and our products.”

Recently, the well-meaning practices of installing ping-pong and foosball tables, or game rooms, or a kegerator in the lunchroom, have come under fire.  Though these ‘perks’ to working in a space where at least someone is focusing on an aspect of Employee Experience (EX) seem great on the surface (mainly to new employees during the interview process), they don’t speak to the long-term EX.  They speak, mostly, to something I like to call Short-term Employee Gratification.

I want to reiterate, the people responsible for work-place ‘improvements’ like those already mentioned, are well-meaning.  But, like many good deeds, they don’t go unpunished.  Here, mostly because these Short-term Employee Gratification efforts are just that – short-term.

Long-term EX is about sustainability.  We see, in the Principles behind the Manifesto for Agile Software Development, that there has always been someone concerned with sustainability.

“Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”

So, why do even the best of us not understand that our actions are not having the intended effects?  Because we are HUMAN BEINGS, and we have this natural tendency to believe that when we ‘fix’ something, that it stays ‘fixed’.  In this case, when we make our employees happy, they should stay happy.

So, why don’t employees stay happy?  Because they are HUMAN BEINGS, and trying to get a human being to stay happy when nothing around them is improving, the morale suffers.

We talk a lot, in the Agile world, about the concept of Continual Improvement.  We also warn those whom we mentor, to only take on as much change as they can handle at any given time.  Trying to change too many things at once and realize which of those changes actually had a positive effect can be darn near impossible at times.

So, in this example, maybe just provide one perk at a time.  But, in all fairness, slowly rolling out toys for employees to play with at work … that’s still just a stop-gap measure to gratification, not a solution to improving the Employee Experience.

I now invite you to take a trip down memory lane with me.  The year was 2004.  I was working at a young company in Chicago, still relatively small at 100-125 employees.  We had a culture of freedom, not fear.  That would come later.  Our products were platforms and API’s for electronic traders (of stocks, bonds, future, options, etc.) to make trades quickly, setup their own custom automatic trading rules, and develop custom trade strategies.

Life was great!  For a while.  There were monthly bonuses for everyone, when the Sales department hit their quota.  There were free donuts and bagels once a week.  I believe that, for a time, there were even free soft drinks from the vending machines.  Our team even had full autonomy over who we interviewed, and who we hired.

As the company grew, and we grew quickly, these perks slowly disappeared.  Every one of them.  Until if we asked around, “Hey, do you remember when we used to have <perk>?”  The general answer was likely “That was before my time.”  But, in reality, it likely wasn’t before their time, they just didn’t remember it.

Let’s fast forward a bit through the ugly parts – fast growth in head count, demanding deadlines and the resulting loss in quality, stolen/lost autonomy, creation of a command and control environment, increasing number of periodic performance evaluations, and finally periodic layoffs.

The changes did not take long.  Two years at most.  But they, and their resulting culture, lasted for much longer.

I eventually left the company.  I knew I was a valuable part of my team, but I was extremely frustrated with many of the negative turns the company had made, as well as some of the decisions my immediate co-workers had made.  I needed to get out to preserve my sanity.  Or so I thought.

I let my manager know I had another job offer, and I had already accepted it.  I gave my two-week notice.  He begged me to stay.  I asked him “If the company values me so much, why doesn’t anyone feel this way?”

Two hours later I got a meeting request from the CTO.  I was to bring all of my improvement suggestions to him, for discussion, first thing the next morning.  Improvement suggestions?  The CTO!?!

I went home and immediately started writing down everything I thought was wrong with the company and how they could improve the working relationships with their employees.  From problems with retention of talent, to employee happiness, to wage inequality, etc.  It ended up being a 3 page long handwritten bulletized list.  I was proud and scared at the same time.

The next morning I handed the papers across the CTO’s desk, and we had a 3 hour long conversation about why I was leaving, the devolution of morale at the company, my unwillingness to stay, his failure (his words not mine) to his employees, and much more.  This is saying a lot about a man who repeatedly would blow off scheduled meetings and short people on their time to talk with him.  Our meeting was only scheduled for 30 minutes.

I left that meeting feeling extremely valued.  Exactly what I wanted all along.  I was shocked, because nowhere in those three handwritten pages had I even come close to mentioning that a deep face-to-face conversation, with the CTO focused on me as an important employee, was enough to restore my hope in the company.  But that did the trick!

Out of foolish pride, I left anyway.  I wasn’t always as enlightened as I am today.  I’m still not as enlightened as I wish to be.  So I made mistakes.  And I will make mistakes.  Leaving the company at that point was probably a mistake.

After I left the company, it took me six weeks to meet with the CTO again and ask to come back.  He agreed.  He wanted me to see the changes that he was making.

I returned to the office (with a raise and promotion) after 10 weeks of absence.  I found a foosball table and a conference room had been transformed into a game room (the newest Nintendo® and XBOX® game systems installed with many games for each).  These were suggestions I had made.

But during those 10 weeks of absence, I realized I was wrong three different ways.  #1 for leaving.  #2 my suggestions were based on short-term gratification. #3 I never brought up any of my suggestions at the times they occurred to me over the last several years.

Just as you might guess, these improvements, and a few more over a short period of time, had an immediate positive effect on employee morale.  But, long-term systemic change had not been addressed.  Frequent performance evaluations still remained.  Deadlines were a constant source of stress.  Development was not focused on building Quality into the product, so it had to be tested out of the product afterwards.  Layoffs became more frequent, and the culture of fear quickly resumed, after the shine of the foosball table dimmed.

The EX had only gotten better for a short period of time.  Eaten alive by the terrible system that was still in place.  Like painting and waxing a rusty automobile, without grinding away the rusty bits first.

Agility is defined slightly differently by almost everyone in our industry.  To me it speaks of a company culture that I would love to work in.  During my entire career, I can think of only a few years when I worked in an environment that I can confidently describe as Agile.  All other environments were either deviating further and further from Agility, or trying everything they could think of to get closer to Agility (with varying levels of short-term success).

While hearing Mike Beedle’s words about Employee Experience echoing in my head, I blend them with Craig Larman’s.  Craig saying that cultural change follows only if there is systemic change, makes clear sense to me these days.

Today, when large organizations want me to help them change their culture, I try to refocus them on their system and how they are providing a long-term gratifying Employee Experience.  Cultural change will follow, and thus Customer Experience.

Guidelines to hiring a professional Coach

Let’s face it, today, finding an experienced and credible agile coach, is not easy.  If you disagree with this statement, you are either very lucky and have special access to some great talent (e.g. referrals or networking) OR your perception of the role may need to change.
There is no need to be ashamed of not being able to find a good coach. You are not alone, many companies face the same challenge.
Truth be told, unfortunately, the industry has changed significantly  of the last few years and became the source of many problems (some very classic problems are described here).  Today, the term “Senior Agile Coach” has been grossly diluted. 🙁
But fortunately, there are still great standards and guidelines you can follow, when looking for an agile coach, irrespective of industry trends.  Please, consider the dimensions below, when looking for a professional agile coach, for your organization.  The original sources of these requirements are listed at the bottom of this page and you are encouraged to explore them for additional details.
Please, do not reduce, simplify or trivialize some of the key expectations of a professional agile coach.  Because, if you do, the following two problems will follow:
  • Industry coaching quality (average) will be further decreased,… and even if you don’t care about this fact as much…you will care about the next fact….
  • Quality of service to your own organization will be also low

…with that….


“Must-Have” for Professional Agile Coach

Quantitative Assets:
  • Has significant hands-on experience in at least one of the roles on a Scrum Team
  • Has coached multiple organizations, departments, or programs
  • Has, at least, 1000 hours of experience coaching at the enterprise/organizational level or a combination of enterprise and multi-team level coaching
  • Has diversity of coaching experiences that can be demonstrated, using different client engagement examples, and which include experience at the organizational level
Demonstration of deep knowledge:
  • Has formal and informal education about coaching and strong mentor relationships
  • Has good working knowledge of Agile and Lean values, principles, and practices.
  • Has helped individuals, teams, and leadership to understand and apply Agile and Lean values, principles, and practices effectively
  • Understands the dynamics, patterns, and development of multi-level teams and how they interact at the organizational level
  • Knows the difference between consulting and coaching and knows when to apply each.
Ability to clearly articulate and substantiate one’s own:
  • Coaching Career Overview (coaching, agile history and how a person got where he/she is today. Include key milestone years)
  • Coaching Focus (summary of a person’s professional self today, including a coaching approach and/or philosophy to coaching)
  • Coaching Goals (personal development goals in coaching)
  • Formal Coaching Education (formal education activities which have contributed significantly to your coaching journey. This includes a wide range of courses on topics including facilitation, leadership, consulting, coaching, process, tools, techniques, frameworks, and other related activities which have influenced our coaching practice)
  • Formal Mentor-ship Education (coach mentor-ship and significant collaboration activities where a person has DEVELOPED a skill or technique or RECEIVED guidance to his/her coaching approach and mindset.)
  • Informal Coaching Learning (significant topics you have studied outside of the Scrum literature which has impacted his/her coaching approach or coaching philosophy)
  • Agile Community Participation (agile community events, such as user groups, gatherings, retreats, camps, conferences, etc. in which a coach has participated)
  • Agile Community Leadership (leadership contributions to the agile community (e.g. writing, publishing, presenting, facilitating, organizing, training and other activities) through events, publications, courses, blogs and forums)
  • Agile Community Collaborative Mentoring & Advisory (significant collaborative agile mentoring, advisory activities, where a person was mentoring, advising other individuals to increase their competency or in development of a specific goal)
  • Coaching Tools, Techniques or Frameworks known (coaching tools, techniques or frameworks which you have implemented, customized, co-developed or developed in one or more client engagements)
Skills, Tools & Techniques:
  • Has contributed to significant improvements in organizations or departments through coaching techniques
  • Has helped organizations and teams beyond the basics of Scrum theory and practice
  • Has enabled organizations to find their own solutions to business problems through the application of Agile principles
  • Is familiar with, promotes and embodies the mindset of Servant Leadership
  • Uses a rich set of facilitation, training and coaching tools, and models
Personal Qualities:
  • Coaching Mindset Coaching skills/practices and frameworks
  • Evidence that the coach has taken both their Experience and Learning and synthesized these into definitive practices, frameworks, approaches, and strategies)
  • Self-awareness: Able to reflect on their own contribution to the coaching by virtue of their own ‘being’
  • Constant Learning: Has and continues to acquire Coaching oriented learning through multiple dimensions
  • Diversity of Experience with different types & sizes of organizations
  • Participation in the Agile community

Note: Your company needs to have internal expertise to validate a person, based on the above.


Resources:

Why Is LeSS Authentic? Why Should Leadership NOT Exempt Itself from Learning LeSS?

Large Scale Scrum (LeSS) is the agile framework that has a history of implementations, trials & errors, experiments and experience reports collected and documented throughout a decade.
LeSS is Scrum, performed by multiple teams (2-8) that work on the same widely defined product, for the same Product Owner.
LeSS stresses the importance of organizational descaling (a.k.a. flattening) that needs to happen before agility can be scaled.  The first LeSS book (out of three published so far) was written in 2008 and it had incorporated the ideas of its two authors, C. Larman and B. Vodde, by mainly including their own experiences of initial LeSS adoptions, from years before.
Overall, LeSS journey has begun many years before Large Scale Scrum has been officially presented to the world and recognized, as a framework, and this is important to acknowledge.  But why?    

Because LeSS, unlike some other very popular and commercially successful frameworks, that are very easy to ‘unwrap and install’, was not invented re-actively, as a “quick fix/hot patch”, in response to growing market trends and business needs (commercial driver).

LeSS is authentic.  LeSS took its time to mature and cultivate, as a philosophy and way of thinking, not as a revenue-generating utility.  LeSS did it at its own pace, without a rush, while incorporating learning of many coaches and companies that went through LeSS adoptions, over years.   LeSS has naturally “aged”, in a good sense of this word 😊.

Important Point: Whereas, deep learning of system dynamics and organizational design is equally available to everyone who attends LeSS training, not everyone can equally impact-fully apply this learning, when they go back to work.  But why?

Lots of LeSS learning (through system modelling, using causal loop diagrams) touches upon organizational elements, such as HR norms and policies, reporting structures, career paths and promotions, location/site strategies, budgeting/finance processes, etc. – things that are considered to be “untouchable” for an average person (employee).

Of course, it does not mean that an average person is not able to start seeing things differently (they definitely do!) after studying LeSS but it is just that he may not have enough power/influence to make necessary organizational changes that are required by LeSS.  In fact, for many people, this newly gained knowledge which is no longer possible to “unlearn” 😊 (e.g. ability think systemically), is accompanied by realization of one’s own powerlessness – and could be pretty frustrating.

Things are different for people that occupy higher organizational positions.  A senior leader is able to combine the decision-making power that is given to him by his organization and the power of newly obtained knowledge, coming from LeSS training.  These two powers, united, can have an amplified effect.

Notably, a senior leader who wants to apply LeSS learning to improve his organization must have something else that is very special, in addition to just having general curiosity of the subject and desire to experiment: it is called a ‘sense of urgency’.  The best examples of senior leaders that have learned LeSS and then applied learning to reality, came from situations, where the need to change was urgent and separated success from failure.  Then, if the above is true, the formula of LeSS adoption success becomes:

(Organizational Power + Power of Knowledge)  x Sense of Urgency = Success of LeSS adoption

Important Point: It is strongly not advisable for senior leaders to delegate LeSS learning to people that are below them organizationally and therefore, not empowered to make organizational changes. Granted, individuals at all organizational levels will be benefited from learning LeSS (it is a great eye opener).  But senior leaders – people that are empowered to make significant organizational changes, must attend LeSS training in person and not delegate attendance to their subordinates.  Leadership should not exempt itself from learning.
In fact, and ideally, senior leadership should attend LeSS training, accompanied by their respective organizational verticals, so that everyone goes through the same learning journey together.  Having HR and finance people, alongside with C-level executives and staff members of lower organizational levels – is a HUGE BONUS.

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)

2019 Big Apple Scrum Day Coaching Clinic – Highlights

2019 Big Apple Scrum Day (BASD) was an amazing experience for many – again!  The Coaches Clinic, supported by some top notch professionals in the industry, was one of the greatest hallmarks of the event – the tradition that has been maintained for the last 5 years.

Collectively, the coaches brought to the table lots of expertise, across multiple disciplines: organizational design, enterprise and team coaching, corporate culture, HR, business, DevOps/agile engineering, human psychology and other specialties.

Each coachee was given 15 minutes or more to share their thoughts, concerns or just ideas that required reflection and validation.  Throughout the daily course, the clinic has served about 35 people.

Below are some testimonies, coming directly from the coaches as well as some best Kodak moments:

Coaches’ Testimonies:

Zuzi Sochova, CST, Agile & Enterprise Coach:

“I had several conversations with people about their careers, about what is next, and it felt that the missing ingredients is a courage. The true agile value we all keep forgetting. The courage to brake the position structure and the prescribed career paths and create a brand new job for yourself. Don’t wait until someone opens a position. Design it yourself. Create a need for your skills and value you can deliver. Defined positions and career paths are over. They belong to the last century. In modern world the we need more emergent leadership, the flexible solution for an actual problem. And fixed roles only keeps status quo. You are a leader. Step out of your position box and create your own role, focused on value, allowing you to satisfy your dreams.”

Jim York, CEC-CTC, CST at FoxHedge:

“Another great turnout at the Coaches Clinic at this year’s Big Apple Scrum Day in New York City! My thanks to the attendees, sponsors, and organizers that make this one of the premier agile events on the east coast. This year marks the third year I’ve volunteered as a coach at the clinic. I had many good conversations with those who stopped by. If you were one of them, let me know how things turn out!”

Amitai Schleier, Agile and Development Coach at Latent Agility

“It was an honor to once again take part in the BASD Coaches Clinic. When people need advice or guidance for where or how to start improving technical practices, I’m happy to offer some — but only after I’ve asked enough questions to begin to understand where they’re coming from and what they’re up against. Fortunately, our 15-minute sessions are usually enough to find at least one insight, one recommendation, and one action. Yesterday’s Coaches Clinic was no exception. My appreciation to Gene and the BASD organizers for including me.”

Mary Thorn, Agile Practice Lead at Vaco:

“Coaching at the Big Apple Agile was an enjoyable experience. The attendees were educated in their questions and ready to be coached. They came curious with open ears. They left with possible solutions to help them in their day to day execution.”

Aleksandr Kizhner, Experienced Agile Coach at TEKSystems:

“Big Apple Scrum Day is a groovy place to meet people who share your passions and interests. It is a place, where you can meet your influencing people and heroes, a place – to share your ideas, learn something new and help others with your knowledge and experience.  One interesting thing that I remarked about how it felt: much more about actual practitioners of agile practices, rather than theorists or consultants. This was reflected in the attendees that I was inspired to meet, and I thank them all for sharing their interesting stories with me.
What was coming that might be game-changing in agile adoption 2019?”

David Liebman, Agile Coach at Eliassen

This was the fifth year that I have participated in BASD’s coaching clinic among a group of outstanding and dedicated professionals.  It is always a pleasure and an honor to be part of this group.  

The individuals who came for coaching continue to demonstrate a passion for Agile and the issues and concerns that they brought during this year’s clinic dealt with everything from how to facilitate Scrum events to differences in implementing various Agile frameworks.  

The most notable trend in my coaching sessions was the focus on applying soft skills to foster greater collaboration among the teams, stakeholders and executive management. This was expressed as the need to understand and level set expectations at all levels. It seems that although the basics of Agile practices seem to be better understood over the years the successful implementation of Agile remains an issue where this disconnect in understanding a major cause.  

I believe that as we continue to attempt to be Agile we are at a point where difficult conversations need to be had to ensure that we agree on what success means and what we need to do to be successful.  I am confident that we will reach our goals.”

Kodak Moments:

HR-Related LeSS Experiments – Deciphered

Large Scale Scrum has a history of more than a decade. The first book about LeSS was published by C. Larman and B. Vodde (the co-creators of LeSS) in 2008.  There were two more books on LeSS, subsequently written in 2010 and 2016.  There is no surprise, why the collection of LeSS experiments from the field is so valuable: the authors have documented many (more than 600) experiments, based on their personal experience with LeSS adoptions, as well as feedback and information collected from other organizational design consultants, coaches and early adopters of LeSS, around the globe.
Today, references to LeSS Guides and Experiments can be found in various places on the internet and intranet of many companies that have decided to experiment with LeSS.
This writing is about a small sub-set of LeSS experiments that are specifically related to HR norms, policies and practices. They are all listed in the guide (referenced above), under the section “Organization” and it implies that they are directly related to organizational design – the first-order factor that is responsible for success of LeSS adoptions and agile transformations, at large.
Experiments with Performance Appraisals:
Avoid… Performance appraisals – p. 273 — There is a lot of research and evidence, supporting that individual performance evaluations and individual appraisals that are linked to monetary rewards, are not an effective way to make individuals to become more efficient and productive.  When a manager appraises an employee, usually only one opinion in the room that matters: a manager’s.  Feedback that is delivered once or twice a year is not timely and therefore is hardly actionable by an employee, thus useless, for the most part.  Neither an individual that delivers an appraisal, not an individual that receives it – like the process.  The process, is also pretty expensive, as it uses a lot of company’s resources: it involves lots of documentation, coordination and men-hours spent by many people, from first-line management to HR.
It is worth noting that there is an indirect relationship between conventional Budgeting process and conventional Performance Management process – both of which harmfully feeding off of one another. This is described in the book “Implementing beyond Budgeting: Unlocking the Performance Potential“, by Bjarte Bogsnes.  In his work, Bjarte refers to performance appraisals as “legal trail for a rainy day”.

Avoid… ScrumMasters do performance appraisals – p. 275” —Just like performance appraisals done by agile coaches could lead to serious dysfunctions (page. 130), performance appraisals done by ScrumMasters are extremely harmful.  Drafting ScrumMaster into this role will create a serious conflict of interest and will hinder ScrumMaster’s ability to influence natural growth and evolution of learning among team members. Impartiality and neutrality of ScrumMaster is highly important; becoming an appraiser – takes away this advantage.  Only by remaining neutral and non-authoritative (performance appraisal is exhibition of authority) will ScrumMaster be able to help a team to self-discover, self-improve, and become autonomous in their journey to success.

“Try… De-emphasize incentives – p270.” | “Avoid… Putting incentives on productivity measures – p. 271.” — If achieving a higher productivity (output, velocity) is coupled with monetary incentives/perks or other political gains (typical of many companies that overuse scorecards, metrics, KPIs, RAGs), there is will be always attempts by individuals/teams to claim successes/achievements by ‘playing the system’, in pursuit of recognition and a prize.  For example, in pursuit of ‘higher productivity’ teams may start inflating estimates, to claim higher velocity or deliver work that is low in priority but simple to deliver – just to create an illusion of volume. Incentivizing ‘higher velocity’ is an invitation to moving from “low Fibonacci numbers to high Fibonacci numbers” during estimation.  (Also, see Addressing Problems, Caused by AMMS)

Try… Team incentives instead of individual incentives – p. 272 — The process of individual performance reviews loses its original meaning when people work on same teams, where swarming (working together on the same task) and collective ownership is encouraged.  Offering individual incentives to people would just polarize them and move in opposite directions, towards becoming selfish, individual performers and super-heroes. In cases such as these, people may be easily drafted into unhealthy competition with each other over claims of success, trying to privatize what should be owned and worked on collectively. Companies that continue incentivizing individual performance with monetary perks just continue widening the gap between “what science knowns and business does” (quote from Daniel Pink).

“Try… Team-based targets without rewards – p. 273” — Clearly, team-level behavior, is an extension of individual behavior.  Just like individuals could be inclined to ‘game the system’, so could whole teams, under certain conditions.  Just like individuals, whole teams could be drafted in unethical conspiracies to game numbers, in pursuit of meeting targets, or beating other teams (e.g. producing ‘higher velocity’), whenever monetary rewards are at stake.  It is absolutely necessary to set targets to individual teams that work on par with one another, for the same organization, it would be best to decouple team targets from team rewards.  The latter could be handled through, some sort of profit sharing formula, based on a company’s financial success that is traceable back each team’s work.
Experiments with Job Titles:
“Avoid… Job titles – p. 276 | Try… Create only one job title.  Try… Let people make their own titles – p. 277 | encourage funny titles” – p. 277 —In pursuit of job titles, individuals may also seek gaining authority and “upper hand” over their peers and colleagues.  This may lead to artificial organizational complexity and hierarchy, as well as a casting system.  Individual job titles can also polarize people and drive them in opposite directions, away from shared ownership.  It is for this reason that on agile teams (e.g. Scrum), there is only one title – Developer.  This approach encourages people to think of each other as on-par, as peers, and grow into T-shaped, multi-skilled, cross-functional, willing-to-swarm workers.  In situations, where some distinction between individual jobs is absolutely necessary funny job titles are recommended.  For example, instead of calling someone QA Tester, a person could be called “Bug Finder and Exterminator”
“Try… (if all else fails) Generic title with levels – p. 277” — If it is absolutely necessary to have title distinction (e.g. to signify different levels of seniority/expertize of individuals), try using a leveling system.  For example, Developer level 1(junior), Developer level 2 (mid-level), Developer level 3 (senior)…. However, care should be exercised, not to explicitly associate different title levels with different levels of pay.
Experiments with Jobs:
“Try… Simple general job descriptions – p. 278” – Do not overcomplicate job descriptions.   Precision in a description may lead to contractual perception of what a person should and should not do, in a workplace.  This may also limit a person’s willingness to step out of his comfort zone and learn other areas of work, other skills and becoming multi-faceted.  It may then further lead to “managing by objectives” that are based on detailed job descriptions, and subsequently bring about problems of performance appraisals, described above.  Complex job descriptions also have a tendency attracting underqualified external candidates, whose resumes are excessively long, as they are ‘tailored to closely match complex job descriptions’.  (Relevantly, attracting bad agile coaches, by creating inappropriate job descriptions is a known problem).
“Try… Job rotation – p. 279 | Try… Start people with job rotation – p. 280” — Give individuals opportunities to learn new domains, technologies, lines of business.  This is will reduce the risk of a person becoming uninterested/bored with his current job.  Further, by rotating from one job to another, a person may discover where he fits best and delivers most value.  By having this opportunity, a person will also have a higher chance of merging the gap between “having to do a job” and “wanting to do a job”.  This is especially important with newly hired people that have a limited industry experience (e.g. recent college graduates).
 Experiments with Hiring:
Try… Hire the best – p. 280 | Avoid… Hiring when you cannot find the best – p. 281” — Do not settle for less than “best people your money can buy”.  It is better to rely on fewer great people that you already have on-staff than bring on more under-qualified people, to speed up work, especially at the end of a project that is already late (Brook’s Law).  From a system thinking perspective if you are trying to increase velocity (output) by a scrum team and decide to do so by adding more developers that you procured on low budget (low pay will most likely buy you low-skilled developers), you will most likely reduce velocity, by having low-skilled developers introducing more bugs into a system. Please, see why.
Try… Team does the hiring – p. 281” — If you plan on hiring an individual to join a team, please make sure that a team does most of interviewing and vetting.  Through that, not only a person’s skills and experience will be examined but it will become more apparent if a person can organically jell with a team: if there is compatibility, chemistry and synergy with other team members.   Panel interviews by whole teams are usually much more effective, since they include practical tests, real-life simulations and hands-on exercises.  It also allows some people to observe, while others ask questions, and then rotate.  Try to reduce the level of influence that HR personnel and first-line management have on the process as much as legally possible.  This will reduce the amount of subjective, administrative, frequently bias and error-prone screening (refer to top of page 17).
Conclusion:
As a summary, please consider the following quote that describes sushi-roll-like organizational design in Large Scale Scrum (LeSS), by C. Larman (also, explained in detail in Agile Organization, as a Sushi Roll):
In it, HR policies is listed as one of the vital elements of overall organizational agility.

02/07 – LESS TALKS: MEETUP – Scrum Master, F/T Role @ JPMorgan

This was an amazing performance by Erin Perry of JP Morgan –  last night, at NYC Large Scale Scrum meetup. The highest ever, record-high number of RSVP-ed people: (108) – since the meetup’s inception in, 2015.
Erin spoke about the ‘guerrilla agility’ approach that she has experimented with her colleagues, while coaching the organization, without even calling it ‘agile’.  Before Erin dove into the journey of Scrum Master, being made into a full time role at JP Morgan, she demystified some most commonly known misconceptions about the role.

 

This is what Erin shared with the crowd about the most commonly known misconceptions around Scrum Master role:

  • “Mature teams don’t need a Scrum Master” — Erin brought up a great analogy from sports to explain why this is not true:  “Athletes and musicians at the top of their game are surrounded by coaches and trainers. Why do we think our development teams will grow past the need of them?”
  • “Scrum Master is an administrative role (that consists of maintaining JIRA,running the daily stand-ups, reporting in the scrum of scrums, and facilitating meetings)” — This is very commonly seen in organizations but it is wrong perception.  Trivializing/reducing the role of Scrum Master to JIRA-Master-Admin is the sign of deep misunderstanding of Scrum, as a framework and and Scrum Master, as a role.  Administrative tasks are best rotated through the team to allow the Scrum Master to focus on the deep coaching needs of the Product.This is frequently seen in companies that are trying to ‘fit agile’ in their otherwise archaic organisational design, without making much of an effort to change the ladder.
  • “Scrum Masters are non-technical” –  Although many great Scrum Masters are not fully capable coders, many very experienced and effective Scrum Masters are hands-on developers.  Even if someone starts off as non-technical Scrum Master, it is great if that person has aspiration to learn new things and acquire some basic technical skills (especially, if Scrum is used in software development environments).
  • “Scrum Master is a junior role” – Deriving from Erin’s talk, this is probably one of the biggest evils in the list of common misunderstandings about the role of Scrum Master.  This critical misunderstanding alone, to a large extent, is also responsible for depreciation of Agile coaching profession in a market place.  This is how:   Scrum Masters are underpaid because companies don’t value the role high enough >>> Instead of honing their craft, as Scrum Masters, people try to ‘upgrade’ themselves (on a resume) to Agile Coaches too soon  >>> under-qualified Agile coaches flood the market,  get hired and set a low coaching bar for companies >>> coaching profession deteriorates further >>> companies stop seeing value in real, experienced organizational coaches >>>there is nobody, really, to provide good coaching and mentoring to existing Scrum Masters that are at the beginning of their career journey >>> Scrum Masters don’t ‘grow’ in their profession >>> Scrum Masters get frustrated with their role and low pay >>> and the cycle begins again…It’s the same dysfunction we saw in the last two decades with developers and the architect role. Scrum masters should become great scrum masters, not aspire to a “promotion” to agile coach. 
    • [Author’s note: This is what has produced so many Chief-Sheriffs-Power-Point Architects: individuals that tend to tell others what enterprise architecture should look like, without actually doing any hands-on development]
  • Career path for Scrum Master inevitably requires climbing up the organizational ladder” – This is another huge misconception about Scrum Master role.  Compensation and organizational seniority should not be coupled to to the pursuit of promotion to Coach, or Team Lead, or Manager.  A person should be comfortable to build expertise in Scrum Master role, passionate about it, grow within the role, and an organization must provide a healthy habitat for this to be possible (providing fair compensation is one of key things).  Erin stressed how this dilemma is swiftly addressed in Large Scale Scrum, where Scrum Master is viewed is a very senior and experienced role, whose focus changes over time. The difference between Scrum Master path Myth vs. Reality – is illustrated below.

This is how Erin has exposed some most common misconceptions about a career path of Scrum Master:

 Avoid This (Myth) Try This (Reality)

 

It has been a great pleasure (and honor) to host Erin’s presentation to the LeSS community of NYC.  Her views on Scrum Master role and career path are very much in line with my own and are strongly supportive of what is recommended in LeSS.  The way Erin sees Scrum Master in LeSS (as a very seasoned, experienced and well-versed practitioner) and how sheelevates the role to the level of a team-level coaching, also brings back good memories of our past collaboration, when we together summarized, for the benefits of a global coaching community, what the role of agile coach should be (please, refer to 2015 “Agile Coaching –  Lessons from the Trenches“)

 


Special thanks to Khalid Sultan, Raghu Raghunath and John Bradley for sharing their graphics and notes, and to Jim Dermend for his real-time tweets (below):

 

Download presentation