Angels and demons and silver bullets
We (sometimes/often/all the bloody time) like to improve things in big batches. As in: everything that was done before is bad and should be replaced with this new thing. I find it ironic how widespread this is even in the agile community.
One of the recent trends is the move from projects to products, of course with the obligatory demonization of one and the idolization of the other. The way projects and products are managed is indeed different. Projects have a known or desired end date, products usually don’t. Projects focus on outputs, products on outcomes. Projects can be OK with temporary teams, products less so. And then we have agile …
I’m not fond of the concept of ‘agile project management’. I’ve seen this mostly muddling the waters, rather than helping with improvements. Using it seems to give permission to continue with the old, but using some new fancy words. I mean, how much can possibly improve if your portfolio management practices remain the same, program management remains MIA so no-one is accountable for outcomes, “sprints” are planned for three months ahead, and lessons learned from one project could have easily been copied from the previous ones as there’s no follow-up or improvement.
Adopting Agile and treating everything as a project are incompatible approaches. A portfolio usually contains a mix of products (where Agile can be used) and projects (where project management should be used).
Also: product management != scrum & project management != waterfall.
It tweeted the above, which sparked some conversations and lead to me writing down a list of actions an organization can take if there’s confusion between projects and products, waterfall and agile, outputs and outcomes.
- Figure out what’s what in your portfolio
Your organization’s or team’s portfolio of initiatives is mixed. For some of the initiatives you might be able to create rather accurate plans, and some others have many unknowns, making them unpredictable. Some of them have a deadline, and some of them will ‘done done’ when no-one is getting any value from the results anymore. Some of them could even be successfully run as waterfall (oh the horror!) while some others need lots of feedback from many iterations. That is — some of them might be potential projects, and some of them might be potential products. So, spend some time on analysing and agreeing on what is what. - Figure out expected outcomes for all initiatives
Every initiative in the portfolio needs to have clear outcomes, regardless of whether you decide to manage it as a project or as a product. The challenge is that with products, it’s very difficult to avoid answering the “but why” questions, whereas with projects, the easiest answer is to just list the expected outputs. This is only half the picture, though. The mandate for initiating a project is part of program management — and once again, program management is not the same as “managing large projects” — and the outcomes part of the “but why” needs to be understood and agreed there. - Choose the best methods to achieve the outcomes
Select a suitable project management method for your projects. You will probably have to deal with stage gates, approvals, and tolerances here. You might have to assemble a one-off team or give the project to an existing team. Select a suitable product management method for your products. Agile might work really well here. - Stop looking for a one-size-fits-all solution
Accept the fact that not all work can or should be managed in exactly the same way. It is OK to have both projects and products in your organization. No, you don’t need to get rid of all projects (and project managers). I’ve seen it being done more than once — never ends well. And, even different projects and different products are often managed differently. Project management has its principles, and so does product management. Following these principles and not getting stuck in procedures seems reasonable. This doesn’t mean that you should ignore the agreed procedures or processes, but if they seem to be getting in the way of achieving the outcomes, then you should raise that concern. Don’t go all cowboy, but don’t just “baa” either. Communication is very important. - Stop demonising methods and tools
Your realization that a certain initiative is better managed as a product rather than a project does not mean that project management is bad. The fact that PMBOK or PRINCE2 is not relevant for your initiative does not mean they are not relevant for some other initiatives. On the other hand, the fact that Scrum doesn’t seem to work that well for your other initiative doesn’t mean that Scrum is bad or that any kind of agile approach is fundamentally flawed. The tribal approach of “mine are angels, yours are demons” helps absolutely no-one, and especially not the people paying your salary, directly or indirectly. - Take some time to read and learn
If you do still wish to demonize an approach to managing work, then please do some research about the theory, the principles, and the practical application of the method (or framework) before you make claims about how evil it is. The same applies to anything you want to present as a silver bullet. You will soon realize that there are none. Keep an open mind when you learn more about an approach you dislike (with a passion). Instead of “this is wrong” or “this will never work here”, think about “under which conditions would this make sense” and “what obstacles could have contributed to those I’ve seen fail”. As a side note: people criticizing Taylor should really read his book, as in actually read not just hear rumours about, and people criticizing waterfall should really read Royce’s paper. - Always keep improving
We are constantly discovering (or re-discovering) better ways of working. Our previously chosen methods and previously designed processes and procedures can quickly become obstacles to value creation if we don’t continually improve the ways we get our work done. It is quite likely that the approach you’re promoting today will be heavily criticized 2–3 years down the line. Don’t become overzealous in promoting your favourite method. Use these as tools to get the work done, take good care of them, keep improving your toolset, and don’t be afraid to throw away the ones that can’t be used anymore.
Remember, it’s not the sharp knife that presents the greatest danger in the kitchen — it’s the blunt one.
