Microsoft has officially confirmed that they’re making Widgets in Windows 11 quieter by default, which is corporate language that means they will stop showing the MSN feed when you hover over the Widgets.

The new Widgets experience is gradually rolling out with the Windows 11 Insider Experimental Preview Build 26300.8346, and Microsoft’s goal here is to make Widgets less distracting and overwhelming.

Right now, just brushing your cursor over the weather icon in the bottom-left corner of the taskbar triggers the massive Widgets board to slide out, showing a cluttered grid of mostly low-value content.

It’s quite obvious that Microsoft was aware that all users found the Discover feed on the Widgets board bothersome. However, the fact that the feed contained ads likely made the Widgets board a revenue driver for the company. So, when Microsoft said “we’re testing a new set of default settings [in Widgets] designed to reduce unexpected alerts and visual interruptions.”, I was genuinely surprised.

It’s not like the company had a choice either, as even Satya Nadella admits that Microsoft needs to “win back” Windows 11 fans.

Either way, Microsoft is testing the new Widget experience with Insiders by modifying a few default settings.

All changes coming to Widgets in Windows 11:

1. Windows will now disable “Open on hover” by default. So only a deliberate click on the Widgets icon brings up the Widgets interface.
2. Turning off taskbar badging, which is the red notification dots or alerts that appear over the Widgets icon to notify you of the number of breaking news and other alerts. These badges are a huge distraction, and there is no practical reason to have them.
3. Limiting taskbar alerts, which are the animated Widgets icons that cycle through dynamic alerts like severe weather or stock market changes. These won’t show up anymore until you have already interacted with the Widgets board.
4. When launching the Widgets board for the first time, it will show you the core “widgets experience” (your pinned mini-apps like weather, calendar, and system stats) instead of bombarding you with the MSN news feed.

The last change has to be the most impressive one, especially as it comes from Microsoft, which is infamous for data collection to show personalized ads.

You can already turn off these features manually, but most people who use Windows aren’t aware of it, and some don’t seem to care. While Microsoft got away with it for a while, now the situation has gotten out of hand, and people are switching away from Windows 11 because of forced features like Copilot and MSN feed in Widgets.

Now, Microsoft is on a path to rebuild Windows 11 around what users actually want. That said, the Widget features or the lack of them are currently under testing, and there is no mention about when it will reach regular users.

Meanwhile, you can turn off defaults in Widgets manually.

How to turn off Open Widgets board on hover?

Hover over the Widgets or press Win + W, click the settings icon on the top right, and turn off the toggle that says Open Widgets board on hover.

How to turn off MSN feed in Widgets?

Just below the Open Widgets board on hover, click “Show or hide feeds”, then turn off the toggle for Feed. Click Turn off when prompted.

How to turn off Widgets completely in Windows 11?

Go to Settings > Personalization > Taskbar > turn off the toggle for Widgets
You’ll then have a cleaner taskbar.

You’ll then have a cleaner taskbar.

But I actually prefer to have something on the left side, and just having the weather is good enough. But I do not need to see the MSN feed when I hover over it, nor do I want to be distracted by constant alerts.

Microsoft recently said that they want to make Windows 11 a calmer OS with fewer upsells or ads. Changing the default behavior of the Widgets board so it shows only your widgets when deliberately clicked, while hiding the MSN feed unless you want to see it, is them keeping their promise.

Speaking of the MSN feed, do not doubt that Microsoft is going to phase it out. In fact, a new design change is coming to the MSN feed in the Widgets board that would give each tile extra rounded corners, like the ones in Copilot, that Edge is also trying to mimic.

To be honest, this new cleaner design with clear separation between the Widgets and the MSN Discover feed does reduce the claustrophobic feeling of the old MSN + Widgets look. So, maybe if Microsoft focuses on making MSN feed better with less clickbait and more useful content (without AI-generated summaries), then there might be some genuine takers for the decades-old MSN feed.

Still, it doesn’t look like Microsoft will go back on their promise, and as this new Widget experience reaches all users, the MSN feed, random alerts, and open on hover will all be turned off by default.

Anyway, it’ll be interesting to see how Microsoft plans to recoup the lost revenue from MSN feed, especially as Bing officially crosses 1 billion users for the first time.

