Category Archives: Norms & Principles

03/30 – LESS TALKS: Virtual Collaboration & Facilitation Lab – Part 2

One of the most powerful techniques to understand organizational design and dynamics is to model them, with your colleagues, in front of a white board. Not according to ‘best practices and cook books 😉 but based deep system thinking and shared understanding, by all participants.

But what if you cannot get together in front of a white board???

Miro Board In combination with Zoom (shared session & team rooms), will give you an opportunity to collaborate on-line – together by diverging into teams and converging in a large group. Lets try this together!

Since Large Scale Scrum (LeSS) is NOT a ‘methodology’ or ‘set of tools’ but an organizational design framework, system modelling is its critical part. But even if it was not for LeSS, understanding the way your system (e.g. enterprise) behaves could be very powerful.

Please, note, once you learn this stuff, you will not be able to ‘unlearn’ it and your knowledge could be viewed by others, as dangerous 😉 (and frustrating to you).

In this session, we will try bringing real life system modelling conversations (please, see examples of images from past LeSS training below to gain understanding) into a virtual session.

Examples of real-life CLDs:


Some Best Coaches May Face Some Biggest Challenges. Why?

Have you ever found yourself in a situation, where you feel that you have so much great value to bring to your potential client, that you are so much better than anyone else they may have considered for the role so far …. yet, a client is hesitant to bring you in. Why?

 First, You Must Self-Assess:
  • Are you a professional trainer, coach and organizational design consultant who had  spent many years honing his/her craft and investing in self-development? Do you consider yourself a life-long learner who openly speaks about it?
  • Over years, have you earned some highest industry-recognized accreditation that represent your professional journey? Do you make it explicit and visible publicly (e.g. LinkedIn, your web site)?
  • Have you, not only read dozens of books and case studies, but also authored or co-authored some on your own? Do you blog, write articles about your experiences and beliefs?
  • Do you speak publicly (webinars, conferences), have your own web site, where you offer free educational information to communities? Do you have tens of thousands followers in the industry, attending to your events, reading your newsletters and benefiting from your expertise?
  • Are you a one-person entity that you have relentlessly built over years?   Are your responsible for your own networking and business development, along with providing community service (this usually, always keeps you busy at nights and on weekends), ON TOP of your paid work?

If you answered ‘yes’ to most of the above, you are actually might be facing against some potential challenges.

