So What?

So what? Why do the things I've been babbling on about for the last 6 days matter?

Why does it matter that there's a tendency for the development team and the people who are paying the development team to agree a way of working that is neither productive nor valuable.?

Why or how could it help the success of a project to know that starting to realise a project is essentially antangonises the idea for the project and undermines and attacks the people who had the idea for the project?

Why does it matter that the idea of value streams isn't a very useful one for software development?

Well, none of it matters unless it changes how you see the world, and changes what you do in response to what you see. And of course, none of this matters unless the way that this changes the way you see the world results in these things.

An increase in the chances that the projects you're working on will be a success
A more positive emotional experience for you and your team
A more positive emotional experience for your customers and their users

Yes, emotions.

Why am I talking about emotions? Well for a couple of reasons.

Being responsible for a project can make you feel terrible. I don't know if this is exactly the right time to admit this (when would be a good time), but I've been thrown off a couple of projects. Once in a quite genteel fashion. Once, quite abruptly and overnight. I strongly suspect that there've been attempts to throw me off a couple other projects. And I ejected myself from one company after a couple of run-ins with it's go-getting, CEO.

But also, let's say, being responsible for a project can make you feel great. When you're involved in a project that has to deliver for a deadline and all the wailing and gnashing of teeth over scope and what will and won't be delivered is gone and the team is working well, that's a great feeling. When you deliver something that has cost millions, but will deliver millions and millions more, or will save millions. That's a good feeling.

So that's one reason I'm talking about emotions.

But another reason I'm talking about emotions is that not many other people seem to talk about them. The way that Agile methods, and now Scaled Agile methods are sold is as a set of practices (actually a set of qualifications) that, if learned carefully (and paid for obviously) will somehow guarantee success.

Some people, at least, are honest about conflict. Gene Kim et al. in "The Devops Handbook" talk about the core chronic conflict between the developers who want to write as much new functionality as possible and the operations team who want to keep a platform stable.

Even more honestly, at the end of their book, they admit that the innovative ideas for ways of working that they talk about in the book have got them kicked out of some companys who weren't quite ready for so much innovation.

And really what I'm saying when I say that the work of implementing an idea is naturally antagonistic to the idea. It's that there's another chronic, core, conflict right there. And by saying that this is a chronic, core, conflict, I'm also saying that perfectly learning and perfectly applying a methodology won't guarantee project success.

Once you know, once you understand this, you will be very suspicious of any methodology or any advocates of a methodology that isn't honest about the conflict.

Agile project management methods don't just need to take into account conflict resolution - this is the point about warning agains "agreed activity" agile project management methods also need to acknowledge conflict generation.

But this is the importance the third point that I talked about yesterday. Value irrigation. The way to resolve the conflict between the shiny project idea that got funded and reality with all of its financial, logical and temporal constraints, is to deliver something of value. And the way to do that is to explore the value landscape. What is valuable to the client? What is valuable to the client organisation? What is valuable to the users? And wherever possible, as soon as possible, connect these things via some working software.

Understanding more about your clients and the client organisation will give you at least a chance of working on the things that are most valuable to them, even if any direct attempt at asking for prioritisation result in the old classic "We need it all, there's no way we can prioritise."

Understanding more about your users might allow you to stumble on the absolute gold of "pull." You might find something that the users really want and that you could give them.

Once you have pull from real users, you are in a completely different ball game.

So, so what? These are three things that I talked about yesterday?

Implmenting a project inherently creates conflict with the idea of a project
Avoid that conflict (with agreed activity) is an answer, but it's a disastrous one
The only positive approach is to explore the values of the client and the users and start to deliver solutions that are valuable to both.

What I've found amazing, when I've seen this happen, is that exploring the values of the client and the client organisation, and exploring the values of the users, isn't so much conflict resolution. It's more conflict dissolution. The conflict between the idea and the reality would still be there, should anybody be bothered to inspect it. If you were foolish enough to mention this to the customer, you might get a some gruff recounting of the original dream of the project and how someday, they's still like to see that.

But proving the clients and customers with something that they want, especially if it leaves the customers calling for more, is mostly enough to let the dream fade into the background.