The post Microsoft is finally turning off the MSN feed and ads in Windows 11 Widgets by default appeared first on Windows Latest

Windows 11 users have a new, redesigned and faster Run dialog to look forward to, says Microsoft. After months of working rebuilding it from the ground up, the company says that the new Run dialog is gradually rolling out to users. To start with, it is – predictably – Windows Insiders who get first access to the new tool, but it should not be long before everyone is able to use it. But to get access right now, you need to be signed up to the correct channel and opt to enable the feature manually. The channel you need is… [Continue Reading]

BONUS: Why Your Agile Transformation Keeps Snapping Back — And What Systems Thinking Says About It

Natalia Curusi co-authored a book that doesn't tell you what agile should look like — it tells you what actually happens when you try to transform an organization. Friday-night deployments, zombie teams going through the motions, transformations that met a wall of silence. In this episode, we unpack the real lessons from the front lines: how personal values drive the shift to agile, why some teams have all the ceremonies but none of the substance, and what systems thinking reveals about why transformations fail — or snap back.

When Your Values Don't Match Your Ways of Working

"I felt like there is a mismatch in my values, my moral values and principles, and customer-centric orientation. So when I found out about Agile around 2010, I understood — okay, this is the answer. Now I have the answer how I can map my moral values and principles with software delivery."

 

Natalia's journey to agile didn't start with a methodology — it started with a gut feeling that something was wrong. Working in large corporations in the early 2000s with fixed-scope contracts, late deployments, and scripts running directly in production, she sensed a disconnect between how work was done and how it should be done. When she moved to a smaller company around 2010 and experienced transparency, collaboration, and the freedom to ask any question without fear, she realized this was the agile mindset — even before she knew the term. The key insight: agile isn't something you adopt, it's something that aligns with values you may already hold. That alignment between personal principles and ways of working is what makes the difference between going through the motions and genuinely transforming how a team operates.

Don't Be an Agile Zombie

"The first thing I observe — if I go to some of the ceremonies and I see that stand-up becomes like a status meeting, and everybody is reporting to somebody. People are afraid to say some of the things, afraid to escalate risks or assumptions."

 

One of the strongest chapters in the book is titled "Don't Be an Agile Zombie." Natalia describes teams that have all the boards, all the roles, all the right meeting cadences — but nothing is actually changing. The Scrum Master becomes a secretary. The Product Owner is a proxy afraid to make decisions. The tell-tale signs? Fear and formality. When people report upward instead of collaborating sideways, when risks go unspoken because the environment punishes transparency, that's a watermelon project — green on the outside, red on the inside. Natalia's approach starts with observing the tone and dynamics in ceremonies. If the stand-up feels like a status report and not a coordination meeting, something deeper is broken. And her advice is direct: if an organization is delivering waterfall and happy with the predictability and value, that's fine — just call it what it is. Don't put lipstick on a pig. As Rebecca Homkes discussed on this podcast, the key is to communicate the truth with care, but communicate it nonetheless.

Task-Driven vs. Value-Driven: The Real Spectrum

"It's not right to say that you are agile if you are not. Just name the things how they are — name the things using the right word."

 

Rather than the old waterfall-vs-agile binary, a more useful lens is the spectrum between task-driven and value-driven product development. On the task-driven side, somebody creates the list of tasks — requirements, architecture document, design document — and a project manager distributes them. Teams execute but aren't asked to be creative or adaptable. On the value-driven side, what matters is the impact of what teams build. Value is discovered through the dynamic interaction of functionality with customers — it can't be predetermined. Most organizations sit somewhere on this spectrum, and many are slowly moving toward the value-driven end even if they don't call it agile. The practical takeaway: transformation should be tailored to where an organization actually is, not where a framework says it should be. The book argues for a pragmatic, hybrid approach rather than evangelical purity.

Systems Thinking: Why Transformations Snap Back

"We did a big agile transformation — five years of real transformation. Then the company was bought, merged with a bigger payment provider. And now they are working with SAFe. And that's the end of the story."

 

