LeSS Adoption Principles and Approach @ Enterprise Agile SF Bay Area

LeSS was initially ‘mislabeled’; when it was called a scaling framework.
It is a descaling framework.It is also, organizational design framework that helps to address core elements of organizational design: HR policies, finance/budgeting, vendor management, site strategies – areas that are not too comfortable for many companies to address.System and Lean thinking drive understanding of LeSS.
LeSS is not about: ‘best practices’, maturity metrics, RAGs, KPIs, tools, and operating models.LeSS 3 adoption principles are:
1. Deep and Narrow (not broad and shallow)
2. Top – Bottom + Bottom – Up.
3. By Volunteering onlyWhat does this mean?Some uncomfortable questions that will be answered:
1. Why so few agile trainers and coaches truly understand LeSS and
teach it to clients?
2. Why large consultancies don’t bother teaching LeSS to their clients?
3. Why LeSS adoptions are not so widespread?

More about LeSS: https://less.works/

Classic Anti-Patterns During Scrum Events

Below, are some more commonly observed anti-patterns, seen in Scrum. The list in is not conclusive.

During a Sprint
  • Too many people (beyond 3-9 recommended in Scrum) consider themselves as ‘team members’.  Entire functional groups (component teams) that belong to the same reporting structure consider themselves, as teams.
  • Managers, PMO and other marginally involved in work people get involved
  • Too many unresolved/undiscovered external dependencies on groups and individuals that work outside of Sprint.
  • Team members have only partial dedication to Sprint and do side-work, elsewhere.  People that contribute to Sprint work are not on a team
  • Sprint duration is not consistent: sprints are shortened or made longer.   Sprints are too long (> 30 days)
  • Scrum Master is passed around from one person to another as a “hot potato”, due to the fact that nobody is able to perform the role well.  Common reasons: lack of Scrum knowledge, lack of comfort with raising dysfunctions, seeing no personal benefit in performing the role.
During Daily Scrum
  • People, arriving late to a meeting that is very short, to begin with
    People, attend remotely, with poor connection and no visual support
  • Daily scrum, becoming a status report, where team members ‘report’ their deliverable to Scrum Master (or someone else, who self-invited, e.g. manager, PMO)
  • Some people are overly talkative; others very silent
  • Too much focus and updates of electronic tools, taking time from a meeting. Scrum Master, becoming tool specialists” / administrators, making updates, on behalf of others
  • Team members, are not being able to clearly articulate/express themselves
  • Deep dives into detailed discussions OR… Referencing to ticket numbers only, without sharing meaningful content
  • Refinement backlog items or planning of future sprints
  • Command & control behavior towards team members, from Scrum Master or among team members, e.g. direct task assignment
  • Product Owner comes uninvited and takes over a meeting
  • Monologues, arguing, disrespect, excessive feedback, loss of focus and orientation
During Sprint Planning
  • Product Owner did not clearly articulate to a team sprint goals
  • Work proposed for next Sprint is not well refined
  • Not enough effort is made to validate that planned work is really doable (DoR is not met)
  • Planned work has strong (and asynchronous) dependencies
  • Planned work by far exceeds a teams capacity (overall, skill set)
  • Team’s planning is treated as a hard commitment
  • No (or little) indication that the whole team plans together (everyone plans their individual work)
  • Product Owner is not explicitly informed about what a team is planning to work on
During Product Backlog Refinement
  • Product Owner is not present and/or sends in a ‘proxy’ or BA, instead
  • Not all team members are present. OR… too many people join, including uninvited guests
  • Refining backlog items that are low in priority
  • Too much focus on generating estimate numbers, not on shared understanding, a.k.a. as CCC (card, conversation, confirmation)
  • Attempts to solve/implement backlog items. Spending too much time on “how to build” details, instead of understanding “what to build”
  • Keeping Product Owner and stakeholders in a meeting, beyond their interest (e.g. technical discussions)
During Sprint Review
  • Meeting is made extremely short and treated as a formality (‘Scrum mandate’)
  • Review turns into a ‘town-hall’ with political agenda, instead of being a working session
  • Product Owner and/or key stakeholders/users are not present
  • Team shows, a ticketing system (mostly), power points or lines of code, instead of working software
  • The same person “shows” and takes all the credit for a team’s deliverable
During Sprint Retrospective
  • No feedback from Sprint Review is taken in
  • Managers, Product Owner, others – come uninvited
  • Lack of safety and comfort in a meeting. Too much hostility
  • Too much political correctness and lack of openness
  • Same people speak up. Same people remain silent
  • Same impediments are being raised in each Retrospective, nothing gets resolved

April 20-22 & 22-24: Certified LeSS Basics (CLB) Courses | Virtual

Class April 20-22

