In this episode, we have the privilege of having Mauro Sacchi, an esteemed leader in digital R&D at Wärtsilä, whose innovative approach and vast experience in transforming traditional industries into agile powerhouses.

I’m excited to share our transformation story at Wärtsilä, where we’ve embraced Large-Scale Scrum (LeSS) principles to break down organizational silos and unlock our teams’ full potential. This journey wasn’t just about implementing a framework – it was about fundamentally changing how we approach product development and team collaboration.

The Challenge: Fragmented Firepower

When I took over leadership of our digital R&D organization three years ago, I encountered two critical challenges:

1. Inability to direct our firepower to the most valuable work - Our organization was fragmented into silos, with over 10 teams each maintaining their own separate backlogs.
2. Human potential diminished by hierarchical structures - Brilliant people with advanced degrees in physics and mathematics were being treated as mere code producers rather than valuable contributors to product decisions.

Let me illustrate this with a real scenario: One team was working on something extremely valuable for a customer who had complained about our development not meeting promises. Meanwhile, other teams couldn’t help because they were bound to their own backlogs and priorities – even though those priorities were objectively less valuable.

The LeSS Revelation

Though I’d been a Scrum practitioner since around 2007, I hadn’t been exposed to LeSS until taking this role. When my predecessor mentioned the organization was founded on LeSS principles with a Spotify model, I did what any responsible leader would do – I studied up and enrolled in the first available training with Bas Vodde.

That training was nothing short of a revelation. It wasn’t about falling for a theoretical framework (I’m not easily lured by process-heavy approaches). Instead, LeSS addressed my two concrete problems through two powerful principles:

1. One product, one backlog - A clear approach to prioritization based on customer value
2. People at the center of value creation - Recognizing that human potential drives success

The Big Bang Approach

We decided to implement the change in one go rather than incrementally. Why? With around 10 teams, we needed a meaningful critical mass to truly make a dent in our agility. So we merged all previous backlogs into one and elevated the role of the product owner.

This created what I call “necessary friction” – the productive tension that forces meaningful conversations about what truly matters to customers. Many organizations avoid this friction by creating silos, but that’s a missed opportunity for value creation.

“When you start to question and challenge, especially when you put items in competition with each other, you create friction. In my view, that friction is absolutely positive – it’s a dialogue you need to have for proper product ownership.”

Product Ownership: Not for the Faint-Hearted

In a LeSS organization, product ownership is a serious role that requires making hard decisions. The product owner isn’t just a requirements analyst – they must mediate across multiple organizations and customer requests to create one prioritized backlog.

This isn’t about being “nice” or popular. It’s about having the courage to say “no” or “not yet” to stakeholders, which can be politically challenging in a large corporation. Sometimes you need to compromise, but the focus must remain on maximizing value.

In our context, we have a product owner who owns the product we develop, while product managers from various organizations process customer requests to this product owner. Our product isn’t sold standalone – it’s part of a bigger ecosystem of services, which adds complexity to these relationships.

Unleashing Human Potential

Perhaps the most rewarding aspect of our transformation has been seeing our people flourish. In traditional industrial settings, software teams are often treated as IT service providers who simply code what they’re told. But in our world of maritime and energy equipment, software has become a critical engineering discipline that should sit at the same table as mechanical and electrical engineering.

This represents a massive cultural shift for corporations that don’t have software in their DNA. It means elevating software engineers to work alongside other disciplines to solve problems together – that’s true product development.

The results? Teams taking ownership, caring about the work they do, and helping each other regardless of their comfort zones. When it clicks, it’s a pleasure to witness.

“I see teams with excellent positive dynamics because they embrace the simple principle that we are doing product development. The success of my team is the primary objective for value creation, and I do whatever it takes to help that team succeed and deliver value to customers.”

Not a Walk in the Park

I want to be transparent – this journey hasn’t been easy. Some individuals don’t want to work in an environment where more is demanded from them. Some truly just want to code and be told what to do. We’ve been adamant that people belonging to teams need to do their best to make the team successful, even if it means working outside their comfort zones.

