- 15 February, 2021
- Article - Software Best Practices
When it comes to agile technology and development processes, we’re well passed the stages of if, why or even when. All IT departments are at some stage of this journey, as industry is moving away from a traditional linear product development lifecycle.
Projects have a clearly delineated start and end, products do not. It follows that there should be value in arranging our processes to follow this same paradigm instead of working against it. We need to arrange our people into teams that can continuously work on the highest priorities, with the latest feedback and most meaningful requirements. This is not only because of the well understood value of iteration in the form of responsiveness to change, and how it can exploit the malleable nature of technology. It is also because of the way it promotes accountability in an organisation, and can stimulate other less obvious areas like purpose, communication and growth.
Product-centric development is an operating model and a mindset, one which encourages fewer centres of gravity. It works well for larger technology projects, platforms and digital products which are intended to be long-running, even if they are at an innovation or experimentation stage. It is a way of thinking, budgeting and arranging teams without the yolk of verbose project plans, but still with the discipline and expectations necessary – in the form of backlogs and velocities. The catch: it is only possible with a capable team who can tolerate (or prefer) blurred lines in responsibilities, and can handle the accountability for delivery moving further down the chain.
1. Identify products
The first step is tidying up the product set. This requires identifying, grouping and structuring a product portfolio that makes sense for the business.
This usually forces consolidation and coherence in the portfolio, as it becomes clear which teams and systems don’t really belong anywhere and have become clutter. It creates focus on the products that really matter, whether they drive revenue, offer potential or mitigate risk.
2. Organise and fund cross-functional teams
Working this way requires much more flexibility and overlap in teams, as requirements morph between product, business, customer and technical domains much faster, and prioritisation cannot wait for the next steering committee meeting.
Teams need to represent more of a shared brain, where the collective skills within the team minimise waste and promote accountability for the success of product. Key dependencies need to be eliminated, whether on individuals in one-off roles, or on entire teams which can hold up processes. Each team becomes atomic and contributes forward momentum to the product because they can work independently.
Teams must have everything it takes to be outcome-oriented in a way that is fair. This means enough skill, capacity and support to function independently over the long term. Incidentally this also then fosters and leverages longer-term commitment to the team and product from each individual.
3. Establish clear success criteria, objectives and measurements
There should be a framework for the team to measure their own success, and self-diagnose shortcomings. The best success criteria are those which are clearly understood by all parties, quantifiable and unambiguous – and ideally visible!
4. Take leadership responsibility
Changing a way of work requires leadership with resolve and commitment, but also patience as people adjust, particularly those from traditional business, ops or customer-facing roles. For some organisations, especially larger ones which are earlier in their agile transformation journey, this could be a substantial and difficult change to the way-of-work. It is also proving to be the most effective way to compete in the digital economy, and is worth pursuing.
Ultimately, CIOs should be constantly refining how to deploy resources in the most effective way. Right now, to be more reactive to the market, and to harness more potential from IT, this means teams allocated to products and backlogs rather than isolated projects and plans.
