Transforming From Projects to Products
There is an old saying – An Agile Transformation is easy, you only have to change two things: Everything you say, and everything you do.
But actually, as obvious as that joke was, it is also wrong. You only need to change one thing, you need to change the way you think.
It is my premise that when we talk about Agile Transformation what we mean is transforming our thinking from considering our deliveries in terms of ‘Projects’ to thinking in terms of ‘Products’. And transforming from measuring people in terms of their effort, to measuring them in terms of their collective contribution to a shared goal (the value they add).
Project: an individual or collaborative enterprise that is carefully planned and designed to achieve a particular aim.
Product: an article that is created or refined to satisfy a need.
As we have all discovered, software product development is complex, both in the development itself where we face a host of unpredictable variables, complications and unknowns. But, more significantly, it is very difficult to know what you want until you see it and consequently there are an abundance of quality software products that do not effectively fulfil the need that triggered their commission.
We have learned that reviewing progress regularly with stakeholders and modifying based on that feedback is far more likely to result in a successful product.
In most cases it is a fallacy to believe that for a complex and bespoke software solution you can know your end state before you begin, regardless of how well you analyse. And no matter how good at planning you are if you don’t know the end state your plan is flawed, and as you cannot predict the unknown even the best plans are unreliable.
We have come to realise that bespoke software delivery is far more akin to product design and development than it is to project delivery.
Peter Drucker is an inspiration here, traditionally we put so much effort into getting things right, to be more efficient, or to do this, by that deadline, that we forgot to ask if what we are doing is bringing value. We put all our emphasis on measuring and monitoring effort, or efficiency, rather than assessing if we are achieving our goal.
If you are considering an Agile Transformation it is likely that you have discovered that efforts to ‘manage’ projects are leading to the wrong results and the focus needs to move from a focus on effort to a focus on value. To set a direction and ‘lead’ the way in product development. Try to stop measuring output and to start measuring outcomes.
But this is a major cultural change for many companies and not an easy one. It is a complete shift in perspective, moving from planning the delivery of a project to collaborating on the creation of a product.
For project management to be effective the end state needs to be [largely] known, and for the steps to get there to be familiar and [largely] predictable. With a known end state and predictable building steps, a Project Manager can effectively work towards that aim.
But bespoke software is far more complex and is generally dealing with many unpredictable variables, the biggest variable being the end state. In the majority of cases the end state is not known at the outset and emerges in the course of the product being developed. The true end state needed to fulfil a need or want can very often be significantly larger or smaller than initially anticipated. The ability and flexibility to pivot based on emerging information is crucial for delivering value and the product being a success.
Project Managers, often find the transition to an Agile mindset the hardest as it is their role that is arguably impacted the most and ultimately needed the least. So many of the traditional measurements are turned on their head when dealing with software. Once you can let go of the assumption that bespoke software is predictable and repeatable.