We’re also bridging two cultures – the software domain and the mechanical world – which operate at different speeds and often involve different generations. The youngsters need to respect the deep domain knowledge of experienced mechanical engineers, while the mechanical engineers need to recognize software engineering as a distinct profession requiring its own expertise.

The Long Game

Creating this culture takes time. While there are quick wins, building an organization with this mindset is a long-term journey. We’re far better than we were three years ago, but we’re still learning and growing.

For organizations considering a similar transformation, remember that you need to play the long game. The necessary friction will never (and should never) completely disappear – if it did, that would signal a return to silos and disconnection.

Final Thoughts

If you’re considering implementing LeSS in your organization, I’d recommend the training not just for product developers or coaches, but especially for organizational leaders. The principles of LeSS are fundamentally about designing organizations to succeed from both human and structural perspectives.

And if you’re in the middle of this journey already, remember: don’t give up. It’s worth it.

• Mauro

Podcast with Ben Maynard and Mauro Sacchi

Listen to the podcast, below, or here at the Product Agility website

The LeSS City Guide Simulation is an interactive, hands-on activity designed to help participants experience the dynamics of multiple teams working together on a single product.

In this updated version of the Nexus Zoo simulation, the focus is shifted to a practical project: creating a city guide for the city where the training is taking place. Unlike the Nexus Zoo simulation, this exercise incorporates events typically seen in LeSS adoptions, such as a Self-Design Team Workshop and Multi-Team Refinement, to better simulate LeSS dynamics.

This activity helps participants understand how multiple teams collaborate to achieve a shared product goal, offering insights into the challenges of scaling Scrum. It is usually conducted before introducing the events in LeSS to highlight the differences between LeSS and Scrum.

Materials Needed

To run the LeSS City Guide Simulation, you will need the following:

• Colored voting dots (green, red, blue, yellow)
• Large post-its
• Colored A4 paper
• Pens and markers
• Transparent binder and puncher
• Stopwatch or timer

Step 1: Self-Design Team Workshop

The simulation begins with a Self-Design Team Workshop, where participants form their own teams. The trainer provides colored voting dots representing key skills needed for the work:

• Green Dot: Good knowledge of the city
• Red Dot: Good drawing skills
• Blue Dot: Beautiful handwriting
• Yellow Dot: Tripadvisor on the phone

Each participant selects dots corresponding to their skills, making them visible on their name tag. Teams are then formed with 4-5 people, ensuring a balanced mix of skills across all teams.

Step 2: Multi-Team Product Backlog Refinement

Once teams are formed, the Multi-Team Product Backlog Refinement event begins. The Product Owner (PO) — who could be the trainer or, preferably, a co-trainer — presents the product goal: creating a local city guide and getting feedback on it as soon as possible. The initial items for refinement include:

1. Cover Page
2. Must-See Attractions
3. Museums
4. Restaurants
5. Hidden Gems
6. Current Events

The PO uses large post-its for each of these items, presenting them in the order above. Items are distributed for refinement, with one item given to a group of 3-4 participants, which should be a mixed group across teams.

The goal of each group during refinement is to create:

1. A suggested list of items (e.g., top 5 attractions)
2. A layout of the page (what it should include and where - eg. drawing of the attraction, map, etc.)

After a time-boxed refinement session, all participants walk around the room, and each group presents their work. A second round of refinement may follow to add further details if needed.
At the end of the Multi-Team PBR, the PO collects the post-its with the most interesting items (e.g. Must-See Attractions, Museums) to create the backlog.

Step 3: Definition of Done (DoD)

The Product Owner presents the Definition of Done on a flipchart or large post-its, covering the following:

• One page per item
• No two consecutive pages of the same color
• One integrated product
• One common copyright at the bottom center of each page
• Clear handwriting; no grammar mistakes

Step 4: Sprint Planning

Sprint Planning follows, during which the PO presents the top backlog items and asks which team will take each item, one by one. The list will usually look like this:

1. Cover Page
2. Must-See Attraction 1
3. Must-See Attraction 2
4. Museum 1
5. Museum 2
6. Must-See Attraction 3
7. Museum 3

The teams take as many items as they think they can complete in the given time for the Sprint.

Step 5: The Sprint

