Category Archives: Team Dynamics

ALI in partnership with Agile Beer presents: LeSS – A Descaling Framework

A great opportunity to present to two Ireland meetups, at once:
Agile Lean Ireland and Agile Beer.  More than 150 people joined, with many great questions.

Synopsis:
Although LeSS is a scaling framework, in reality it requires organizational de-scaling.  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 only


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

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:

04/07 – LESS TALKS: Irony With Fake LeSS (is_Scrum) Adoption, with Dr. Wolfgang Richter, CLT

Dr. Wolfgang Richter is the founder and CEO of JIPP.IT GmbH (http://www.jipp.it/), an Agile Change Agency. He is a Certified Scrum Trainer (CST), Certified LeSS Trainer (CLT) and Coach and works with Scrum and Agile Methods since 1998. He and his team specializes in improving processes and structures by using agile methods and principles. Agile Transformations is one of the main activities. Scrum and LeSS are his preferred approaches for internal and customer driven projects.


This is going to be a fun story. Lots of IRONY.
When an organization hits Large-Scale Scrum, it is most likely to begin with a fake adoption. Scaling per sé is not easy. And it is not recommended. However, large enterprises rarely have a choice. So what can be done to handle the burden of scaling? Which pitfalls can be observed regularly? What is against all odds likely to succeed?


April 02-03: 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: London, NYC, Chicago, Sarajevo, Dayton, Santiago, Sao Paulo, Atlanta, Phoenix and Florida