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.


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.