The Sprint starts, and the facilitator sets a visible timer. Teams use the time to complete an increment that meets the Definition of Done. The facilitator and/or PO should stay available to answer questions but avoid interfering unless needed.

Step 6: Sprint Review

When the Sprint ends, the Sprint Review takes place immediately, during which the completed work is inspected. The trainer sets a timer to keep the Sprint Review concise.

Step 7: Team and Overall Retrospective

After the Sprint Review, each team holds a Team Retrospective to discuss what went well and what could be improved. Afterward, the entire group participates in an Overall Retrospective, which includes the PO. This retrospective focuses on systemic improvements for the next iteration.

Common Challenges and Learning Opportunities

The simulation reveals several typical challenges, especially in the first iteration:

• Lack of Communication with the PO: Teams often do not ask the PO questions about the product, such as the city guide title or copyright. In LeSS (like in Scrum), the PO is accountable for maximizing the value of the product resulting from the team’s work and should involve the team in product decisions while retaining authority over key decisions.
• No Integrated Product: Participants often miss the tools for integrating pages (e.g., puncher and binder) and usually just present individual pages. In LeSS, it is important to have an integrated product that is handed over to stakeholders (e.g., customers) at the end of the Sprint.
• Delayed Integration: Teams often integrate their pages into the binder only at the end of the Sprint, rather than continuously as pages are completed. In LeSS, continuous integration is encouraged to avoid last-minute issues and increase learning by observing what other teams are doing.
• Insufficient Communication Between Teams: Teams often struggle to coordinate on items that should be consistent across all pages (e.g., copyright). In LeSS, team members are encouraged to coordinate directly by walking over and discussing whenever needed.
• Unfinished Pages: If pages are incomplete at the end of the Sprint (e.g., drawing is not finished), the PO may add these items to the backlog for the next iteration.

Step 8: Debrief

The simulation usually involves at least one more iteration to allow teams to apply their improvement strategies and learnings. At the end of the simulation, a debrief session takes place to highlight key takeaways. Common debrief questions include:

• What differences do you see between Scrum and the way you worked in the simulation?
• What worked well in terms of communication between teams? What challenges did teams face in coordinating with each other? How did you ensure consistency across different pages?
• How did delayed integration affect the final product?

Suggested Timings

• Multi-Team Product Backlog Refinement (PBR): 8 minutes
• Sprint: 10 minutes
• Sprint Review: 3 minutes
• Team Retrospective: 3 minutes
• All other events: As long as it takes

Facilitation Tips

This section provides helpful tips for facilitating different parts of the simulation to ensure a smooth and effective learning experience.

• Multi-Team Product Backlog Refinement (PBR): The PO should offer one item at a time (one item for a group of 3-4 people). Teams sitting at their team tables should decide how to split into different refinement groups. The PO can answer questions about what should be done but should not be overly involved in discussing details.
  In order for the PO to easily create the backlog at the end of the PBR, distribute large post-its and ask the teams to use them for the suggested attractions, museums, etc.
• Sprint Planning: Ensure that instead of one team picking similar items (e.g., two museums), those items are distributed across multiple teams to promote cross-team learning and adaptability.
• Sprint Execution: As a facilitator and/or PO, provide honest feedback on participants’ work but avoid giving direct guidance on how to proceed. Instead, encourage participants to think for themselves. For example, when asked about specific product details (e.g., copyright), respond with questions that prompt participants to come up with their own solutions. If asked how to coordinate that every team uses the same copyright, say, “I don’t know. What do you think?”

The LeSS City Guide Simulation provides an engaging, practical way for participants to understand the challenges and dynamics of multi-team Scrum, focusing on collaboration, handling dependencies, and continuous improvement.

Introduction

Spill-over or carryover items are common in many teams. Unfortunately. Focusing on avoiding spill-over can have a positive impact on the team and team dynamics. This article provides insights into what spill-over is, why it’s important, how to prevent it, and what not to do to avoid it, along with strategies for measurement and improvement.

What does spill-over mean?

Spill-over refers to items that have been started but have not been finished at the end of the Sprint. Spill-over does NOT refer to items that were not started even though they were selected in the Sprint — these are sometimes referred to as items thrown out of the Sprint.

