When is a project not a project? When it is a product. Chris Hesketh notes the growing shift towards product based development across our government clients, reflecting on the obvious, and not so obvious differences
Agile projects have firmly been in the ascendency in recent years. Where the requirements are uncertain and the end state open ended it’s proven to be a more effective delivery methodology.
Nowadays, largely thanks to its sheer prevalence, Agile is now pretty well understood. In many ways it has become the de facto go-to model and, more often than not, it is followed properly. But they are still projects, with a project’s strengths and weaknesses. A bit like salmon; projects are born, live wild lives, achieve their life’s purpose and then spawn the next generation.
However, not all IT systems live like salmon. Most need to evolve continuously, supporting different business outcomes overtime. That different lifecycle is what we are trying to match with product centric development.
Under the microscope
It is understandable that product centric development is not – yet – as well understood or as widely used as other methodologies.
It is easier to deliver with project teams in siloes, focused on achieving their own end-end outcome. But they are prone to duplicating common logical components, and once the project is done new requirements need a new project and they take time to set up.
Product centric development tries to do better, organising stable teams around the common logical components – products – which can serve multiple end-end threads and be around for the long-term and next requirement. An online payment system for a utility company would be simple example of a common component.
Once the product and its team have been identified and are in place, they can then pursue their vision or “roadmap” which, basically, is about the long term goal they are trying to achieve. Product features are then pursued in short increments in order to safeguard its ongoing value with wider stakeholders at the end of each increment then judging whether to keep investing or not.
From theory to reality
Fundamentally this is a trade. To reduce the cost of development (by only developing things once) and increased agility through continuity of resource we end up making the governance model harder. And this is because:
- Product owners have to continuously balance investment against different client demands. Usually there is more demand than delivery capacity so someone will be disappointed. And if the disappointed client has their own money and delivery team, then they can build their own version of the product and we are back to where we started.
- The organisation still needs its end-end outcomes. That means system integration, now product integration, and integrating different products with different roadmaps can be like herding cats.
So how can we make this work? Well, it comes down to that age old adage that if you put really good people on a problem then it is more than likely going to go well. Whatever working model you use, at the end of the day it still largely comes down to the quality, experience and ability of the people involved.
The best product owners are supported by the best technical leads and share a common language – one where the technical lead can speak business language and vice versa. Team coherence is therefore really important. Having different people from different organisations and different cultures doesn’t make building a high performing team impossible, but it does make it harder and it needs to be taken into account.
It can be done though. Take the Royal Navy’s NELSON programme. There, once you step through the front door you work for and represent the Navy, irrespective if you’re paid by a contractor or supplier. This “One-Nelson” ethos has been pivotal in its award-winning success so far – and there’s certainly much to learn from their approach.
So, what’s next?
In the 20-odd years I’ve been working in and around software development and technology I’ve learned that predictions are notoriously difficult to pull off. New advances materialise, some flourish and others fade away.
I will say, though, that organisations are always going to be looking for new ways to deliver value to their clients – be they private sector or government. There will always be plenty more Agile project fish in the sea, products are going to continue to emerge from the waves.
About the Author
Chris Hesketh is the CTO at BAE Systems Applied Intelligence for the Central Government Client group
Explore Government Insights
Stay up to date with the latest thinking, trends, technologies and projects from our Government teamFind out more
- A question of agility. Government IT is on the move. Chris Hesketh explores why agile by Design is finally taking root across public sector organisations
- Don’t go chasing waterfalls. Hannah Green says adaptability and mindset are all crucial when it comes to the ever-evolving field of software development
- It’s a numbers game. Engineers nowadays have to be even more multi-faceted than in previous generations. Andrew Stock explains why cost optimisation now ranks high among engineering disciplines
- Selling serverless. When it comes to going serverless, Stephen Rolph and Paul McAninly say that the abundant benefits outweigh any teething problems
- Fuelling the fight against fraud. Stuart Goodwin and Dil Begum consider the deep rooted issue of fraud in the UK and examine how better use of data may help the tide
- In control with Agile. Jenny Matthews explains how Agile working can give you the control you want, without having to compromise
- We need to talk about data engineering. Organisations across the public and private sectors are increasingly prioritising the role of data engineers – and rightly so, says Alex Richards