What Are Some of Your Potential Challenges?
  • When trying to engage with a client, if you sound very knowledgeable (even if it comes so natural to you), you might be creating an inflated impression about what your aspirations and intentions are. Without any intention, you could be perceived as someone who wants to come in, take over, set your own tone, and run a show.
  • If you attempt to impress others with your knowledge too soon, the effect could be the opposite to what you expect: you  might be putting in an uncomfortable position people that you interact with, some of which could be much less experienced than you, unable to speak at your level, and perhaps even aiming at your future role, because their old roles had been being downsized (Larman’s Law #4). This is not so much a problem with senior management but quite common with first-second level manages and single-function roles (e.g. BAs, manual testers) that are sometimes asked to validate/interview you initially.
  • You might be competing against a very large population of external candidates-consultants that are usually procured through staffing agencies/traditional preferred vendors, and presented as “coaches” (today, coaching is a highly commoditized and heavily overloaded term). In reality, such candidates are coaches in name-only (a.k.a. coaches-centaurs). They are willing to engage at a deeply discounted rate and are easily augment-able into an existing reporting structure (seamlessly fit an existing staffing model) just like any other, traditional “human resource”. Once in, they typically become individual performers (e.g. tool administrators, backlog stewards, or metrics collectors) – a classic coaching anti-pattern.
  • You might be trying to enter into a client company’s domain that is tightly controlled by a large consultancy that already brought in their own, very expensive resources, installed their own, home-baked ‘best practices’ that are presented in the form of heavy power point decks and cook books. Even if you have a lot of experience with such best practices, unless you explicitly express your strong support for them, at the time of initial contact with a client, you might be perceived as a challenger and corporate unfit.
  • Although the most generous rate of a highly experienced independent professional (we assume, you are reading this now) is just a fraction of what a large consultancy would be charging a client for each placed consultant, if you cost more than a coach-centaur (described above), you may put yourself out of range.
What Can You Do to Mitigate These Challenges?

First and foremost, remember: there is only one chance when you can make your first impression!!! You are lucky if you will have a second chance.

  • Try to understand, really well, what a client’s real goals and aspirations are. When you meet a client, even for the first time (first interview or just an informal lunch meeting), listen to THEIR concerns and feel for THEIR pains.  Keep your strong views to yourself and tone down what you  may know: do not overwhelm a client.  At times, a client will not be explicit with you about their real problems, so you may need to read between the lines, ask probing questions. But be careful, how deep you probe.  Don’t become too obvious.
  • Do not up-sell yourself. Do not speak about your own qualifications, credentials or past successes (unless it is absolutely necessary or you are being asked).  Of course, it would be amazing is someone paved a road for you and spoke about you highly, so that you have a fair representation😊.  If you have to refer to your past experiences, present them as circumstantial and based on past conditions (try not sound absolute and categorical).
  • Always remember that when you meet a client, you are on THEIR territory, and eventually, you will leave and they will own everything you have done for them.  You may not even have a chance to claim a credit for your work, because its results will be seen only after you are gone.  Therefore, be very explicit about your intentions upfront, of NOT wanting to ‘take over, become a hero, challenge everyone and change everything’.   This could be a tough one, because at times, against your own will, you could be viewed as a leader-challenger, due of your perceived seasoning and expertise. You must make a client comfortable that you will respect their territory and their decisions and you are there to serve THEM.
  • During your initial interaction with a potential client, even if you discover something that makes you feel that an immediate course correction is required, refrain from stating this too soon (unless you are explicitly asked to provide your own view). It would be wiser to offer assurance to a client that you are seeing a lot of potential of working together and ready to support them in any of their efforts. Then, only after you fully engage and dig in, you should start gently steering a client in a right direction by, reflecting on what you see, and offering alternatives, as needed.

In summary, being a highly qualified and experienced professional does not automatically quality you as, as the best candidate to be selected.  There are many situational conditions that must be considered while interacting with a potential client.  Often times, not all your assets and resources should be revealed at once and to everyone.  You may have to be strategically smart in your pursuit and goals, even if your intentions are most genuine and it feels that you just have to be yourself and hold nothing back.

03/03 – LESS TALKS: Meet Ron Jeffries & Chet Hendrickson @ LeSS NYC (‘Dark Scrum’ and more…)



First and most importantly: Ron Jeffries and Chet Hendrickson are long time friends and colleagues who both had a huge impact on what defines AGILITY.
About Ron:

Ron Jeffries is author of Extreme Programming Adventures in C#, the senior author of Extreme Programming Installed, and was the on-site XP coach for the original Extreme Programming project. Ron has been involved with Scrum, Extreme Programming, and Agile for over ten years, presenting numerous talks and publishing papers on the topic.

Ron is the proprietor of www.XProgramming.com, a highly-ranked source of Agile Software Development information. He was one of the creators, and a featured instructor in Object Mentor’s popular XP Immersion course. Ron is a well-known independent consultant in Scrum, XP and Agile methods, recently specializing in helping Scrum teams get Done-Done.  Ron is one of the original authors of the Agile Manifesto.  Read Ron’s post on ‘Dark Scrum’ at: https://ronjeffries.com/articles/016-09ff/defense/

About Chet:

Chet Hendrickson has been involved with Agile Software Development since 1996, when as a member of Chrysler’s C3 project he helped develop Extreme Programming. In 2000, Ron Jeffries, Ann Anderson, and Chet wrote Extreme Programming Installed. It detailed XP’s core practices, how to do them, and how they work together to help teams be successful.

Chet is the first signatory to the Agile Manifesto.

Since 2002, Chet has been an independent consultant, coach, and trainer. In 2009, he was asked by the Scrum Alliance to help develop the Certified Scrum Developer program. Chet and Ron Jeffries taught the first CSD course and continue to offer them in the United States and Europe. He has been a Certified Scrum Trainer since 2009.

Ron and Chet were the curators of the Scrum Alliance’s Agile Atlas website and in that function created the Alliance’s official Scrum description, Core Scrum.

Chet and Ron Jeffries often work together and are popular conference speakers, bringing an interesting mix of humor and deep knowledge, and the odd cat picture. The are a fixture at the Agile Alliance’s annual conference, Agile 20xx, as presenters in the Stalwarts track.
Last year, Chet attended Craig Larman’s LeSS class in NYC and this is what he had to say:
http://www.keystepstosuccess.com/2018/06/may-30th-june-1st-certified-less-practitioner-course-with-craig-larman-nyc/


02/27 – LESS TALKS: Q & A on “The Spotify “Model”: Don’t Simply Copy-Paste”, with Evan Campbell



Recently, Evan  Campbell wrote an article on SolustionsIQ site: The Spotify “Model”: Don’t Simply Copy-Paste.  It resonated strongly with  many people. This LinkedIn feed alone attracted more than 23,000 viewers and it is growing.

On February 27, Evan was a guest-speaker at Large Scale Scrum (LeSS) meetup of NYC, answering questions about his views and the writing.  The video recording and transcript with live questions are below:

Top 5 Questions submitted before the session:
  1. Evan’s article talks about many large companies blindly adopting the Spotify model, because this is the strong recommendation they get from large consultancies. Are there any examples, at least, when such recommendations were followed and implemented successfully? It seems that ING success is overly inflated.
  2.  In the article, there is mentioning of hard-line reporting within the “chapter” or the “tribe” structures? It means that historical/orthodox challenges of organizational design persist in new “agile” structures. Could you elaborate on that?
  3. In the article, there is mentioning of random consultancies’ PowerPoint solutions, in which a heavy deck is the most important asset delivered. It is often delivered by a consultant who has very little industry experience, yet presents from the deck ‘as if’ it was the best known practice. Any comments on that?
  4. Our organization is big and one-team Scrum is not sufficient. If Spotify is not the right solution to scale, then what is?
  5. Our company was advised to adopt Spotify model. Today, some of old vertical organizational structures (e.g. QA department, Architecture group) have become chapters, and people are mandated to be a part of those chapters. Used to be managers, are now chapter leads. Nothing seems to be changing. What are your thoughts on this?

Discussion of Two Agile Coaches (Erin Perry & Gene Gendel): Uncomfortable Topics Addressed



Erin Perry and Gene Gendel (his site) have known each other for almost a decade through past work and continuous networking.  They both had agreed to have a candid talk about some of their personal work experiences.  The whole recording is about 35 minutes. But there is no fluff. This is slides-free dialogue of two experienced coaches, with many years of industry experience. Erin and Gene are exposing some most pressing  and somewhere uncomfortable topics.

Topics addressed:

  • How do you keep your head up when you’ve seen agility rolled back or stopped over and over again?
  • What mistakes are you seeing over and over again with large scale agility?
  • What are some of the biggest external challenges that organizations face today, with respect to agile guidance (e.g. low quality agile staffing,  big consultancies)?
  • Why organizational agility is in jeopardy, when there is heavy reliance on external vendors (development & testing) that are not familiar with agile, beyond knowing how to spell it?  What could be done to mitigate this problem?

02/18 – LESS TALKS: Tsvi Gal, CIO/CTO @ multiple Fin-Techs: sharing experiences about organizational agility



Tsvi Gal is an accomplished technology business leader, the winner of the Einstein Award for technology excellence.  Tsvi had served as CTO and CIO at a number of large enterprises: Morgan Stanley, Bridgewater Associates, Deutsche Bank Investment Banking, Time Warner Music Group and other companies.  Tsvi has extensive experience in technology and operations, mostly in financial services, media and telecom.
In his recent career, Tsvi led the divisional Agile & DevOps transformation and the changes to the ways of work in technology, workforce strategy and front-to-back initiative.

Some questions presented & answered:
  • When someone wants to transform, it implies that there is a need to transform (change). What were some of the most pressing needs, in your experience, to go through changes? Something did not work? Was not efficient? Other?
  • How many people were involved in the transformation? How long did it take? Who was spear-heading this effort: internal coaches, external coaches, mix of both, PMO, etc?
  • How did you address HR related issues that frequently arise when agile teams are being stood up: individual performance appraisals, bonuses, promotions, career path?
  • Who provided guidance to technical excellence during the transformation? Technical coaches (internal, external)? Were teams using TDD, CI/CD?
  • Did you use any known agile frameworks ro scaling approaches? Or was it all internally defined?
  • DevOps vs. DevSecOps? Any difference? Is it dev practice or org. silo?
  • HR is years behind, when it comes to agility. Why? Do not blindly copy & paste (e.g. Spotify model)

02/11 – LESS TALKS: Nicolas M. Chaillan, US Air Force Chief Software Officer On Technology Agility, Scaling and More

On February 11, 2020, NYC Large Scale Scrum (LeSS) meetup was honored to host the event for a special guest-speaker Nicolas Chaillan – the first Air Force Chief Software Officer.  Nicolas is also the co-lead for the Department of Defense Enterprise DevSecOps Initiative with the Department of Defense Chief Information Officer. His full bio is available here.

Presentation Slides

CSO Memo on Agile – and SAFe, by Nicolas M. Chaillan (US Air Force Chief Software Officer)


Run This Method Through Organizational Compiler



Running this method through an “organizational compiler” may improve health of your organization: (variables are “globally declared” and clickable hyperlinks. You can pass any arguments to this method, as long as they are valid arguments 🙂 )
public class LegacyOrganizationalEcosystem { 
public static void main(String[] args){
if((agile_framework == this_framework{ 
System.out.println ("Simplify your organisation.
Try scaling agility by de-scaling complexity")
} 
else if (agile_maturity_goal == this_goal){
System.out.println ("Stop chasing numbers. Self-assess, systemically")
}
else if (agility_measurement == this_measurement){
System.out.println ("Stop internal competition. Recognize command & control behaviors through system modelling.")
}
else if (coaching_model == this_model-left_side){
System.out.println ("Avoid locally optimized for coaching ivory towers and Agile CoEs.")
} 
else if (agile_coach == this_coach-right_side){
System.out.println ("Beware of 'quasi-coaches'.")
}
else if (agile_coach_career_path == this path){
System.out.println ("Get REAL, experienced coaches with effective coaching approaches")
} 
else if (agile_knowledge_basis == this_certification){
System.out.println ("Avoid certification collectors. Be cyber-vigilant.")
} 
else if (talent_acquisition_model ==  this_model){
System.out.println (" By-pass staffing agencies. Select vendors diligently and responsibly.")
}
else if (architecture_expert == this_architect){
System.out.println ("Avoid 'power-point' architects.")
}
else if (prod_owner_team_communication == this_comm){ 
System.out.println ("Remove translation layers. Learn about benefits of feature teams through gaming.")
}
else if (prod_owner_sm_relationship == this_relation)
{
System.out.println ("Avoid faking Scrum roles. Understand Scrum roles through system modelling.")
} 
else if  (scrum_pattern == this_pattern)
{
System.out.println ("Recognize Scrum anti-patterns.")
} 
else if (sprint_naming == this_convention){
System.out.println ("Avoid Sprints without PSPI. Understand and expand product definition.")
}
else if (customer_request == agile_requirement){
System.out.println ("Avoid 'agile' BAs and BRDs.")
}
System.out.println (“Overall, your organization may need a refresher on what agility truly means :). You may enjoy sharing this” + anecdote + “ with your colleagues and play this”+ game +” at your next town-hall meeting.”)
}
 }

 

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.