Consider the following scenarios:

• A team picks up 4 items in Sprint Planning 1. They start all 4 of them, but then only complete (done) one of them in the Sprint. The other 3 they plan to continue the next Sprint. Spill-over is 3.
• A team picks up 100 items. They start 1 of them and get it done. 99 of them they never started and are not completed at the end of the Sprint. Spill-over is 0.

A key point here is that spill-over does NOT relate to the amount of items a team selects during a Sprint. Hence, picking up less items to try to reduce spill-over is interesting but not likely to actually have an effect :)

Why is spill-over important?

Spill-over is an important measurement for 3 reasons:

1. Agility/flexibility. Ability to change directions every Sprint as there is a no work-in-progress point
   Originally, in Scrum, Sprints were described as small projects that are treated independently. In between the Sprints (and preferably, all the time) the product ought to be in a shippable state and there should be no work in progress so that the Product Owner can re-prioritize based on the current situation. Spill-over practically doesn’t give the Product Owner any choice, the same items need to be continued.
2. Spill-over is caused by some team habits.
   There are not many good reasons to have spill-over at the end of the Sprint. The most common causes for spill-over is that (1) the team members work individualistic and have many items in progress at the same time, (2) this goes hand-in-hand with using spill-over as a buffer to stay within your comfortable knowledge area, to avoid learning, or (3) the items selected in the Sprint are too large.
3. Spill-over suggests difficulty of working incrementally and a need to improve engineering practices.
   Within a Sprint, team members work in small incremental steps that are integrated and tested continuously. When the team members do not work incrementally, then the chance of spill-over increases due to integration problems or other hidden surprises.

How to prevent spill-over?

So, what are ways that teams prevent or cope with spill-overs?

• Have this discussion within your team. As a team, you have the goal for your Sprint, which is either a Sprint Goal or selected items. How do you work on these as a team in a way that avoids having spill-over. Examples below.
• Limit the amount of work-in-progress. The best teams I’ve worked with tried to work one item at a time during the Sprint. This dramatically increased team collaboration and learning. Spill-over became an exception.
• When you try to limit the amount of work-in-progress, then you will end up working out of your knowledge area. That is not always easy. Adopt practices such as pairing or mobbing that will make it easier to learn together.
• Tasks in a Sprint Backlog become coordination boundaries. Sprint Planning Two, in essence, is a software design meeting where the team talks about how they are going to implement the selected items. One outcome of that in-depth software design discussion is fine grained tasks. These enable the team to work one item at the time. Use the time in Sprint Planning 2 to talk, in detail, about the design. You’ll find you’ll learn a lot from that also!
• Have a status check during the Sprint. Commonly this is 2 or 3 days before the end of the Sprint, usually at the end of the daily, where someone asks “Ok, we have 2-3 days left, how does it look? What can we (not) complete?” This is where the team can decide what to focus on to finish or what other actions to take.
• Split items during the Sprint. When you discover an item is larger than expected or the item left is too big to fit in the rest of your Sprint, split it! It is fine to split items inside the Sprint. You update the Product Backlog, inform the Product Owner, and pick one for in the Sprint and the other goes back on the backlog. Obviously, this split is a customer-centric end-to-end split and not a task split (unless you had a task in the first place).
• When you do have spill-over, take it in the Retrospective. How did that happen? How can we work differently to avoid this?
• Split items in the refinement. I would recommend to split so that a team can take roughly 4 items per Sprint. No need to split as small as possible.

What not to do to avoid spill-over?

• Pick up less items in a Sprint. I mean, this doesn’t harm, but it isn’t useful either :) Spill-over is not related to the amount of items you selected, so it will have no impact.
• Take shortcuts to finish an item. When this happens you are solving something bad (spill-over), but introduce something much worse. Having high quality ‘done’ work is more important than reducing spill-over. Reconsider how you work as a team but do not rush. Also, when you see this happen in your team, please speak up as you and the rest of the team will need to deal with the result of shortcuts on the long-run.

Conclusion

Spill-over measurements can be good agile health metrics. In my experience, focusing on reducing spill-over always eventually has a positive impact on the team and team dynamics. Initially the focus on spill-over often triggers questions. These are great learning opportunities for you, take them serious and engage people in the conversation. Hopefully this post helps you and the teams in that conversation.

Credits

This article was originally written in Wartsila context and they allowed me to publish it here. Thanks to Jowen Mei and Ronald van Miert for edits to the post.

In the first part of the Rise of Product Developers series, we explored how Product Developers focus on the domain and users’ problems to build a product. The true value developers bring lies in their critical assessment of what and how they’re building. This approach has always been essential, but it’s become more clear now than ever as AI’s capacity to generate code continues to advance. Because of this mindset, Product Developers refer to Product Backlog Items as hypotheses.

Questioning the Why

In a Product Backlog Refinement Workshop, a conversation unfolds between the Product Developers and a Product Manager:

Product Manager: “We need pagination.”
Product Developers: “What problem are we trying to solve?”
Product Manager: “The page loads too slowly, and I think we’re losing users because of that.”

Questioning the Why So

Product Developer 1: “I can look at how many people are leaving the page without doing anything.”
Product Developer 2: “Could we simplify the process by showing only recent events?”

If they decide to investigate the first idea, they’ll need observability within the product. Observability has increasingly become a high-priority feature, which is an overarching strategy that encompasses various aspects such as instrumentation (product feature that allows monitor and measuring behavior) and testability (making sure that the designs are friendly to effective testing). Enhanced observability equips Product Developers with the means to accurately evaluate both the value and functionality of the product. As the series continues, we will explore how they also depend on observability to retain knowledge.

Shared Requirements Discovery - Think Critically Together

The responsibility of requirements discovery is not exlusive to certain roles. Product Developers clearly play crucial roles in this process.

Product Manager: “That’s true, but a user has said they’ll pay a million dollars if we implement pagination.”
Product Developers: “Is it worth adding complexity for that? Could we determine if displaying only recent events would satisfy them?”

Questioning the Why Now

Product Developers: (to the Product Owner) “Why are we fine-tuning the UI now? We haven’t had many users yet.”
Product Owner: “This user is the key to attracting more users. We need to ensure they’re satisfied.”

Questioning the Functionality (What)

Product Manager: “Perhaps showing only recent events might work.”
Product Developers: “Can you give us an example?”
User: “Sure, for instance, show only the 5 most recent events if there are many.”
Product Developers: “Like this?”

Scenario: Show only recent events when there are too many past events
  Given there were 3 events 3 days ago
  And there were 3 events 2 days ago
  And there were 3 events 1 day ago
  Then I should see only 5 recent events within 2 days in the past event list

User: “Yes, that looks good.”

Using techniques like Specification by Example, Product Developers and users bridge the communication gap with less ambiguity. If also helps them to define the scope of the work critically.

Questioning the Solution (How)

Product Developer 1: “We should generalize this functionality because more listing requirements will likely emerge.”
Product Developer 2: “YAGNI, let’s keep it simple for now.”
Product Developer 3: “How do we know we are done?”
Product Developer 1: “We write the test first.”
Product Developer 2: “And we also test later to uncover unexpected side effects and bugs.” (try to prove what we did is wrong)

Think about mantainability critically

While the world marvels at AI’s ability to pass the Turing Test, Product Developers understand the challenges it poses for passing Regression Tests in product maintenance.

In traditional organizations, the worth of an initiative is justified through logical reasoning and often isn’t questioned. However, even logically sound ideas need to be treated as hypotheses, given the variables of feasibility, the impact on the existing product, and the actual outcome.

Conclusion

Product Developers not only play a role in implementation and maintenance but also shoulder the responsibility of critically evaluating and validating assumptions while preserving key knowledge. An integral part of their contribution is the continuous improvement of their process through their critical thinking skills. However, this trait of constantly refining processes isn’t unique to them alone, which is why it wasn’t highlighted in the examples.

By fostering informed decision-making within the organization, Product Developers play a pivotal role in ensuring the success of the products they develop. In practice, validation and knowledge preservation often go hand-in-hand. In the next installment of this series, we’ll delve deeper into another crucial aspect of Product Developers’ accountability: learning and preservation.