Category Archives: Training

July 08-10: Certified LeSS Basics (CLB) Courses | Virtual

Class of July 08-10

Relevant Assets:
Next virtual LeSS Training:

06/09 – LESS TALKS: Never-ending saga with Estimation. Can LeSS help us debunk this?

 

Materials used

Additional assets recommended:

Upcoming Training (group discount: group_disc):


Synopsis:

For so many companies, inability to estimate -> forecast –> budget –> manage expectations of clients/users/management is a big issue.
This is not surprising.Under assumption that everyone understands
Scrum and has first-hands experience with all of the below:

  • “Our teams cannot accurately estimate work”
  • “Our teams are not stable and not dedicated. Capacity is unpredictable”
  • “Not everyone is cross-functional and everyone does their own work. What is the point of estimating together?”
  • “Our teams get confused with historical Velocity-driven planning vs. Capacity-driven planning. When to use what and why?”
  • “Our teams have hard dependencies on other teams. Some resources are shared. What can we do?”
  • “Our estimation and metrics get so-so fudged, as they roll up through multiple organizational layers to the top”
  • “Our organization is fractal: one PO per one team, each team works in a silo. We cannot “standardize” estimation”

And most of the below:

  • -“Individual teams are more or less OK, with estimation, but how to we ‘normalize’ estimation across multiple teams?”
  • -“How do we ‘scale estimation’, so that our sr. management can get a sense of how much work we have?”
  • -“When is the best time to estimate? How provides estimates?”
  • -“How can we effectively estimate with many developers not be co-located?”
  • -“When and where is knowledge about the estimated work being used?”

Let’s talk about how most of these problems can be addressed in Large Scale Scrum.
Instead of implying that LeSS is a silver bullet or blanket solution to everything, lets focus on specific dynamics of LeSS, with respect to:

  • specifics of LeSS product group design
  • intimate synergy between teams
  • roles & responsibilities, artifacts & events

in order to understand WHY estimation and forecasting by LeSS product group (e.g. 50 developers) would be more reliable than the same, done by e.g. 50 developers of a traditionally-designed organization.

May 26-29: Certified LeSS Basics (CLB) Courses | Virtual

Class May 26-29

System Modelling exercises done in class.

Note: These are not “the best” or “the only” solutions.  This is brainstorming in small teams: conditional, situational, circumstantial.

Relevant Assets:

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

Next virtual LeSS Training:

05/28 – How to Identify “Agile Masquerades”? What Alternatives Could We Offer Instead? @Agile Munich

Materials presented

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


05/05 – LESS TALKS: Dave Snowden: Answering Tough Questions (Q&A)

A great talk today (this is round 2), with Dave Snowden (round 1  was on 04/20), who took on some provocative and pretty powerful questions.  All points that Dave made were strong.
Here is one that resonated really strong (the quote in blue below is semi-transcribed/paraphrased, starting from about 4 min 20 sec in the video recording below):
…SAFe is perfect for big consultancy firms…
With big consultancies, when the ratio between a principal and a doer (partner and consultant)  is up to about  from 1:5 to 1:10 – apprentice model.
With ratio of above 1:15 – it becomes an industrial model (you have to “feed” a lot of people), when you get more structured processes and recipes.
This is why big consultancies want high utilization and long-term projects, [using] Six Sigma, BPR, SAP…etc.
What they like is a massive roll out, with lots of people, over a long period of time.
What they DONT like, are small improvements in the present.
…So you [if you are a client company] are better off working with small consultancies, not big consultancies….“.
Author’s note: This is how a client-company can become a subject to “triple taxation“. Avoid this.

Questions submitted prior the webinar (The list does not include questions that were asked on air, real-time)


Dave’s Bio:
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.

 

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