Talk to your team about Modern Agile. It’s a worthwhile experiment. Here’s why.

Modern Agile In 30 Seconds

Modern Agile has four guiding principles:

• Make people awesome
• Make safety a prerequisite
• Experiment and learn rapidly
• Deliver value continuously You can learn more about these guiding principles at the Modern Agile site. I also encourage you to check out Joshua Kerievsky’s talk at Agile 2016, as well as join the Slack group (click on Community from the main site). This post is not going to describe the principles in depth.

“Make people awesome” tends to trip some people up, but my design friends (UX, Service Design, etc.) will probably get it immediately:

In modern agile we ask how we can make people in our ecosystem awesome. This includes the people who use, make, buy, sell or fund our products or servicesFolks in the Agile community sometimes nitpick on the work “make” (assuming it means force), but that isn’t the intent.

What is my involvement with Modern Agile?

I’m a member of the community, and I have been toying with getting more involved somehow. I’ve derived value from using the Modern Agile principles (see below). I am not getting paid for this, nor is there anything to buy/sell.

The nice thing about MA is that even if it were to fade into oblivion (as many of these things do), I would still get value out of it. Jump into the Slack community to learn more (main site, community tab).

Valuable?

In my personal opinion, Modern Agile is valuable for three reasons:

1. embraces whole-org agility, and aligns our efforts around delivering value to the humans (internal and external) in our ecosystems,
2. discusses an extremely important prerequiste for agility (safety), and
3. strengthens the Agile community by focusing on the core, and encourages us to continuously search for lighter weight tools, and embrace diverse viewpoints and approaches (adapt and improve) To me, at least, it is a helpful frame.

Why? I’ll dig into two big reasons below.

More Effective Conversations

Software product development is a whole-organization sport. I’m not a big fan of distinguishing between “the team” and “the business” (or “business people”, or “sponsors”). I find Modern Agile much easier to explain to non-developers, and more likely to trigger meaningful conversations. I need to communicate effectively to non-developers, because the bottleneck is rarely at the software development team level. These are the people — the folks in finance, marketing, the C-suite, product, logistics, UX, and design — that need to change their ways.

It is easy to get bogged down on words like process, tools, working software, contracts, negotiations, plans, requirements, projects, and self-organizing. The Agile Manifesto resonates deeply with me personally, but I find it hard to generate that same excitement when talking to other people (especially non-developers). Many conversations go sideways quibbling over a word here, or an assumption there. But throw something powerful like “make safety is a prerequisite” or “deliver value continuously” into the mix, and the conversation tends (in my experience) to switch gears.

I respect that the Agile Manifesto has not been updated, and love it for what it is, but personally I wish the spirit of embracing change, tuning, and adjustment had been applied to the Manifesto itself. It (the spirit) certainly inspires the Agile community, which is continuously practicing, adapting, and refining (when it isn’t too busy selling and certifying).

This is probably why I find myself gravitating towards — or at least using in day to day work — the Modern Agile principles. It IS NOT a repudiation of the Manifesto or Scrum Guide at all. It simply works better. I’ve found the same thing with some of the Kanban Method principles like “start with what you do now” and “agree to pursue incremental, evolutionary change”. People pay attention. We need to build more bridges.

Agile == Scrum

Many people associate Agile with Scrum roles, artifacts, events, and what are known as “Scrum patterns” (tools/methods that align with Scrum values and theory). This makes sense since Scrum is the most popular Agile-inspired framework. But here’s the problem. A person looking at the Agile Manifesto (or Modern Agile) will naturally ask “well, how do WE actually do it HERE?” They’ll then list some needs from their particular context — going faster, accountability, forecasts, reporting, titles, how UX fits in, scaling challenges, performance management, etc. — and wonder how to achieve those goals using Scrum (because Scrum is where you start, right?)

What we’re left with is TONS of accumulated patterns, books, conference videos, training material, and tribal knowledge. These patterns are NOT Scrum rules, but they are Agile-Scrum spawn. This is what happens when you have something promising that works (Scrum does work, sometimes). People try to fill in the blanks. Over the years, these various ways morph, adapt, fork, multiple, decay, and die.

Couple that with aggressive two-day certification schemes, and the innate customer desire for a silver bullet, and you have lots of people running around “doing Agile” by doing Scrum and a host of potentially outdated and overly prescriptive and ineffective patterns. There’s something about the spirit of the Manifesto that is being obscured. And we are potentially ignoring lightweight ways that — gasp — sometimes break the Scrum rules, as well as the vital technical practices that Scrum purposefully leaves out.

Recap

To Recap: 1) the Agile Manifesto isn’t going to be updated (totally respect that), 2) Scrum is popular (totally respect that), 3) lots of teams abuse the spirit of Scrum (it happens), 4) certification fixates a wide population on the basic practices (totally predictable, somewhat unavoidable, and it is lucrative), and 5) software product development is a full-org pursuit.

Diversity of Perspectives

I’ve covered more effective conversation, but there’s something else…

As a community we need to “leave room” for non-Scrum tools/methods/frameworks/approaches. I’d say the same thing for the code-craft communities…we need that voice to ring louder. Not because Scrum is bad, but because a balance of voices is vital to a thriving community. In fact, I see a strong need to focus on the core values of Scrum as well, as they are frequently obscured.

Otherwise, you’ll see a split of some sort, or a deepening of the current divide. I can very much see a scenario where you see something like LeanAgile (with DevOps, and a strong craft component, and a awareness of scaling) fork off from what we see as AgileScrum and SaFE. Maybe this is inevitable, who knows, but I feel that Modern Agile is an important perspective and frame.

So…

Give Modern Agile a look. Go through the principles with your team. Have a conversation. The nice thing about MA, is that even if you stop there — just talking through the principles — you’ll probably learn something.