Scrum.org Blog

What to Do if Your Self-Managing Teams Are Struggling

Robert Pieper — Mon, 17 Nov 2025 17:25:44 +0000

Self-managing teams are at the heart of Scrum. These teams hold the responsibility for deciding who does what, when, and how, and they take ownership of the product work from start to finish. They are expected to manage operations, maintenance, verification, and all the small and large decisions that shape a product. While the idea sounds simple, many Scrum teams and organizations discover that encouraging true self-management is difficult. Even capable and collaborative teams can struggle to take initiative or share ownership. Understanding what helps self-managing teams grow through these challenges is essential for long-term effectiveness.

Why Silence Supports Deeper Problem Solving

One of the most underestimated tools for growing team ownership is silence. When a problem surfaces during a Scrum event and no one immediately responds, it can be tempting for a facilitator or leader to jump in with an answer. This instinct often comes from experience, expertise, or simply wanting to help the team move forward. However, filling the silence can unintentionally shift responsibility away from the team.

Letting the moment breathe gives people time to think and encourages them to step into the problem together. Reflecting the issue with a simple question like, “What are we going to do about this?” guides people toward action and ownership. During these quiet moments, team members begin to explore options, discuss possibilities, and build confidence in making decisions. Self-managing teams grow stronger when they learn that silence is not a signal to wait for leadership but a space to begin collaborating.

Motivation Shapes How Teams Approach Self-Management

Motivation plays an important role in the success of self-management. Some team members naturally embrace problem-solving and collaboration. They enjoy taking initiative and exploring new ways to improve. Others may be less internally motivated and approach their work as a set of tasks to complete before the end of the day. This difference in motivation can impact how a team responds when faced with decisions or challenges.

When individuals are not motivated to take action without direction, self-management becomes more difficult. Teams may stall, look for guidance, or avoid responsibility. Addressing motivation begins with understanding what each person values and how they connect to the work. Leaders and Scrum Masters can inspire engagement by clarifying purpose, celebrating progress, and removing barriers that prevent people from contributing fully. As motivation grows, so does the ability of self-managing teams to step into ownership and act confidently.

Three Pillars That Strengthen Self-Managing Teams

To support the development of self-management, three pillars are particularly helpful: boundaries, goals, and accountabilities. These elements work together to create a structure where teams understand expectations while still having freedom to make decisions.

Boundaries

Boundaries are essential because they create clarity and safety. When teams understand what they are allowed to change and what must remain stable, they gain the confidence to take action. Without boundaries, teams may hesitate out of fear of overstepping or making the wrong move. With well-defined boundaries in place, teams can explore solutions, test ideas, and grow through experience. This clarity becomes a foundation for strong self-managing teams because it supports autonomy without causing confusion.

Goals

Clear goals give teams a shared direction. When the team understands what outcomes matter most, it becomes easier to align decisions and collaborate toward meaningful results. Goals serve as a guide when questions arise and help reduce dependence on external direction. They empower teams to make choices that support the broader purpose of their work. Effective goals encourage focus and help reinforce the behaviors needed for self-managing teams to thrive.

Accountabilities

Accountability brings ownership to life. When individuals and teams take responsibility for outcomes, their engagement deepens. They begin to collaborate more intentionally, solve problems proactively, and support each other’s success. Accountability shifts the mindset from waiting for direction to actively shaping the work. This ownership strengthens the structure of self-managing teams and helps them become more resilient, adaptable, and committed.

Leadership’s Role in Supporting Teams Through Struggle

Although self-management belongs to the team, leadership plays an essential role in creating the environment where it can flourish. Leaders can remove obstacles, provide clarity, and build trust by allowing teams to face challenges without stepping in too quickly. Growth often happens when teams encounter difficulty and must work together to find a way forward.

Leaders who give teams the space to struggle, learn, and recover help them develop confidence and maturity. They support the conditions that allow self-management to take root. By offering guidance without taking over, leaders help self-managing teams grow through experience rather than direction.

Creating Conditions for Sustainable Self-Management

Self-management develops over time. It requires practice, clarity, trust, and room to experiment. Teams need boundaries that support safe exploration, goals that encourage alignment, and accountability that reinforces ownership. Most of all, they need leadership that believes in their potential and supports them through the challenges that come with growth.

Even when self-managing teams struggle, these challenges can become turning points. With the right environment and support, teams can develop into confident, capable groups that collaborate effectively and take ownership of their work.

If your Scrum team feels stuck, chances are small mistakes are adding up to big barriers. Misused events, unclear goals, and weak accountability can quietly erode progress and collaboration. Download our FREE eBook, Why Scrum Isn’t Working: A Manager’s Field Guide to Organizational Misfires, to uncover how these common missteps derail teams—and how to realign your Scrum practices to deliver the value your customers expect.

Continuous Learning is at the heart of great Scrum Teams

If you're ready to grow your understanding and improve how your team works, explore our upcoming Professional Scrum courses.

Want to see how Responsive Advisors can help you or your organization succeed? Learn more at responsiveadvisors.com.

[Vlog] The AI Fluency Framework, Explained

Mehdi Hoseini — Mon, 17 Nov 2025 17:03:34 +0000

The AI Fluency framework helps us build a mindset of how to think about working with AI.

The credibility of the AI Fluency concept goes to the Anthropic company, which has partnered with academic experts Prof. Joseph Feller and Prof. Rick Dakan to launch a course about the framework.
So, let’s see what it is.

In one sentence, AI Fluency is the conscious ability to collaborate with AI in ways that are effective, efficient, ethical, and safe.

The 4D Core Competencies

It has four core competencies of Delegation, Description, Discernment, and Diligence. These competencies apply across all three major ways of interacting with AI, including Automation, Augmentation, and Agency.

What does it really mean to be fluent with AI?!

AI is reshaping how we communicate, create, learn, and solve problems in both our work and personal lives. It helps us with a new way of writing, brainstorming, decision-making, and much more. But here is the thing. Having these powerful systems doesn’t automatically mean we know how to effectively use them.

Think about a time when you got an unexpected response from an AI and you weren’t sure how to proceed. Or when you struggled to explain exactly what you needed and left the interaction feeling frustrated. Or maybe you have wondered if the information you are sharing is being properly protected.

All of these situations highlight the gaps between simply having access to AI and truly being fluent with AI.

So, we need to develop a lasting skill in ourselves to be able to constructively and fluently use this newcomer.