In the later part of the book, Natalia and her co-author move into systems thinking — Cynefin, the Iceberg Model, causal loop diagrams. Many agile practitioners stop before they get here because it feels academic. But Natalia argues it's essential, and she illustrates why with a real example: a payment company that went through five years of successful agile transformation using LeSS, only to be acquired by a larger organization that pushed SAFe — and the transformation snapped back. This is the basin of attraction concept: a system has to pass through a point of genuine disruption before it can settle into a new stable state. Without that, it returns to where it was. For practitioners looking to get started with systems thinking, Natalia recommends The Fifth Discipline by Peter Senge and learning to build causal loop diagrams — a practical tool that creates productive conversations about how organizational dynamics actually work.

The Post-Agile Era: Beyond Labels

"It's like comparing apples and orchestras. You cannot compare agile and AI — they are completely different things. Agile is not enough, but it's also not dead."

 

Natalia addresses the "Agile is dead" debate head-on. Her argument: comparing agile to AI is a category error. An apple cannot play an orchestra, and an orchestra cannot replace an apple — they serve entirely different purposes. AI can handle a significant portion of day-to-day tasks, but it lacks common sense, empathy, and the ability to read a room. Rather than declaring agile dead, Natalia sees a post-agile era — not one where agile disappears, but where we move beyond the label wars. The trends that matter aren't about whether agile is popular; they're about collaboration, adaptability, and understanding how teams and organizations actually work. We can finally talk about what matters in our industry without being pressured to label it.

About Natalia Curusi

Natalia Curusi is an Agile Coach at Endava with over 20 years in software delivery, specializing in agile transformations, delivery optimization, and systems thinking. She leads Asia Pacific initiatives driving business agility. She is co-author of From Resistance to Resilience: Practical Agile Lessons for Transformation.

 

You can link with Natalia Curusi on LinkedIn and visit her website at nataliacurusi.com. You can also join the Agile Continuum community on LinkedIn.

Download audio: https://traffic.libsyn.com/secure/scrummastertoolbox/20260502_Natalia_Curusi_BONUS.mp3?dest-id=246429

In March 2026, I challenged GitHub Copilot to build a Visual Studio extension, "Version Sync," from scratch without coding. Despite initial failures and needing extensive feedback, it succeeded in creating an extension to sync project version numbers. However, Copilot's code quality was lacking, emphasizing that AI can't replace experienced developers.

A lot of the "DDD-ish" .NET code I review scatters business rules across handlers, validators, and controllers, and barely puts any on the domain model itself.

Each copy of the same rule drifts a little over time, and whether a given object is valid starts to depend on which path the caller took to reach it.

You can absolutely build a working system this way. I've shipped plenty of procedural code with enough if-checks to keep things in line. But there's a cleaner way to think about it, and it starts with a single idea.

What Is an Invariant?

An invariant is a rule about an object that must hold true for as long as the object exists.

Not just when you save it, or when a validator happens to run. The rule has to hold every time you touch the object, no matter how it got into memory.

A few examples:

• A Course always has a non-empty title.
• An Order total always equals the sum of its line items.
• A Subscription is in exactly one state: Trial, Active, PastDue, or Canceled.
• A published course has at least one lesson.

None of these mention validation, persistence, or HTTP. They're statements about the domain, and they should be true regardless of how the object got loaded.

Where Procedural Code Goes Wrong

Take a simple Course written the way most CRUD-ish .NET apps still write it:

public class Course
{
    public string Title { get; set; }
    public CourseStatus Status { get; set; }
    public DateTime? PublishedOn { get; set; }
    public decimal Price { get; set; }
}

There's no constructor and every property has a public setter, so the class is willing to accept any combination of values.

To keep the data correct, the rules end up scattered across the application:

• CreateCourseValidator checks the title isn't empty.
• PublishCourseHandler sets Status and PublishedOn, and remembers to check the course isn't already published.
• ChangePriceHandler checks the course isn't archived.
• A new endpoint shows up, someone copies an existing handler, and the archive check quietly goes missing.

Every rule lives in a place that just happens to be on the path the request took. Nothing on the Course itself prevents it from drifting into an invalid state.

That's the real cost of an anemic model. It isn't that there's no behavior on the class. It's that the class makes no promises, so every caller has to enforce the rules itself.

Always-Valid: The Model as the Source of Truth

The shift I want to make is simple: the model never accepts an invalid state.

