The queasy conventions of writing about software development methodologies

Today I was going to write about commitment and consistency and the pain that it causes. But that can wait for another day.

When I'm thinking about commitment and consistency, two particular examples come to mind, from my career. Two painful examples. Two times when things did not go well. One of them that I'm fine with. One of them I'm still smarting about.

OK - I can't get away now with not talking about them, and I really don't want to talk about them. And the reason that I don't want to talk about them is the reason for this post.

The reason that I don't want to talk about them is that there is a convention that when we talk about software development methodology we talk about how, if you follow the methods that are prescribed, you will have success. So what are those conventions?

There is a method
I know what it is
I can explain to you what it is.
If you follow the method that I explain to you, your project is guaranteed to be a success.

And of course, along with this comes a fifth, hidden convention.

If you project isn't a success after reading my book, it's because you didn't follow the prescriptions in my book closely enough. Maybe you need to sign up for my online course or you need to hire me as a consultant.

And so of course, hidden, behind these are even more assumptions.

I've been really successful.
I attribute my success to my method.

OK. If I'm not saying that - what am I saying?

Beyond Agile as it's practiced, a wholesome combination of extreme programming and scrum, there isn't really any special method. But there is a way of seeing.
I'm starting to understand what that is.
Part of trying to understand what that is, is explaining it to other people
Part of that "way of seeing" is to understand that not all projects are going to succeed.
If you're project isn't a success after reading my book, it's probably not your fault.
I've been partially successful. Some projects I've worked on have gone really well, some haven't.
I attribute the success that I've had to working with very clever people, luck and a willingness to improve the ways we see projects.

That's what this book is selling. A "way of seeing."

Project management is about managing contradictions.
A central contradiction is that project management is about making an idea into a reality. But ideas can never be realities. They are completely different kinds of things.
This contradiction can't be completely dissolve, but it can be eased by delivering value.
We start to deliver value by understanding where the value is - for users, but also for the people and the organisation that are funding the project.
This is new territory, there is no value stream. There's a value swamp. Project management is about irrigating the value swamp.

Project managment is about irrigating the value swamp.

Well, that's a catchy slogan.