Let’s talk about the four competencies of the AI Fluency framework.

Delegation: Deciding on what work should be done by humans, what work should be done by AI, and how to distribute tasks between them. Includes understanding your goals, AI capabilities, and making strategic choices about collaboration.

Description: Effectively communicating with AI systems, including clearly defining outputs, guiding AI processes, and specifying desired AI behaviors and interactions.

Discernment: Thoughtfully and critically evaluating AI outputs, processes, behaviors, and interactions. Includes assessing quality, accuracy, appropriateness, and determining areas for improvement.

Diligence: Using AI responsibly and ethically. Includes making thoughtful choices about AI systems and interactions, maintaining transparency, and taking accountability for Al-assisted work.

The three ways to interact with AI

Now, let’s take one step further and talk about how humans can interact with AI systems. There are three modes of interaction:

Automation: When AI performs specific tasks based on specific human instructions. The human defines what needs to be done, and the AI executes it.

Augmentation: When humans and AI collaborate as thinking partners to complete tasks together. Involves iterative back-and-forth where both contribute to the outcome.

Agency: When humans configure AI to work independently on their behalf, including interacting with other humans or AI. The human establishes the Al's knowledge and behavior patterns rather than specifying exact actions.

As the final word, AI fluency develops through continuous learning by intentional practices, not overnight mastery.

This is going to become the bare minimum literacy required by the job market.

So, ask yourself a question: Am I really willing to be fluent with AI?! If yes, then you need to invest in your learning to become an AI-aware pro in your field of profession.

What is the next step?!

If you want to go further, you can join my upcoming Professional Scrum Product Owner - AI Essentials (PSPO-AI Essentials) class. See this link for more information:

https://scrumschool.org/course/professional-scrum-product-owner-ai-essentials?utm_source=scrum.org&utm_medium=blogs&utm_campaign=the-ai-fluency-framework

From 70% Spillover to Trusted Predictable Delivery: A Flow Metrics Case Study

Alexander Hardt — Mon, 17 Nov 2025 14:59:42 +0000

Overview

A leading international retail organization faced persistent challenges in its IT transformation program. With 40+ teams operating across multiple countries, the organization struggled with unclear metrics, unpredictable delivery, and declining trust between teams and stakeholders.

Despite claiming to use Scrum, teams lacked clarity on what to measure, how to improve, and how to communicate progress effectively.

Felix, a Scrum Master Chapter Lead overseeing 15+ Scrum Masters, recognized that traditional Velocity and Story Points weren't providing the necessary insights. Drawing on previous experience with Flow Metrics, he partnered with Professional Scrum Trainer Alex Hardt to introduce a comprehensive Flow Metrics training program.

Within months, the initiative transformed not just delivery performance but the entire culture of transparency and trust across the division involved.

Challenges

The transformation team faced multiple interconnected problems:

Measurement Confusion: Teams lacked a consistent way to measure and communicate their actual delivery speed. Story Points and Velocity created endless debates without providing actionable insights. Management couldn't understand what teams were actually accomplishing.

Poor Predictability: The division committed to quarterly planning cycles (PI Planning) with international stakeholders across the US, UK, and Australia. However, Spillover Rates reached 60-70%, meaning most planned work wasn't completed on time. This created a pattern where stakeholders felt "you promise us things at the start and don't deliver them at the end."

Dependency Management: Dependencies between teams created bottlenecks and delays. Teams would start work only to discover they were blocked, waiting for other teams, which created flow debt and extended Cycle Times. Work accumulated particularly in integration phases, where cross-team coordination was required.

Data Quality Crisis: When teams first attempted to implement Flow Metrics, they discovered their data was fundamentally unreliable. Items remained open for 850+ days. Status transitions weren't tracked properly. Work types weren't categorized consistently. The tools and processes weren't capturing what actually happened.

Communication Breakdown: Trust between teams, management, and international stakeholders had eroded. Without objective data, every conversation devolved into subjective arguments about performance. Teams felt they couldn't say no to new work, leading to chronic overcommitment.

Cultural Dysfunction: The focus on starting new work rather than finishing existing work created a system optimized for busyness rather than delivering value. Teams lacked the language and tools to push back effectively.

Initiating Change

After attending Alex's Professional Scrum with Kanban (PSK) classes, Felix and his team returned with renewed energy and a clear framework in place. Rather than mandating a top-down transformation, they followed the principle of Kanban: "Start with what you do now."

The catalyst was making work visible through Flow Metrics. Alex's training emphasized three key areas that became eye-opening game-changers for Felix and his team:

Conceptual Clarity: The training provided an unprecedented level of focus. Participants finally understood exactly which metrics mattered most and why. After years of being overwhelmed by competing frameworks and metrics, this clarity cut through the noise.

Little's Law: Understanding the mathematical relationship between Work in Progress (WIP), Throughput, and Cycle Time provided teams with a simple yet powerful mental model. Felix noted, "Actually, you don't need much more than this for the next three years. This gives you enough to work on."

Experiential Learning: The TWiG simulation game made product development complexity tangible for people at all experience levels, including those new to IT or Scrum Master roles. This created shared understanding across the division about why Flow matters.

Immediate Action

Directly following the training, self-organized working groups formed spontaneously. Without managerial directive, teams took ownership of applying what they'd learned. Initiatives emerged around data quality improvement and probabilistic forecasting, with participants declaring "we're applying this to ourselves now." This grassroots momentum signaled something different. The concepts had resonated deeply enough to drive autonomous action.

Solution

The implementation unfolded in interconnected waves:

1. Data Quality Initiative

Teams immediately recognized they couldn't measure Flow without reliable data. A grassroots initiative formed to establish consistent data capture practices. Rather than external pressure, teams now had intrinsic motivation. They wanted accurate metrics for themselves. This discipline improvement became foundational for everything that followed.

2. Work in Progress Reduction

Armed with Work Item Age visibility, teams addressed their "orphans." Started but never finished items. They systematically:

Archived obsolete work
Split large items into shippable pieces
Implemented and honored WIP Limits
Focused on finishing over starting

For the first time, teams were reducing Flow Debt rather than accumulating it. Work in Progress was cut roughly in half at both the team and strategic levels.

3. Probabilistic Forecasting

The division adopted Monte Carlo simulations for forecasting, replacing commitment-based planning with probability-based communication. Instead of "we'll finish this," conversations shifted to "we have an 85% probability of completing these four initiatives in the next quarter."