If you're holding a Course reference, you can trust it. You don't need an if (course.Title is null) somewhere down the call stack, you don't need a parallel validator double-checking, and you don't need to hope the handler remembered the right guard.

Three moves get you there.

1. Block construction of invalid objects

A Course without a title shouldn't exist, so the easiest fix is to make it impossible to construct.

public class Course
{
    private Course(CourseId id, string title, Money price)
    {
        Id = id;
        Title = title;
        Price = price;
        Status = CourseStatus.Draft;
    }

    public static Result<Course> Create(string title, Money price)
    {
        if (string.IsNullOrWhiteSpace(title))
        {
            return CourseErrors.TitleRequired;
        }

        return new Course(CourseId.New(), title, price);
    }
}

A private constructor with a static factory gives you a single, well-known place where a Course can come into existence, and that's where the validation runs. From that point on, any code holding a Course reference can assume it has a valid title.

Value objects like Money apply the same idea at a smaller scope, so a Money can't be negative or be missing its currency by the time you're using it.

2. Encapsulate state transitions

Once construction is locked down, the next leak is state changes. The class should control how it changes, instead of leaving that up to whoever has a reference to it. No setters, and every change goes through a method that knows the rules.

public Result Publish(IDateTimeProvider clock)
{
    if (Status != CourseStatus.Draft)
    {
        return CourseErrors.AlreadyPublished;
    }

    if (_lessons.Count == 0)
    {
        return CourseErrors.CannotPublishWithoutLessons;
    }

    Status = CourseStatus.Published;
    PublishedOn = clock.UtcNow;
    return Result.Success();
}

The handler doesn't need to know whether the course was already published, and it doesn't need to remember to check for empty lessons. It calls Publish and propagates whatever result comes back. The rule lives next to the state it protects, in one place.

3. Encapsulate the aggregate

Some rules span multiple entities inside the same boundary. The aggregate root is the right place to enforce those, because it's the transactional boundary.

Take this rule: a published course must have at least one lesson, and lessons can't be removed once it's published.

The wrong way is to expose Lessons as a mutable collection and rely on the application service to remember the rule everywhere it's used. The right way is to keep the collection private and force every change through the root:

public sealed class Course
{
    private readonly List<Lesson> _lessons = [];
    public IReadOnlyCollection<Lesson> Lessons => _lessons.AsReadOnly();

    public Result RemoveLesson(LessonId id)
    {
        if (Status == CourseStatus.Published)
        {
            return CourseErrors.CannotModifyPublishedLessons;
        }

        var lesson = _lessons.FirstOrDefault(l => l.Id == id);
        if (lesson is null)
        {
            return CourseErrors.LessonNotFound;
        }

        _lessons.Remove(lesson);
        return Result.Success();
    }
}

When a rule needs to span two aggregates instead of one, that's a different problem, and I'd reach for a domain event rather than letting one aggregate reach into another.

What You Actually Get

You can write the same system procedurally, and it can work well. The thing you give up is trust.

In a procedural system, every caller shares responsibility for not breaking the rules. In an always-valid model, that responsibility lives on the domain model. The difference compounds over time:

• Validators don't drift, because there's nothing to duplicate.
• Code reviews focus on behavior instead of "did we forget a check?".
• New endpoints can't accidentally bypass a rule that lives on the entity.
• Tests stop covering scenarios that aren't even expressible.

The model goes from being a passive data carrier to being the smallest, sharpest place where the business rules live.

Fundamentally, this is about encapsulation. The model encapsulates the rules that govern its state, and the rest of the system interacts with it through a well-defined interface. That leads to cleaner code, fewer bugs, and a more maintainable system overall.

Summary

An invariant is a rule that must always hold true while the object exists, and the cleanest place to enforce it is on the object itself.

• Construction invariants belong in a private constructor behind a factory.
• State transition invariants belong in methods that own the state they change.
• Aggregate-wide invariants belong on the root, with child entities accessed only through it.

The tradeoff is that you give up the freedom to write procedural code that could be easier to understand in the short term, but you get a model that you can trust to always be valid.

If you want to go deeper into modeling aggregates, value objects, and rich behavior across a real system, I think you will enjoy Pragmatic Domain-Driven Design.

See you next week.

---