I understand Agile. I don’t understand the attachment many people have to what I consider limiting beliefs Scrum has added to it.

#AgileDoesNotHaveToBeThisHard. Insight #7.

I love the essence of Agile at the team level. This is what I believe the essence of Agile is:
Have a team of capable people, managing themselves, be focused on delivering value to their customers. They:
– strive to deliver value as quickly as possible
– create work in small bits, either through a timeboxed for flow model
– collaborate with stakeholders to discover what’s really needed

– use feedback to drive their work, adjusting as needed based on the feedback received
– take an attitude of welcoming changes – both in what needs to be done and in how to do it
– frequently reflect on how to become more effective and adjust their behavior accordingly.
– learn how to do its practices better, challenge those practices, and learn how to change faster over time.
– don’t follow process unless it supports them and they change it when it doesn’t

-don’t rely on documentation or emails to convey information but use direct communication whenever possible
– attend to the quality of the product being built, in particular, the technical practices being used
– recognized that architectures, requirements, and designs will need to emerge

In addition, management provides an effective environment for people in the organization to work in.

In addition to this, I believe that there are many first principles that can further guide us and enable teams to be more effective. This reflects that without theory, experience is blind (Kant) and expensive (Deming).

Systems thinking is also essential so when things go wrong we look to improve the system and not blame the people.

Scrum adds restrictions on this view in an attempt to make things simpler:
– purposefully incomplete
– follow until you understand (which implies you can’t understand at the start)
– a focus on empirical process control
– an underlying belief that we can’t get to cause and effect because we’re in a complex adaptive system
– a lack of a need for management

It’s also removed technical practices and has become more abstract and more confusing in the process.

Without this extra guidance of what works, it requires being immutable so people don’t go off course. This says not to challenge its assumptions. This violates the essence of Agile – learn how to do things better. This tends to have people follow Scrum instead of discerning what improves being Agile.

I’m happy for feedback to help me understand why these limits are useful. But please don’t defend them. Don’t tell me it’s Scrum’s creator’s right to do it. Of course, it is. But why is doing it effective?

And don’t say “Scrum allows what’s being suggested.” I know it allows a lot of things. But if things are important, allowing is less effective than encouraging.

See my first comment if you believe there’s a better way.


Creating Engagement By Taking Responsibility

#AmplioInspiration #2.

Many Scrum Masters before Amplio Value Coach Workshop:

“I don’t have a problem with Scrum’s immutability. It just points out that people aren’t doing Scrum. That’s fine if that’s what they want to do. Just don’t call it Scrum. If they’re not motivated enough or haven’t read the Guide it’s not my fault. I explained to them that Scrum only uncovers their impediments and doesn’t help solve them. That it is purposefully incomplete and that they’d have to fill in the gaps themselves. ”

Scrum Masters AFTER the Amplio Value Coach Workshop

“I’m not going to give up on them just because they aren’t doing Scrum. I want to know why.”

“Maybe it’s a lack of knowledge – What do they need to know? How do I accelerate their learning?”

“Maybe it’s just too difficult – Is there an easier way to get better results?”

“Maybe it’s a lack of motivation – I need to present them the ‘why’”

“Maybe Scrum isn’t suited here – I need to challenge the assumptions we’ve made. I’m not worried about following Scrum, I’m concerned about getting value to our stakeholders.”

By providing the science of Agile, Scrum Masters can better guide their team.

The shift is from making the team figure things out by merely guiding with the Scrum events and the Scrum Master knowing what to do and accelerating the speed at which the team discovers it themselves.

It shifts Scrum from being a passive framework to being a learning and guiding platform.

Ask me about the workshop if interested.


Summarizing the attitude of #Amplio Vs Scrum in a table

#AgileDoesNotHaveToBeThisHard. Insight #5.
The Scrum attitude is surmised from comments like:
Ken Schwaber – Scrum uncovers impediments but doesn’t tell you how to solve them.
Scrum itself is a team framework.
Scrum is “purposefully incomplete.”
Scrum is designed for complex adaptive systems.
“Follow until you understand.”

The Amplio attitude is what I’ve been using to create Amplio.

To me the bottom row is akin to driving on the wrong side of the road, looking at the rear view mirror, complaining about how difficult it is.


If you’re baking and leaving out ingredients, don’t expect things to come out well. Same with Agile.