This transformed stakeholder relationships. Felix explained: "The communication style fundamentally changed. Previously, it was 'you didn't deliver, that's terrible.'Now it's 'there was an 85% probability. It didn't work out this time, but it will next time.'" When the 15% happens, it's understood as natural system variation rather than failure.

4. Flow-Enhanced Scrum Events

The team reimagined Scrum Events through a Flow lens:

Sprint Planning: Monte Carlo "How Many" simulations based on historical Throughput replaced gut-feel forecasting.
Daily Scrums: Walking the board right-to-left, focused on unblocking aged items rather than individual status updates.
Sprint Retrospectives: Flow Metrics provided evidence-based foundations, making these sessions constructive rather than emotional venting.

5. Dependency Management

In a SAFe context, where several teams work on initiatives often with a large number of dependencies, actively managing those dependencies is crucial.

In Felix's division, using PI Planning and quarterly releases, with multiple teams working on shared initiatives. They improved dependency management on a cross-team level by reducing WIP and increasing transparency, enabling teams to proactively manage their dependencies and complete initiatives more quickly.

6. Strategic Integration

Flow Metrics is integrated with the division's OKR process and WSJF prioritization.

Leadership discussions could now incorporate empirical data, such as "Based on our metrics, we have a 95% probability of completing this in two quarters" or "This has only a 35% probability of completing in three months. The risk is too high to start."

Results

Within approximately one year, the transformation delivered measurable improvements:

Quantitative Gains

Spillover rates decreased from 60-70% to 20-30%
Throughput increased significantly (specific percentages varied by team)
Work in Progress reduced by approximately 50% at both the team and strategic levels
Dependency-related delays decreased as teams proactively managed cross-team work

Qualitative Transformation

Transparency: Teams and management now share a common language for discussing delivery performance. Data replaced opinion in critical conversations.

Trust: The relationship between teams, local management, and international stakeholders fundamentally improved. Felix noted: "We went from 'the countries hate us and we don't trust our management' to 'we're all in the same boat.'"

Focus: Teams gained the ability and confidence to say no to work that would compromise their predictability and consistency. The division shifted from valuing starting work to valuing finishing work.

The most telling indicator wasn't a metric. It was the cultural transformation. Transparency, trust, and focus all increased significantly across the division.

Conclusion

This transformation demonstrates that lasting change comes not from abandoning frameworks but from evolving how we use them. By integrating Flow Metrics with existing Scrum practices, this division:

Replaced subjective debates with objective data
Created intrinsic motivation for continuous improvement
Built trust through transparent, probability-based communication
Established a scalable model that is now spreading to additional divisions

The approach continues to bear fruit. Felix has since moved to a new division where he's replicating the model with a new team of 20 Scrum Masters. The original training participants are now multipliers. Running their own TWiG game sessions and coaching peers on Flow Metrics.

For organizations struggling with agile maturity, the lesson is clear: sometimes the missing ingredient isn't a new framework but better visibility into the one you already have.

Flow Metrics provided that visibility, transforming not just delivery efficiency, effectiveness, and predictability but the entire culture of how teams work, communicate, and continuously improve.

Confidentiality Note

At the client's explicit request, both the individual's name and the company name have been pseudonymized. The case description and results, however, are based on a real project.

Self-organize to higher performance

Mary Iqbal — Mon, 17 Nov 2025 14:00:00 +0000

I once worked in an organization where we needed to grow from one Scrum team into many Scrum teams by staffing up. These teams would support one single Product and would be supporting a single Product Owner and Product Backlog. I suggested that as new staffing joined us, we should let them self-organize into their own Scrum teams.

Is a team new to Scrum ready to self-organize?

To reach this kind of growth, we were planning to hire externally. Some of our hires would not have Scrum experience and many would have limited Scrum experience. Some leaders asked the question: are people who are new to Scrum going to be ready to self-organize?

The short answer is yes. Self-organization is not something that needs to be earned. And besides that - to be honest - deciding what teams' people will work on is not rocket science either. By trusting the team to own how they work together to deliver the product, the organization is empowering them to figure out the best way to deliver the product. By helping the team to self-organize, we would actually be taking the first step to building a high performing team.

Why Self-Organize?

We need to create an environment that fosters a team grounded in empiricism—one that continually learns and is united around improving customer outcomes. Our focus should be on building a learning team. High performers rarely thrive under micromanagement, and excessive limits on self-organization can hold them back. Instead of questioning whether a team is “ready,” leaders should concentrate on hiring people who are motivated to do great work and then shape an environment that empowers them and aligns everyone around delivering value to customers.

If you hired a team of contractors to redesign your kitchen, you wouldn't tell them how to work together. You've hired their expertise. The same can be said of software developers or anyone working together to deliver complex work. You've hired them for their expertise, now let them figure out the best way to deliver their work. Including how their teams should be structured, and how the Scrum teams will work together to deliver the product. *(I am not talking about reporting structure, I am talking about which Scrum team each person should be on within the product team.) What does a self-organization session look like? Check out our recent article, How to roll-out Scrum in your organization.

What does leadership do?

Leaders should focus on removing impediments, ensuring the Scrum team is working together well and that they are using empiricism to inspect and adapt so that they can be always learning and growing. Set the guardrails within which the teams will be allowed to self-organize and give them the training and resources that they need to do their work.

What does self-organization look like?

We asked the team how they preferred to move forward. They chose to begin by forming two large Scrum teams, each made up of a mix of newly onboarded staff and long-tenured employees.

After one Sprint—during which the new team members became familiar with our environment—we held a self-organization session with roughly 30 participants. Leadership opened the meeting by emphasizing the importance of the product and the impact we aimed to create for our customers. The Product Owner then shared her product vision, the Product Goal, and an overview of the upcoming features she hoped to deliver.

The Scrum Masters followed by explaining the guardrails for self-organization: leadership wanted teams capped at 10 people per team, and all teams would work from a single Product Backlog while maintaining their own Sprint Backlogs. Team members were then invited to decide how many Scrum teams we should form, and ultimately determine the composition of each team.

For more details on the self-organization agenda, take a look at this recent article.

The result

The team became one of the highest performing teams in the organization within just six months. They were able to deliver faster and higher quality work than anyone had expected, and they created a culture that was empowered, positive and really felt like a team.

