Why We Need an Attitude Adjustment in Agile

Let’s say you were going to buy a car. You walked into the showroom and saw amazing cars and were really excited. You buy the car, have a lot of troubles driving it and when you take it back they respond with:

1. Yes, the instructions are simple, but driving the car is difficult to master
2. The car is so sophisticated, it’s not possible to have full predictability
3. Well, we thought this aspect of the car was good enough
4. Most people don’t have trouble with this, but since you do, we have this extra education for you

How would you react to that?

I believe these four attitudes are prevalent in many Agile approaches. If you are a practitioner and wouldn't accept this for a car I suggest not accepting it from the approach you're taking for improvement.

If you are a consultant, I suspect you don't mean to be doing this. But if you are, or see others doing it, please stop and please help others stop.

Why saying something is difficult to master is insidious

First of all, it gives those promoting it permission not to try to get better.

Of course people are going to have problems. But we don't have to suffer in solving them. They are not interested in mastering a framework anyway – they want to improve their work. So after they have a bunch of challenges they start looking for something else. Unfortunately, if they’ve typically not been given anything else and usually end up just accommodate their problems. If this sounds like the foundation for Scrumbut it is.

Can’t achieve predictability

Well, of course we can’t. Small, innocuous events sometimes turn out to have big repercussions. The Concorde disaster would not have happened if a small strip of metal hadn’t fallen off the plane that had taken of just before the Concorde did. We can never be fully predictable. When in Vegas, I don't know if the ball is going to land on red, black or green, but I know more money is staying at the table. We shouldn’t resign ourselves to a lack of it, we should see how much we can get and always get feedback. It turns out that looking at a complex problem in a different way (see Dealing with Complexity by Creating a Bias For Simplicity). Looking at a complex problem in a different way often results in a solution that is predictably good. But we’ll never find it if we don’t look for it.

Good Enough

In the early days of Agile there was not a well-defined manner of describing the relationship between initiatives, release, features, stories and tasks. Since we were at the team level and had either a product owner or client who had the big picture in mind, they could have us start building something and then say “it’s good enough.” But this only worked because the big picture was present in the person's mind who was driving things. With Agile at scale now, there is no artifact that represents this other than the Minimum Business Increment (MBI), which, unfortunately is still not used by any of the popular frameworks. MBIs does not take the start small and build up until it's enough. Rather it looks at what is the greatest value that can be delivered soonest. It creates the overall view of things and creates a context for all of the work.

Good enough and too much are not the only alternatives.

Some people just don’t get it

I know people mean well, but I often hear those using Scrum based methods talk about how people don’t get it. Then, of course, they are nice to figure out how to explain things better. But perhaps what’s needed is a recognition that when people can’t make certain jumps in logic, instead of trying to improve their ability to make the jump (or just do it) maybe we need to make what we are suggesting people do easier to understand. In others words, when people don't understand something about Agile (e.g. tying the big picture to the small task) perhaps it's not an indication of the person's inability as much as it's an indication that something is missing. I am not trying to pick on Scrum, but, in fact, it has a different education and framework definition approach than Lean, Kanban, Theory of constraints and Flow,

The deadly synergy of these four attitudes

When someone doesn’t understand something, this attitude will make it easier to just thing it’s good enough and just try to explain it better instead of trying to improve it.

When people have difficulty with an approach it’s easier to just shrug our shoulders and explain that it’s difficult to master.

While we can accept that predictability is difficult we should not accept less predictability than we can because our understanding is good enough.

The bottom line

The bottom line of these four attitudes is:

1)     They take away incentives from those promoting frameworks that promote these ideas

2)     They are self-serving as well (after all, it’s not the promoters’ fault that things are not working well)

3)     They encourage practitioners to accept things that are less than ideal

4)     They put limits on what we should be striving for

A better attitude

The fifth principle of Lean Thinking: Banish Waste and Create Wealth in Your Organization by Womack and Jones, is “perfection.” This is not an OCD approach or a going beyond what’s useful attitude. Rather we strive for perfection not so much to achieve it but to continuously improve. This striving is also how we learn.

But we must go beyond our current acceptance of the common failures many teams hit. 80 years ago Deming established that the eco-system people find themselves in causes most of the challenges people experience. Our responsibility is to continue to improve the system. If we see people consistently make the same mistakes we should not attribute the failure to the people, but more to the system.

This is the anti-thesis of what I hear from many Scrum consultants - "Scrum would work if people would just do it." That may be true, but Scrum may not be the best approach for the problem a team faces. Calling their failures ScrumButs only makes the problem worse. From Scrum.org - "ScrumButs mean that Scrum has exposed a dysfunction that is contributing to the problem, but is too hard to fix. A ScrumBut retains the problem while modifying Scrum to make it invisible so that the dysfunction is no longer a thorn in the side of the team." There is an implication that if the team would put more effort into it, or take the time to figure Scrum out better, we could avoid these. This is a big, assumption.

Our attitude shift would be to ask "why is it so hard to fix this impediment? Is there a better approach, even if it means going beyond Scrum?" In particular, consultants and promoters of frameworks must take responsibility when practitioners have trouble. This does not mean we blame ourselves. It means we continue to improve our offerings so our clients have fewer challenges.

This would have us look at the points above as follows:

1. It’s difficult to master now but let’s make it easier by learning more. When people are having trouble figure out how to make things easier. Most teams new to Agile (particularly those adopting Scrum) run into the same challenges. The attitude of keeping Scrum simple at the expense of it being difficult has proven to be sub-optimal.
2. While we can’t achieve full predictability, we can certainly achieve more predictability than we can now. Many people are convinced that because we're in a complex adaptive system we're at the mercy of complexity. But there are other approaches to solving complex problems. I borrow Dr. Goldratt's theory of inherent simplicity to provide another way - Dealing with Complexity by Creating a Bias For Simplicity
3. Let’s deliver what has the most value quickly. We don't need to settle for less than what we need. Instead of driving value from a single product owner or team, we must determine our direction from the business vision. This requires a business value driven approach. Unfortunately, methods that were created for the team are still in use.
4. If people have trouble with something, instead of putting the cause on them, let us make things more understandable. This is a variant of the first attitude shift.

Never settling for how things are, whether they be good or bad, would be a welcome attitude. We must not accept limitations on us because doing so locks them in - and many of them are not really limitations. As Henry Ford once said - "whether you think you can or think you can't you are correct."

We have to get back to the opening line of the Agile Manifesto – “We are uncovering better ways.”

A Postscript

Besides the comment here about possibly trivializing building software and another post outside of this thread entirely, I realized that people are inferring two things I didn't mean them to. First of all, I wasn't trying to say software is easy. I'm actually not even talking about the software aspect of these things. All of these attitudes come from process folks (mostly Scrum and Cynefin to be specific).

I'm saying the attitudes I've listed at the start of this article do not help us. The fact that building software is hard doesn't excuse us for the horrible job that is done most of the time - especially in the area of the user experience. The second, my point is about the attitude we take. In my mind it's not ok to be complacent based on the justifications I've listed at the front. People adopting Scrum, for example, have had the same problems for 20 years. It used to not called "difficult to master.'