System modeling work in class.

Note: the below graphics are not conclusive decisions or ‘best practices’. They are just an example of brainstorming, based on each teams members’ experience.




 



Class April 22-24

System modeling work in class.

Note: the below graphics are not conclusive decisions or ‘best practices’. They are just an example of brainstorming, based on each teams members’ experience.

Next virtual LeSS Training:

How to Identify “Agile Masquerades”? What Alternatives Could We Offer Instead?

My (Gene is here) great opportunity to present at Agile Coaching and Beyond meetup, of Bucharest, Romania on April 21st, 2020.  Many thanks to Amir Peled for having me on the podium. Great crowd and questions.

Presentation Materials

Some of the most salient points in the presentation:

  • Are you relying on quality talent to assist you with your agile transformations?: a quick (~10 min) recap of Gene’s presentation in Phoenix, AZ about the most classic dysfunctions related to the coaching profession
  • Misunderstanding of agile coaching role – Why organizations get this part mostly wrong?
  • Talent dilution, industry-wide – Why are there so many inexperienced agile coaches in the market?
  • “Bad business“ – Why reliance on staffing firms and head-hunting agencies for agile talent procurement causes more harm than good?
  • Fallacies of big solutions – Why Big Bangs and ‘all–at-once’ transformation attempts are ineffective?
  • Centralized coaching towers – Why creating ‘Centers of Excellence’ and enforcing ‘best practices’ and ‘operational models’ leads to local optimization? Why placing such ‘org constructs’ inside ‘standard’ power structures (e.g. Architecture tower, PMO) further worsens the situation, while jeopardizing individual safety?
  • Rebuilding vertical organizational towers horizontally – Why ‘flipping’ conventional functional areas of control (e.g. QA department, BA group, PMO) on their side and calling them ‘Communities of Practice (CoP)”/chapters/guilds, while preserving reporting lines and other conventional dynamics (e.g. still doing individual performance appraisals by community/chapter/guild, leads to negative outcomes) is the same, as “rearranging deck seats on Titanic”?

 

Next virtual LeSS Training:

04/20 – LESS TALKS: Dave Snowden: Rewilding Agile

David Snowden divides his time between two roles: founder Chief Scientific Officer of Cognitive Edge and the founder and Director of the Centre for Applied Complexity at the University of Wales. His work is international in nature and covers government and industry looking at complex issues relating to strategy, organisational decision making and decision making. He has pioneered a science based approach to organisations drawing on anthropology, neuroscience and complex adaptive systems theory. He is a popular and passionate keynote speaker on a range of subjects, and is well known for his pragmatic cynicism and iconoclastic style.


Materials to Download

Additional resources from Dave:
Very salient spots in the recording:
Snippets from Dave’s talk:
  • You must understand the difference between Correlation vs. Causation, in order to understand eco-systemic dynamics
  • Cookie-cutting approaches don’t work. Forced homogeneity does not work.
  • Fallacy about SAFe and Spotify
  • Consultancies, are a part of revenue-generating schema, when it comes to installing large frameworks
  • When millions are spent on SAFe installations, nobody will admit of failures. People that make decisions about installing SAFe are long gone before responsibility for actions needs to be taken. People that think that it could work, ignore it for the most part and just do things that matter most
  • Ask Spotify, why NOT to use Spotify “model”
  • Beware of snake oil versioning of management: 1.0, 2.0, 3.0, 4.0, 5.0, etc
  • Forecasting of COVID impact on big consultancies
  • You dont scale a complex system, by aggregation or imitation but by decomposition and recombination
Synopsis

Agile started off as an inspirational set of statements and values that inspired a generation of software design. But slowly and steadily that original inspiration has become a set of structured methods, certificates for turning up at a course and a series of method wars which have most recently degenerated to court action. How do we rediscover the original inspiration of the Agile Manifesto and in a very real sense return Agile to the wild. Is it time to move away from the large scale expensive frameworks into a multi-methods, multi-tools ecosystem and to create a new professional practice? In the current crisis agility is not enough …


 

Next virtual LeSS Training:

April 15-17: Certified LeSS Basics (CLB) Course | Virtual

Another engaging and highly interactive Certified LeSS Basics (CLB) virtual class is complete.   People attended from many corners of the map: NY, NJ, FL, MO, IL, NC, Peru, Bangladesh.  The students engaged in a highly interactive collaboration, with questions and exercises, using Causal Loop Diagram (CLD) technique, exploring the following topics: Agile Big-Bangs, Internal Contracts, Local Optimization, Product Definition, Fake Projects/Programs/Portfolios, Scrum Master Role, Fooling with Tooling.
Note: the below graphics are not conclusive decisions or ‘best practices’. They are just an example of brainstorming, based on each teams members’ experience.
System Modelling: Agile Big-Bangs
System Modelling: Local Optimization
System Modelling: Internal Contracts
System Modelling: Product Definition
System Modelling: Fake Pro-jects/grams
System Modelling: Scrum Master Role