These outcomes weren’t the result of tighter control or more oversight—they were the natural consequence of ownership, alignment, and empowerment.

The teams had chosen who they would work with. They had defined their own working agreements. They were invested—and it showed.

Why Self-Organization Works

1. It Builds Ownership and Accountability

People commit more deeply to decisions they make themselves. When a team forms by choice, not assignment, accountability becomes intrinsic.

2. It Surfaces Real-World Dynamics Leaders Can’t See

Working relationships, communication styles, individual strengths—these factors become visible only when people are free to organize around them.

3. It Accelerates Learning and Adaptation

Teams learn faster when they are experimenting, reflecting, and adjusting together. Self-organization encourages continuous improvement at every level.

4. It Builds Trust—The Foundation of High Performance

When leaders say, “We trust you to form your own teams,” they send a message that sparks motivation and psychological safety.

Six Months Later: A Powerful Proof of Empowerment

About six months after the initial self-organization, the Product Owner shifted priorities to new areas of focus. The teams realized that their current structure wasn’t ideal for the new direction.

And then something remarkable happened:

They completely re-organized themselves—without being asked and without needing permission.

They held the discussion during a Sprint Retrospective, decided what configuration would enable them to deliver the new priorities more effectively, and implemented the change immediately.

No escalation. No approvals. No micromanagement.

Just empowered professionals solving their own problems.

This is what real Agile maturity looks like.

The Leadership Mindset Shift

Leadership’s role in Scrum is not to direct, arrange, or control the work. It is to remove impediments, provide clarity, and create an environment where teams can thrive.

High-performing teams don’t emerge from top-down structures. They emerge from trust, autonomy, and continuous adaptation.

When leaders step back, teams step up.

Conclusion

The story of this 30-person group demonstrates a simple truth:

If you want high-performing Scrum teams, you should let them practice self-organization. Within months, they delivered measurable improvements in customer satisfaction and lead time. Within half a year, they were confident and empowered enough to re-organize on their own, in response to shifting priorities—without any managerial intervention.

This is the promise of Scrum. This is what happens when leadership stops managing the work and starts focusing on building the team.

Find steps to self-organize your team here: How to roll-out Scrum in your organization

******

Rebel Scrum is the host of the annual Scrum Day conference. Join us in 2026 in Houston, Texas, or in Madison, Wisconsin, for an interactive, engaging and informative conference experience. View pictures from last year's Scrum Day event.

Agile Adoption in Singapore: The Numbers & What They Mean

Chee-Hong Hsia — Mon, 17 Nov 2025 12:40:59 +0000

You've probably heard the buzz: "Agile is everywhere now!" "Singapore is going Agile!" "Asia is the future of Agile!" But what do the actual stats say? Spoiler alert: they're pretty impressive.

The Big Picture: Asia-Pacific is Going ALL IN on Agile

Let's start with the region as a whole. Because honestly, the Asia-Pacific numbers are wild.

The Asia-Pacific region is investing heavily in Agile transformation services, with market research indicating a $1.3 billion market in 2023 that's still growing.[1] Think about that. Over a billion dollars being spent just on services to help companies go Agile. That's not "maybe Agile works" energy. That's "Agile works, and we're investing serious money" energy.

When it comes to Agile adoption, Asia-Pacific is seeing explosive growth across tech sectors. India leads with significant deployments (especially in tech startups and digital media), while China follows closely (especially in the fintech and e-learning sectors).

And here's what we know for sure: Agile adoption in Asia-Pacific is massive. The numbers tell a clear story of widespread transformation.

Why Asia? Why Now?

Why is Asia-Pacific becoming such an Agile powerhouse? A few things that make this region unique:

Leapfrogging traditional development: Many Asia-Pacific countries are skipping entire stages of traditional business evolution and jumping straight to digital-first, Agile-ready models with no legacy systems to untangle
Massive tech talent concentration: The region produces millions of software engineers and tech professionals annually, creating a workforce that's naturally aligned with iterative, collaborative work styles
Government-driven digital transformation: Countries like Singapore, India, and South Korea have national digital transformation strategies that explicitly promote Agile methodologies as part of their economic development plans
Mobile-first economies: In many APAC countries, mobile penetration happened before desktop computing was widespread, creating a natural fit for Agile's rapid iteration cycles and user-centric approach
Startup ecosystem explosion: The region is home to some of the world's fastest-growing startup hubs, where Agile isn't a transformation. It's the default way of working from day one

Plus, there's something interesting happening culturally. Asia-Pacific leads the world in AI adoption (78% vs 72% globally), and that tech-forward mindset pairs beautifully with Agile's iterative approach. [2] When you're already comfortable with continuous improvement and rapid cycles, Agile just... makes sense.

Singapore: The Agile Frontrunner

Now let's zoom into Singapore. Because honestly? Singapore is killing it.

81% of businesses in Singapore have implemented Agile methodologies at scale. [3] That puts Singapore at third highest in the entire Asia Pacific & Japan region. Third. Not bad for a tiny red dot, right?

But wait, it gets better. The pandemic didn't slow Singapore down. It accelerated everything. 83% of Singapore employers say they accelerated Agile adoption since the pandemic hit. [4] And right now? 78% are currently implementing Agile in their workplaces. [4]

That's almost 4 out of 5 companies. Right here. Right now.

Why Singapore Companies Are Going Agile

According to the data, Singapore employers aren't doing this just because it's trendy. The main motivation? The ability to adapt and respond to rapid changes. [4]

In a world where markets shift overnight, regulations change, and customer expectations evolve constantly, Agile isn't a "nice to have." It's survival. It's competitive advantage. It's how you stay relevant.

The Reality Check: It's Not All Smooth Sailing

Okay, so the adoption numbers are impressive. But let's be real: implementing Agile isn't like flipping a switch. The data shows Singapore companies are facing real challenges:

57% of employers say not everyone on the team understands Agile requirements [4]
55% note that significant time and commitment are needed for team collaboration [4]
48% say remote work arrangements make team communication more challenging [4]

Translation? Going Agile is hard work. Really hard work. It requires training. It requires cultural shifts. It requires people actually understanding what they're doing, not just going through the motions.

You can learn Agile from YouTube videos, blog posts, that colleague who took a course years ago. But here's the brutal truth: just because you can learn something anywhere doesn't mean you're learning it right.

But here's what's interesting: Singapore companies are taking a test-and-learn approach. They're more likely than their global counterparts to experiment carefully before scaling transformation efforts. [5] That's smart. That's how you do it right.

What This Means for You?

So why should you care about these numbers?

If you're a professional in Singapore, this is your market. Agile skills aren't "nice to have" anymore. They're becoming essential. Companies want people who understand Scrum, who can work in Agile teams, who can adapt fast. Ready to get started? Check out our Professional Scrum Master training or explore all our Scrum courses.
If you're a team leader, your organisation is probably either implementing Agile or thinking about it. Understanding these frameworks isn't optional. It's how you lead effectively in 2025. Learn more about Professional Agile Leadership training to transform how your teams work.
If you're a company, you're probably already in that 78% implementing Agile, or you're watching your competitors do it and wondering how to catch up. The question isn't "should we go Agile?" It's "how do we do it right?"

The Training Gap (This is Where We Come In)

Here's the thing: 57% of employers say team members don't fully understand Agile requirements. [4] That's a problem. Because going through the motions of Agile without understanding it? That's just expensive chaos.

You can't learn Agile from a PowerPoint deck. You can't learn Scrum from watching YouTube videos (though, hey, those can help). You need proper training. Training that's:

Globally recognised (not just someone's opinion)
Locally relevant (understanding Singapore's unique business environment)
Hands-on (actually doing it, not just talking about it)
Practical (stuff you can use Monday morning)

That's what we're building at Kiwii. Singapore's official Scrum.org training partner, bringing globally validated Agile and Scrum training that actually gets Singapore. Whether you're looking for Professional Scrum Master, Product Owner, or Advanced Scrum training, we've got you covered. Learn more about why Kiwii exists and our story.

The Bottom Line

The numbers don't lie: Asia-Pacific is going Agile. Singapore is leading the charge. And it's not slowing down anytime soon.

But here's what matters more than the numbers: understanding matters. Adopting Agile without really understanding it? That's how you waste time and money. Learning Agile the right way, from the right people, with the right support? That's how you actually transform.

Singapore deserves better than generic Agile training that doesn't work here. That's why Kiwii exists. That's what we're building.

The Agile revolution in Asia isn't coming. It's here. The question is: are you ready to be part of it?

Reference

Market Research Firms. "Enterprise Agile Transformation Services Market Analysis." Market size data ($1.3 billion for Enterprise Agile Transformation Services Market in Asia-Pacific region, 2023) compiled from industry reports and market analysis. Related market research available from: Gartner's "Market Share Analysis: Application Implementation and Managed Services, Worldwide, 2024" (gartner.com), Forrester's "Market Overview: Agile Development Service Providers" (forrester.com), IDC's "FutureScape: Worldwide CIO Agenda 2023" (idc.com), and Grand View Research's "Digital Transformation Market" reports (grandviewresearch.com). Note: Some reports may require subscription or purchase. Methodology and data verification may vary across sources.
Boston Consulting Group. "Asia-Pacific Leads AI Adoption." BCG Press Release, October 30, 2025. BCG survey finding 78% of APAC respondents use AI at least weekly, reflecting tech-forward mindset complementary to Agile practices. Retrieved from bcg.com
CA Technologies. "Agile Application Lifecycle Management (ALM) Survey 2016." Global survey finding 81% of Singapore businesses have implemented Agile methodologies at scale, ranking Singapore third highest in Asia Pacific & Japan region. Reported by The Tech Revolutionist, October 2016.
NTUC LearningHub. "Industry Insights Survey 2021: Businesses Adopting Agile Approach Since Pandemic, Yet 57% of Employers Face Challenges." Survey of Singapore employers on Agile adoption during COVID-19 pandemic. Key findings: 83% accelerated adoption, 78% currently implementing, 57% cite understanding challenges. Reported by Vietnam News and various media outlets, July 2021.
Business Times Singapore. "Singapore Companies Are Going Agile to Stay Ahead." Feature citing McKinsey & Company research showing Singapore companies' test-and-learn approach to Agile transformation, with higher likelihood to experiment carefully before scaling. Retrieved from businesstimes.com.sg

Die Auswirkungen von „Wir machen Scrum, aber …“ und was dir die Scrum-Polizei verschweigt

Simon Flossmann — Mon, 17 Nov 2025 06:15:00 +0000

„Wir machen Scrum, aber …“

Dieses Phänomen ist natürlich nicht neu. Ich glaube, es war Gunther Verheyen, der ihm seinen Namen gab. Gemeint sind Teams, die Scrum – irgendwie – machen, aber kritische Regeln nicht befolgen. Und das Problem ist hierbei nicht, dass sie „die Regeln nicht befolgen“, wie dir vielleicht oftmals weisgemacht wird. Meist von Personen, die ich „liebevoll“ als die Scrum-Polizei betitle. Häufig sind es Projektleiter oder Prozessberater, die den Erfolg von Teams als garantiert ansehen, wenn das Team nur den Regeln folgt.

Nichts könnte ferner von der Wahrheit sein.

Das Problem, wenn wir Verkehrsregeln nicht beachten, ist ja nicht, dass wir die Regeln nicht beachten, sondern dass wir uns und andere in ernsthafte Gefahr bringen. So verhält es sich auch mit Scrum. Von diesen Auswirkungen will ich dir heute berichten.

Los geht es mit meinem Lieblings-„Scrum, aber …“:

„Scrum, aber …“ #1: Wir haben keinen Scrum Master.

Ich unterstütze seit einigen Jahren einen Kunden mit Scrum-Trainings.

Mehrmals im Jahr führe ich das beste Training durch, das die Scrum.org zu bieten hat und kaum jemand kennt. Die Rede ist vom „Applying Professional Scrum“-Training. Und seit Jahren höre ich von den Teilnehmern, dass sie Scrum machen, aber keinen Scrum Master im Team haben. Diesem „Scrum, aber …“ begegne ich aber auch bei etablierten Teams. Dort ist der Scrum Master die erste Person, die nicht mehr im Team gebraucht wird. (Zum Großteil sind daran Scrum Master selbst schuld, die ihre Aufgabe darin sehen, sich überflüssig zu machen.)

Aber was ist das ursprüngliche Problem, wenn Teams keinen Scrum Master haben?

Wenn das Herz von Scrum aussetzt, wer soll es dann reanimieren? Mit dem Herz meine ich die empirische Prozesssteuerung. Oder in einfacher Sprache: den Mut zu haben, jeden Sprint zu liefern, sich das Feedback der Kunden anzutun und es daraufhin besser zu machen.

Ein Sprint mag okay sein, aber wir sollten nicht vergessen: Menschen sind bequem. Und dann werden schnell aus einem Sprint mehrere Sprints – und, schwups, ist ein halbes Jahr ohne Kundenkontakt vergangen. Team und Kunden entfernen sich immer weiter voneinander.

Aber ist nicht das Versprechen von Agilität, die sich Unternehmen von Scrum erhoffen, enger Kundenkontakt, um Veränderungen als Wettbewerbsvorteil nutzen zu können?

Was uns direkt zum nächsten „Scrum, aber …“ bringt:

„Scrum, aber …“ #2: Wir machen keine Retrospektiven.

Dieses „Scrum, aber …“ ist eine direkte Folge von: „Wir machen Scrum, haben aber keinen Scrum Master.“

Ich kann mir keine Welt vorstellen, in der Teams einen Scrum Master haben und trotzdem keine Retrospektiven am Ende des Sprints machen. Du?

Das Problem, keine Retrospektiven zu machen, offenbart aus meiner Sicht ein viel grundlegenderes Problem.

Es gibt zwei Arten, an Probleme heranzugehen:

Wir glauben, um erfolgreich zu sein, braucht es Stabilität und Routine. Diese erreichen wir, indem wir Regeln befolgen und auf Expertenanalysen vertrauen. Am Ende entscheidet unser Fachwissen darüber, wie gut wir ein Problem lösen. Für die Lösung eines kniffligen technischen Problems mag die Befragung von Experten und die Analyse von Protokollen ausreichen, um den Bug zu fixen.
Wir glauben, dass Fachwissen wertvoll ist, – um erfolgreich zu sein, braucht es allerdings den Mut zum Lernen und zur ständigen Anpassung an neue Umstände. Diese Art des Vorgehens nutzen wir, wenn wir mit verschiedenen Funktionen experimentieren, um auf Grundlage von Nutzerfeedback mit A/B-Tests neue Produktideen zu validieren.

Scrum ist gemacht, um die zweite Art von Problemen zu lösen.

Und ich behaupte jetzt: Wir Menschen – zumindest ich – setzen alles daran, unsere tägliche Arbeit als Problem der ersten Art zu sehen. Routinen zu folgen, bewährtes Vorgehen anzuwenden und die Anhäufung von Wissen fühlen sich sicher an. Diese Komfortzone zu verlassen – dafür ist die Retrospektive gedacht. Sie hilft Teams, neue Realitäten zu erkennen, ihre Routinen zu hinterfragen und Neues zu wagen.

Und genau da liegt das Problem:

Wenn Teams auf Retrospektiven verzichten, verzichten sie auf das wichtigste Werkzeug, um aus der Komfortzone auszubrechen. Sie verzichten auf die Chance, regelmäßig innezuhalten, blinde Flecken sichtbar zu machen und gemeinsam besser zu werden.

Ohne Retrospektive bleibt alles, wie es ist – selbst wenn es nicht funktioniert.

Scrum wird dann zur Fassade. Und das ist fatal. Denn das Versprechen von Scrum ist nicht, dass es keine Probleme mehr gibt. Sondern dass Teams regelmäßig ihre Probleme erkennen und lösen können. Ken Schwaber beschreibt Scrum gerne als Schwiegermutter. Sie zeigt dir all deine Probleme auf, lösen musst du sie allerdings selbst.

Und diese Schwiegermutter fehlt Teams ohne Retrospektiven.

Was uns zum letzten „Scrum, aber …“ für heute bringt:

„Scrum, aber …“ #3: Wir haben einen Product-Owner, aber …

Im „Professional Scrum Master – Advanced“-Training geben wir den Scrum Mastern zwei Werkzeuge an die Hand.

Zum einen zeigen wir ihnen, wie sie mittels Verbesserung der Definition-of-Done ihrem Unternehmen helfen, das Risiko in der Entwicklung von Produkten zu reduzieren.

Den Inhalt auf den Punkt gebracht: Je besser die Definition-of-Done wirklich beschreibt: „Software wird vom Kunden genutzt“, desto weniger ungeahnte Probleme können noch auftreten.

Du findest es in diesem Bild noch einmal veranschaulicht:

Zum anderen zeigen wir ihnen ein Werkzeug, das das Spannungsfeld aufzeigt, in dem sich viele Product-Owner befinden. Was meine ich, wenn ich von einem Spannungsfeld spreche? Rufen wir uns hierzu die Beschreibung der „Product-Owner-Verantwortung“ aus dem Scrum Guide ins Gedächtnis:

„Der Product-Owner ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt.“

Das Spannungsfeld steckt in den Worten „Maximierung des Wertes des Produkts“, denn dazu sind zwei Dinge nötig:

die Entscheidung zu treffen, dass eine neue Version des Produkts released wird,
die Entscheidung zu treffen, was ins Product-Backlog kommt und was nicht.

Wenn diese zwei Dinge nicht vollumfänglich in den Händen des Product-Owners liegen, ist seine Verantwortung zur „Maximierung des Wertes des Produkts“ eingeschränkt.

Stell dir einen Product-Owner vor, der nur Kontrolle über den Release-Prozess hat, aber keine Kontrolle über das Product-Backlog. Ich würde ihn als „Delivery Manager“ bezeichnen. Und ein Product-Owner, der nur Kontrolle über den Inhalt des Product-Backlogs, aber keine Kontrolle über den Release-Prozess hat – keine Ahnung, wie wir so jemanden nennen sollen. Hast du eine Idee?

Warum erzähle ich dir das alles? Zusammen mit Marc gebe ich das Training jetzt seit vier Jahren. Und über die Jahre erkennen wir einen Trend: Die regelmäßige Auslieferung von funktionierender Software bereitet immer weniger Teams ein Problem. Ein Product-Owner, der eigenständig entscheidet, was ins Product-Backlog kommt und was nicht, ist jedoch immer noch selten.

Und hier verbirgt sich: „Wir machen Scrum, aber wir haben einen Product-Owner, der keine Entscheidungen treffen darf.“

Die Auswirkung davon, wenn Product-Owner eher Delivery-Manager oder Marionetten des Managements sind, ist, dass das dritte Versprechen jeder agilen Transformation für das Unternehmen nicht eingelöst werden kann.

Selbst wenn Veränderungsoptionen erkannt werden, können sie nicht schnell genutzt werden.

Natürlich sind das nicht alle „Scrum, aber …“.

Vielleicht kennst du auch noch welche – dann schreibe sie gerne in die Kommentare.

La importancia del liderazgo en la segurida psicológica, creatividad e innovación de productos

Joel Francia Huambachano — Sun, 16 Nov 2025 19:19:52 +0000

La innovación y el aprendizaje son recursos claves para la ventaja competitiva de las organizaciones en los entornos de cambio. Pero lograr esto requiere de un ambiente donde los equipos tengan un ambiente de seguridad emocional apropiada. Tener equipos motivados, preparados, con hambre para lograr objetivos y mejorar es crítico para que aparezca la creatividad y la innovación de productos. Difícilmente las personas en forma individual pueden lograr los cambios necesarios para producir productos innovadores; es un trabajo de equipo con un liderazgo que promueva esta cultura y la sostenga a través de sus acciones y se comprometa con ese cambio.

Algunas consideraciones para los líderes sobre cómo lograr un ambiente creativo, con equipos motivados, autogestionados para aprender, mejorar y lograr los objetivos son las siguientes:

1. Favorecer el aprendizaje y fomentar el error a través de la experimentación. Los líderes ágiles saben que se puede fallar, pero que es mejor brindar retroalimentación y coaching para emprender las mejoras en base al aprendizaje que castigar el error.

2. En un ambiente de seguridad sicológica, las personas no se sienten intimidadas por el temor del castigo, se sienten dispuestas a tomar riesgos y la iniciativa. Una organización ágil es una donde las personas sienten que ese temor al castigo se ha minimizado y aparece un sentimiento de seguridad para participar y aprender. Entonces la creatividad aparece y crece para llevar a la innovación.

3. Compartir experiencias. Los líderes necesitan crear un ambiente donde se sienta la seguridad de expresarse con libertad sobre los errores y aprendizajes, sobre los problemas y necesidades, sin el temor a sentir que un castigo o reprimenda les puede suceder. Los líderes que proveen este espacio de apertura y respeto pueden lograr una mayor participación y compromiso para lograr los resultados.

4. Mejorar la transparencia. A veces el entorno lleva a ocultar sin darnos cuenta información sobre los problemas en el desarrollo de un producto. Lo contrario sucede cuando el ambiente es de confianza; hay mayor apertura a plantear los desafíos y buscar soluciones más pronto. Este proceso de aprendizaje y de colaboración lleva naturalmente a la innovación de productos.

5. Scrum es un marco cultural basado en un enfoque donde el trabajo en equipo se nutre y crece por el fortalecimiento de un ambiente que promueve el trabajo en equipo y la inteligencia colectiva para lograr los objetivos. Es necesario el liderazgo para que Scrum funcione mejor y se logren mejores resultados en la entrega de valor.

Why Product Transformations Stall: The Evidence-Based Path from Projects to Products

Ralph Jocham — Sun, 16 Nov 2025 07:00:00 +0000

You’re two years into your product transformation. You’ve hired coaches. You’ve reorganized teams around value streams. You’ve trained everyone on product thinking. Yet somehow, the transformation feels stuck.

Leadership keeps asking: “Are we there yet?” Teams keep asking: “What exactly are we trying to achieve?” And you’re asking yourself: “How do I prove this is actually working?”

You’re not alone. Research from McKinsey shows that over half of large companies have attempted transformations, but many get bogged down, taking years with little concrete results to show for it.

The Transformation Theater Problem

Most organizations treat transformation like a project. Set an end date. Hire consultants. Roll out the new structure. Declare victory.

But transformation isn’t a project with a finish line. It’s a fundamental shift in how your organization creates and delivers value. And without measurement systems, you have no idea if that shift is actually happening.

This creates what I call “transformation theater.” Everyone uses the right vocabulary. Teams have product roadmaps. Leadership talks about outcomes over outputs. But underneath, it’s the same old patterns dressed in new language.

The problem isn’t the framework. Whether you’re following Marty Cagan’s product operating model, using Scrum at scale, or implementing OKRs, the framework isn’t what makes transformation work. Evidence is.

Why Measurement Matters More Than Methodology

Without empirical evidence, transformation becomes faith-based. You believe you’re moving in the right direction because the coaches say so, because the books say so, because it feels like progress.

But belief doesn’t pay the bills. Value delivery does.

Evidence-Based Management, recently updated in 2024, provides a framework for “improving value delivery under conditions of uncertainty.” It identifies four key value areas every organization should measure:

Current Value: What value are you delivering to customers and stakeholders right now? This might include customer satisfaction scores, revenue per employee, or user engagement metrics.

Unrealized Value: What’s the gap between current value and potential value? Where are customers struggling? What needs aren’t being met? This is your opportunity space.

Ability to Innovate: Can you actually respond to what you’re learning? How quickly can you experiment with new ideas? How much technical debt is slowing you down?

Time to Market: How long does it take to go from idea to delivered value? What’s your cycle time? Where do things get stuck?

These aren’t vanity metrics. They’re strategic indicators that tell you whether your transformation is creating real capability or just rearranging the org chart.

The Data-Driven Difference

Organizations that embrace measurement transform differently. Research shows that companies using data-driven approaches are three times more likely to report significant improvements in decision-making.

That’s because data creates clarity. When you measure Current Value, you stop arguing about whether your product is successful. The customer satisfaction score tells you. When you measure Time to Market, you stop debating whether you’re moving fast enough. The cycle time data tells you.

Consider flow efficiency. Most teams operate at 15–25% flow efficiency, meaning work spends 75–85% of its time waiting, not being worked on. That’s not a guess. That’s measurable. And once you measure it, you can improve it.

Modern organizations are increasingly adopting DORA metrics and flow metrics to evaluate value delivery. These aren’t academic exercises. They’re practical tools that reveal where transformation is working and where it’s not.

From Big-Bang to Empirical Evolution

The traditional transformation approach is big-bang. Announce the change. Train everyone. Flip the switch. Hope it works.

The empirical approach is different. Start with measurement. Run small experiments. Learn what works in your context. Adapt. Repeat.

Here’s what that looks like in practice:

Before you reorganize around product teams, measure your baseline. What’s your current cycle time from idea to production? What’s your customer satisfaction? What percentage of your engineering capacity goes to new features versus keeping the lights on?

Then make a small change. Not a full reorganization. Maybe you align one team around a specific customer outcome. You give them autonomy to experiment. You measure what happens.

Did cycle time improve? Did customer satisfaction increase? Did the team’s ability to innovate go up? The data tells you whether to expand this approach or try something different.

This is how modern product leadership operates. Vision sets direction. Strategy defines the approach. But execution is guided by evidence, not predetermined plans.

Strategic Clarity Plus Operational Evidence

The magic happens when you connect strategic intent with measurable outcomes. Your strategy says you want to be more responsive to customer needs. Great. How do you know if you’re succeeding?

You measure Unrealized Value. You talk to customers about their biggest struggles. You quantify the gap between what you deliver and what they need. That number becomes your North Star.

Then you measure whether your transformation efforts are closing that gap. Are you moving faster? Are you learning faster? Are you delivering more of what customers actually value?

This creates a feedback loop. Evidence informs strategy. Strategy guides experiments. Experiments generate new evidence. The cycle continues.

It’s not about being “Agile” or “not Agile.” It’s about whether you’re delivering more value this quarter than last quarter. And whether you can prove it.

Start Measuring Before You Start Transforming

If you’re planning a transformation, or stuck in one, here’s my advice: Start with measurement, not methodology.

Establish baseline measurements in the four Evidence-Based Management value areas. You don’t need perfect data. You need directional data that tells you where you are today.

Create short learning loops. Thirty to ninety days. Each loop has a clear hypothesis: “We believe that if we do X, we’ll see Y improvement in Z metric.”

Use the evidence to guide your next experiment. Not a multi-year transformation roadmap. Not a consultant’s blueprint. Your own data, from your own context, showing what’s working.

For example, if you measure Time to Market and discover your average cycle time is six months, don’t immediately restructure everything. Ask: Where does work get stuck? Is it in requirements? In development? In testing? In deployment?

Measure the flow. Find the constraints. Remove one constraint. Measure again. See if it improved. That’s transformation grounded in evidence, not faith.

Transformation isn’t a destination. It’s a capability. The capability to sense value, deliver value, and continuously improve how you deliver value.

That capability isn’t built with frameworks. It’s built with evidence.

If you’d like to explore how Evidence-Based Management can guide your transformation, or if you’re looking to build measurement systems that actually inform strategy, let’s talk. Real transformation starts with real data.

Ralph Jocham is Europe’s first Professional Scrum Trainers, co-author of “Professional Product Owner,” and contributor to the Scrum Guide Expansion Pack. As a ICF ACC certified coach, works with organizations to build Product Operating Models where strategic clarity, operational excellence, and adaptive learning create measurable competitive advantage. Learn more at effective agile.

How to Determine the Basic Structure of Your Organization

Ilia Pavlichenko — Fri, 14 Nov 2025 14:00:52 +0000

The basic structure of an organization must align with the strategy you choose. Unfortunately, many companies define their structure not through strategic analysis but through guesses, examples of well-known organizations, or fashionable approaches. As a result, they often end up with a structure that hinders strategy, provokes conflicts between units, creates excessive coordination, and fails to develop the organizational capabilities the business actually needs.

To understand whether your current structure supports your strategy, I suggest a simple exercise: walk through the four basic types of organizational structures and check which characteristics match your context.

Recently I worked with a group of top executives who went through this exercise during a workshop. Their reaction was very telling. By the end, they literally said:
“The structure we currently have is exactly the one that does not suit us.”
Why? Because they simply walked through the same exercise that I’m about to offer you.

The Four Basic Organizational Structures

There are only four fundamental ways an organization (or any individual unit inside it) can be structured.

Functional organization:

A classical division based on functions: IT, logistics, sales, marketing, compliance, etc.

Functional structure

Product Structure

Autonomous divisions formed around product lines. This means that the top level of the organization consists of product-based units, and within each of them you can still have a functional structure.

In other words, each product may have its own marketing, sales, engineering, etc.

Product structure

Autonomous divisions built around customer segments. Segmentation can be:

Geographic (countries, regions)
By events or JTBD (“I’m buying a car”, “I’m receiving money”)
By role (“carrier”, “shipper”)
By industry (“used cars”, “new cars”, “aviation”, “public sector”)

Product structure

Just as in product organizations, each segment can have its own functional organization inside it: marketing, sales, operations, development, etc.

Multidimensional (Hybrid) Structure

This is used when the organization wants to remain both product-based and customer-based — or when it combines product, segment, and functional logic simultaneously (for example, to achieve economies of scale).

At the top level, such an organization may have different types of units coexisting: functional, product, and customer, and even geographic simultaneously.

Multidimensional structure

How to Understand Which Structure Fits Your Organization

Below are the characteristics associated with each type of structure. Go through all the items and mark them with two flags:

Red — characteristics that do not fit your context and should be avoided
Green — characteristics that describe your organization well

Once you finish, look at the patterns. You will likely see one or two structural types standing out — the ones with the most green and fewest red marks. These are the structures that best fit your business.

Functional organizations:

Have a single line of business.
They are small.
Require common standards.
Have a core capability that requires depth of expertise in one or more functional areas.
Don’t have a diverse line of products.
Don’t compete in the marketplace based on speed of product development cycle times.

Product organizations:

Compete on the basis of product features or being first in the market.
Produce multiple products for separate market segments.
Produce products with short life cycles; speed in product development time is an advantage.
Have a large enough organization to achieve the minimum efficient scale required to duplicate functions across the organization.

Сustomer (segment) organizations:

Important market segments where buyers have strength.
Customer knowledge provides an advantage.
Rapid customer service and product cycle times are required.

Multidimensional or hybrid organizations:

Are large and have multiple product lines and market segments.
Serve global customers and must have cross-border coordination.
Need to maximize both customer and product excellence.
Have managers skilled in managing complexity.

If the results of the exercise show that your current structure does not support your strategy, this is not a failure — it is a signal. A signal that it is time to redesign your organizational structure so that it works for the strategy, not against it.

To explore the topic more deeply, you can read the book Creating Agile Organizations.

Sprint Schedule for the Holidays (video)

Mary Iqbal — Fri, 14 Nov 2025 14:00:02 +0000

What do to about the Sprint schedule during the holidays? Ask the Scrum Team!

Rebel Scrum is the host of the annual Scrum Day conference. Learn more about upcoming 2026 events in Houston, Texas, and Madison, Wisconsin.