#AgileDoesNotHaveToBeThisHard. Insight #4.

 “Simple can be harder than complex: You have to work hard to get your thinking clean to make it simple. But it’s worth it in the end because once you get there, you can move mountains.” Steve Jobs

Being purposefully incomplete is not simple.
I also don’t believe in putting the onus on agilists to solve problems that have been already solved over and over.

I see people complain about how hard Agile is or who just accept they are not going to do it well. But I see they are leaving things out. The results should be expected. But they do not have to be accepted.

I don’t like frameworks designed to be followed.
I like frameworks designed as support systems that help us think more clearly.

Here are some concepts and practices I’ve seen that help this in the knowledge workspace that are infrequently used. Each one that’s missing adds to the difficult teams face.

I don’t believe you are justified in complaining (or promoting the idea) that product development is difficult if you’re not using (or teaching) these. Note: this is a partial list.

– First principles
– value streams
– using feedback to be effective in complex situations

– understanding the values and success criteria of stakeholders
– MVPs a la Eric Ries
– Minimum Business Increments
– customer journey

Value Creation Structures
– focused solution teams
– borrowed team member
– shared team member

Supporting learning
– using theory to access people’s dormant knowledge
– checklists
– virtual collaboration boards

Coaching methods
– how to reduce the learning curve using what people already almost know

– team estimation
– planning based on MBIs

– test first
– automated testing

Learning these things takes some time. But more time is wasted with ineffective ways of teaching than it takes learning these concepts. The above integrated with common concepts represents no more than 5 days of workshops and takes you from team to midscale (up to 450 people in development).

You can get introduced to these for free in my #Amplio Community of Practice. Sessions Monday at 1-3pm pacific and Wednesdays 7-9am Pacific through mid-September. All sessions recorded. See picture for how to register and get more information.


The Vision I’m Working Toward

#amplioInspiration #1

When I formed Net Objectives in 1999 its tagline was “Software Development without suffering.”

Ironically, as Agile has crossed the chasm to include both early and late adopters I see even more suffering.

Our popular frameworks are geared towards getting people to follow and be inured to difficulty from the team to organization levels.

There is a better way.

Many of you sense this. Some of you know this.

I am working towards this, as are several others.

It is time to clear the space created by embracing complexity, failing fast, and following until you understand. These statements both demean and disempower people.

We are more capable than this.

Managers, in particular, have been demeaned. I believe most want to make a difference. Unfortunately, the Agile world first ignored them, then vilified them (“chickens and pigs”, “permafrost”), and is now trying to make them subservient to the teams.

Most managers I know got where they are by being great problem solvers. Now, they are being provided little to do in the Agile space – certainly not being given opportunities worthy of their skills. The reaction of many is predictable.

Times are changing. The shine of Agile has already been lost. And the Scrum Master and Agile coaching roles are being questioned.

But the dogma of the Agile camps grows each year.

I believe there is a better way.

We can have joy in our work. But we must learn to think for ourselves.

This can be scary. It is often easier to just follow the way everyone else is. If things don’t work out simply shrug the blame off to Agile.

I am working towards making learning and improving the standard.

Being more joyful.

This takes work, of course.

We can be effective and strive for improvement. Not merely remove impediments we didn’t need to hit in the first place.

There is a difference between working hard to achieve results and struggling because we have been told mastery is difficult. Mastery of innovation is rarely achieved. But mastery of how we work is not that difficult. Saying so is self-serving.

There are two insights that indicate why so many are stuck.

Edgar Schein’s “We do not think and talk about what we see. We see what we are able to think and talk about.”

Our current methods limit what we think and talk about. Any attempt at questioning them invites you to personal attacks.

Our popular frameworks restrict us when they should be guiding us and opening up new opportunities, not making us figure things out within restrictive frameworks.

Consider Eli Goldratt’s observation that “A comfort zone has less to do with control and more to do with knowledge.”

The limitations I’ve mentioned earlier keep us from understanding.

They are self-serving and have caused the stagnation we see now.

I see a better future.

I hope you do as well.


Where did the idea that we can’t find an actionable root cause to a problem or have a well-defined workflow to discover and build what’s needed or that there aren’t first principles on which product development is based that we can use to guide us?

#AgileDoesNotHaveToBeThisHard insight #2.
Probably from those who gave up trying. And those whose business models depend upon these limits being true.

22 years ago maybe this made sense.

Not today.

If you want to learn about first principles and how to tell if a change will be an improvement, join the Amplio Community of Practice Members (free) and see the recordings.