Exploring the Role of the Product Owner & Scrum Master through LeSS

The role of Product Owner and Scrum Master are very clearly defined in the Scrum Guide.
But the guide does talk about these two roles in a context of complex organizational settings, where products are large and many people are involved in product development.
What happens then?

Large Scale Scrum (LeSS) has some answers. LeSS is an organizational DESIGN framework, where a single team – is a long-lasting, organizational building block.In this session, Gene Gendel (Certified LeSS Trainer and LeSS Coach), will share some insights about the role of Product Owner and Scrum Master in LeSS:
• Responsibilities
• Communication
• Organizational positioning
• Career path
Note: prior to attending this session, please review the following pages on less.works site:
https://less.works/less/framework/product-owner
https://less.works/less/framework/scrummaster

04/14 – LESS TALKS: CTO of JPMorgan – Sharing His Views About LeSS Experiments

An accomplished senior technology leader in the financial services industry, Al Youssef shares his views on some LeSS experiments.

Play Recording below:

Questions raised (copied verbatim from Zoom chat script):
  • For enterprise projects, compare and contract LeSS vs SaFE 5.0 -Were the automated tests all functional? or did you also have performance testing? Did you create these as part of your development process or as a separate project?
  • 1n the Machine Learning Data Science Space, are there any unique ways needed manage these projects? -Since their change to LeSS where are they in your adoption? Also how many IY Mangers do they have in his organization. Why I ask? because Craig Larman states 1 IT Manger to 100 scrum team members.
  • What did you do to change structure to support a culture focused on technical practices and provide safety for craftsmanship. (i.e. How did you avoid the contract game? How did you ensure any functional managers were focused on serving those they had the privilege to lead? What did you do about the force ranked performance management system? How flat did you make the development organization? Did you modify the outsourcing arrangements, if so how? What have you done to ensure the technical design authority members on the various feature teams are not counterproductive to self-organization within each feature team?)
  • With only one backlog…how do you deal with situation where the tasks do not match with technical capabilities of the available teams? -One common code base: does it mean you practice a trunk based development?
  • How do you handle the integration testing – is there any coordination done from outside of the teams or is it somehow responsibility of the feature teams to raise their hands when they feel that some testing is not covering some of their features? -Could you describe the scope of the platform a bit more? What are broadly its capabilities? Did the team also have to build the IaC layer?
  • What do you do to prepare your developers to interact effectively with your design authorities and architects? -How did you bring your business stakeholders on the journey to identify and train their team members to bring them in to the role? Do they report to a manager in technology or the business?
  • How do you measure the business value of what is produced as a data team? Do you observe the end to end value?
  • Are your teams all full-stack developers, or do you still have specialized technical roles within the pods? -How does the line organization look like (resource pools?) and how do you shape the mid- / long-term skill profile of the IT department? – are the agile team members part of some resource pool organizations or is the agile team also their home from line perspective?

Engaging and Being Engaged as a Professional Coach – Candid Advice for Coaches & Clients

Key Takeaways

  • There are things that coaches need to do prior to engaging with a client company
  • Coaches need to know about challenges they might be facing while trying to engage with a company
  • There are some practical things coaches and companies can do to set up the engagement for success
  • Things that hiring companies need to know about a coaching profession
  • Advice for hiring companies to not shut doors (intentionally or unintentionally) in front of experienced coaches, without opening up flood gates for charlatans, cheer-leaders, and ‘best-practices” experts

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?…

Read more on InfoQ

April 09-10: Certified LeSS Basics (CLB) Course | Virtual

Another engaging and highly interactive Certified LeSS Basics (CLB) virtual class is complete.   People attended from many corners of the map: UK, USA, Canada, Argentina, Spain, Kuwait, Australia.  The students engaged in a highly interactive collaboration, with questions and exercises, using Causal Loop Diagram (CLD) technique, exploring the following topics: Agile Big-Bangs, Internal Contracts, Local Optimization, Product Definition, Fake Projects/Programs/Portfolios, Scrum Master Role, Fooling with Tooling.
Note: the below graphics are not conclusive decisions or ‘best practices’. They are just an example of brainstorming, based on each teams members’ experience.

System Modelling: Agile Big-Bangs
System Modelling:  Internal Contracts
System Modelling: Local Optimization
System Modelling:  Product Definition
System Modelling: Scrum Master Role
System Modelling: Fooling With Tooling
System Modelling: Fake Projects, Programs, Portfolios

More Kodak Moments

Next Training Series: