Category Archives: Team Dynamics

07/14 – LESS TALKS: Have we just witnessed the transition to remote teams? No. Find out why.

 

Additional assets recommended:

Upcoming Training (group discount: group_disc):

Best Agile Articles of 2019: Proper Scaling of Scrum And Dynamic Financial Forecasting

Materials  used

Additional assets recommended:

Upcoming Training (group discount: group_disc):

July 01-03: Certified LeSS Basics (CLB) Courses | Virtual

Class of July 01-03

Relevant Assets:
Next virtual LeSS Training:

06/23 – LESS TALKS: What is “UNDONE” Department And How To Eradicate It?

Materials used

Additional assets recommended:

Upcoming Training (group discount: group_disc):


Synopsis:

What is Undone Department?
“Undone department—This department, ideally, does not exist.
Unfortunately, sometimes the teams are not yet able to create a true shippable increment every Sprint. This is reflected by their “Definition of Done” not being equal to “Potentially Shippable.” The difference between them is called Undone Work. Someone needs to do this Undone Work, and a common “solution” is to create separate groups that pick up the “undone work”—the undone department. More on this in the Definition of Done chapter.
Undone departments such as test, QA, architecture, or business analysis groups should never exist in the smaller LeSS framework groups; rather they should be integrated into the teams from the start. On the other hand, we unfortunately still frequently see an operations or production undone department in LeSS adoptions, as they often cross organizational boundaries.
A goal in every LeSS adoption is to remove the undone department. How long will this take? The answer is highly dependent on how fast the organization improves its capability.” – from the 3rd LeSS book (Large Scale Scrum: More with LeSS)

06/18 – Exposing Uncomfortable Topics: Errors and Omissions with Scaling


Materials used

Additional materials recommended:

Upcoming Training (group discount: group_disc):


Synopsis:

“Bad scaling is one of the biggest ‘agile problems’ of modern days for companies.
Bad scaling is one of the three (the other two are : “agile tools” mania and falling a victim to big consultancies’ industrial model [see/play Dave Snowen’s view here:

https://www.keystepstosuccess.com/2020/05/05-05-less-talks-dave-snowden-answering-tough-questions-qa/ ] ) one of the most expensive mistakes companies make, when they set themselves on a wrong ‘agile course’.Bad scaling is one of the three corners of “Trippe Taxation” triangle:

Bad scaling comes in the form of trivializing agility at is core, weakening agile roles, plagiarizing and relabeling someone else’s experiments and calling them ‘operating models’, copy-pasting Scrum and Scrum roles into Fractal Geometry that look great on paper.

Are there better ways to work? Probably not, if the ultimate goal is to relabel existing enterprise complexity with fancy agile terminology and then call it “enterprise scaling”. But there could be better ways to work if an ultimate goal is to simplify existing complexity (de-scale), and by doing so, improve your chances to scale agile ways of working (e.g. do Scrum, by more than one team, working for the same Product Owner, on the same product, out of the same backlog).

In this session, Gene will expose some classic pitfalls of bad scaling and will recommend how, more good things could be done with less stuff,…how things could be done better, using Large Scale Scrum (LeSS).”

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