“Aut inveniam viam aut faciam” - “I shall find a way, or I shall make one.”
It’s six thirty in the morning in London. January 23rd, 2020. I’ve been doing this Agile project management thing just over ten years. For about seven or eight of those years I’ve been trying to write a book explaining how to do it. Specifically, I wanted to write a book that somehow captures what it actually feels like. What it’s actually like.
What is it like? Well, mainly, for me?
It’s emotional, and it’s non-sensical.
And I think the current idea for a title that I have for this book “Delivering the impossible” captures this pretty well. I’ve had other titles. “Late and Over Budget” was my working title for a long time, “Good enough project management” was another (I literally got laughed at in an interview when I put that on my CV). What you’re being asked to do as a delivery manager, project manager, Scrum Master, whatever you’re called, what the team that you’re working with is being asked to do, is most probably logically impossible. But still, you’re being asked to do it. But often (nearly always) there is an emotional side to it as well. What you’re being asked to do is “impossible” in the sense that it’s overwhelming.
Periodically throughout these ten years, under a variety of titles, I’ve tried to explain what the hell is going on when you get asked to manage a project and what you should do about it. The title “Delivering the Impossible” came about when I was thinking that the answer might be in the writings of a Chilean psychoanalyst and philosophyer, Inacio Matt-Blanco and his notions of symmetrical and asymmetrical thinking. And no doubt about it, some of the truth is explained by that, but since I wrote that - way, way back in 2016 and 2017, I’ve had some other experiences.
Firstly, I’ve been part of a genuinely successful project. I’ve been involved in projects before that were a success in terms of the money then made or how please the users were, but I’d never before also been on a project which genuinely, in its own terms, delivered what was needed, when it was needed without any kind of delay or problem. Part of what was eye-opening about this from my point of view was how important to delivering on time was constant contact with clients and customers.
When I started writing about this “successful” project, I started to realise that what the continuous contact with clients and customers had done is make some of that standard “bad behaviours” of clients and customers, if not impossible, then certainly very difficult. For example, refusing to detail requirements, continuously changing their minds about what is important, insisting on a particular aspects of an interface even though they tested badly. What I started to think was that by doing this we were essentially, from the beginning of the project, crafting an alternative value stream, and I started to see developing a new piece of software as “value stream irrigation” - building a new value stream.
Then, behind this I had another revelation. Part of the problem with software development is not only that you’re trying to construct a value stream, but you’re trying to replace a value stream. A frequent, but extrememly difficult example of this, are software projects that are attempting to “replace like for like.” But another kind of displacement is also common. “Funding for idea”. In this, successful, project, both of these things were in play. This was the revelation. Managing software development is about managing a transition between “Funding, value, qudos for idea” to “funding, value, qudos for real thing.”
What really attracts me to this model of project managment is. Well. This:
It explains the weird, peculiar and downright bad ways in which people involved in projects behave without having to call them names.