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.


#3 The Cost of Simple

#AgileDoesNotHaveToBeThisHard. Insight #3.

The Cost of Simple
How the focus on simple frameworks puts the onus on the adopters.

The idea that you need a simple framework to help people in product development is incorrect.

If a framework is simple but puts the onus on its users, the overall combination of people and framework is not simple. We must take a systems approach here and look at the whole.

Simple is not the point. Effective is.

Effective means you provide the right information at the right time.

And since we’re talking about Agile, this should be information that helps people make better decisions, not telling them what to do.

There is an irony that we rail against management when they tell people what to do but accept so many Scrum trainers that tell teams to “follow until they understand.”

We all know how it’s easier to tell people what to do. Simple frameworks must resort to that.

In the same way want managers to guide instead of telling, we want our frameworks to guide instead of telling.

Frameworks need to be designed to bring forth people’s dormant knowledge – that is, what they know intuitively – that takes advantage of their experience. They must help us build a mental model of what to do to guide us.

This simplifies people’s work because they will discover they already know most of what’s needed.

This requires more than a simplistic approach.

Being purposefully incomplete merely means more work for the adopters.

The content is always incomplete.

The guidance system doesn’t have to be.

Like a GPS, only part of it needs to be displayed, but if it’s not there when you need it, work gets complicated.

“A good tool improves the way you work. A great tool improves the way you think.” Jeff Duntemann

An approach that doesn’t provide a model to understand why it works will be more difficult to use than one that does.

Kant – “Experience without theory is blind.”

Maybe that explains why you have to hit impediments in Scrum instead of avoiding them.

I’m continuing my series on understanding what’s needed today. Join the free Amplio Community of Practice for weekly insights on how to improve your work.


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.


Stop conflating the complexity of what we’re creating with the complexity of how we create it.

Agile does not have to be this hard insight #1.

I continually see comments like: “in complex work, more is unknown than known.” And then a discussion about complexity is used as a way to limit what can be done. But there are two fallacies here.

The first is that the complexity of what we’re building has the same nature as the complexity of our methods used in building it.

The second is that we need to worry about complexity in the first place. Our real enemy is non-linearity. A non-linear event is one where a small change creates a big result – usually detrimental. The focus on complexity is often counter-productive because of a “what’s the point, it’s all complex anyway” attitude.

But this is the wrong attitude to take.

Human-centered design and a focus on the customer journey can help in seeing what to do regarding creating value.

Regarding our work process, we must turn to a scientific approach – blending empiricism with continually building a theory that explains things. This theory already exists in the form of theories of Flow, Lean, and the Theory of Constraints. All of which are based on systems thinking.

Fortunately, even though the nature of what we’re building and how we are building it are different, the solution to staying on track is the same – quick feedback. The quicker this feedback is the better. And the ability to use what’s learned quickly is essential. This is why a flow model is often more effective than an incremental one.

Want to learn more? Join my free Amplio Community of Practice where over the 8 week period from July 17- September 8th I’m recording the content for my Amplio Development and my upcoming #Amplio Midscale Masterclasses. See first comment for more.

Forthcoming insights:
#2. How the focus on simple frameworks puts the onus on the adopters.
#3. How a lack of theory sets up resistance in management.
#4. Use alignment to lower coordination costs.


Two Kinds of People Promoting Frameworks

George Box once said “all models are wrong, some are useful.”

A paraphrase of that could be “all frameworks are wrong, some are useful.”

Some people take that to mean that comparing frameworks makes no sense since they all are wrong. That it’s up to the people using them to make the best of them.

Unfortunately, this takes away incentive to continuously improve a framework. Instead, we see a justification to accept a framework as is.

Another group of people take it to mean “my framework is not as good as it can be, I’m going to strive for it to be more useful.” This attitude incorporates a sense of responsibility for the framework – one of looking to see how it can be used and misused and working to improve both.

Attend to the attitude of the people promoting frameworks. That will tell you a lot about whether you will be on your own with it or if those promoting it will be there to help you with improving it.


Knowledge is not power. Wisdom is power.

Knowledge is knowing a tomato is a fruit.

Wisdom is knowing not to put a tomato in a fruit salad.

The Agile training industry is overly concerned with knowledge.

It certifies in knowledge.

It doesn’t notice its lack of attention to wisdom.

It puts that on the people gaining the knowledge.

We need to shift from following knowledge to using wisdom.