“Many organisations are so focused on delivering features that they tend to forget the outcome or business impact one wants to accomplish. The acronym MVP is frequently used in a context of a fully working application or minimal set of features where one forgets to truly validate assumptions. PO’s are writing detailed user stories but not always following up on the business impact of it all. At the same time you see business leaders in the organizations disconnect from the delivery process.
Let’s see how we can do things differently!
A cocktail of different models that put business outcomes at the center. A different way to look at so-called product backlogs, stepping away from a flat list of items. This cocktail is one of many LeSS experiments you could try and some things to avoid.”
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)
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.
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.
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.
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:
• 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
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
Dr. Wolfgang Richter is the founder and CEO of JIPP.IT GmbH (https://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?