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)
“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:
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).”
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
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