You get what you measure!
Processes
A good process helps you produce good quality products and deliver them to your customer on time. A great process also highlights opportunities for continuous improvement and allows for some spare capacity to implement the necessary improvements.
Scrum and Kanban have become the two most popular choices for agile teams. Scrum is based on empiricism and uses transparency, inspection and adaptation as the pillars of continuous improvement. Kanban has its root in Lean manufacturing and uses the principles of flow to drive continuous improvement.
Continuous improvement
To make continuous improvement possible, it is essential that you choose to measure the right things. In the world of software development, Agile and Lean are being used as buzzwords and it is not uncommon to come across organisations where Lean and Agile techniques are being employed without a sound understanding of the underlying principles.
Organisations do not always optimise for value creation and flow. Instead, the desire to optimise often translates into local optimisation applied to silos within the organisation.
Mastering iterative development can be hard enough for development teams. But even when development teams manage to successfully apply the build-measure-learn cycle to their work, they might be doing this in the context of a business that does not yet iterate.
While a great process is necessary, it’s always a means to an end, never the end itself. The end, and the purpose, is value creation: if you don’t create value for your customer, there is no need for your product. The same can be said for product features: customers don’t buy features, they buy solutions to problems. Most products out there are loaded with unused features which cost money to maintain.
Do we need more features?
Often, we don’t remove obsolete features simply because the organisation behind the product has set up a development team and allocated a Product Owner specifically to these features. Somehow the concept of a feature team has been interpreted as a team that is allocated to a feature rather than it being a multi-disciplinary team that is capable of developing any feature. Therefore removing the feature would make these feature teams feel that they are no longer needed.
Not only they are still needed (because of their expertise and experience), they should celebrate the removal of an old feature because it allows the organisation to free some capacity to experiment with new features and products!
If we accept that value is the primary desired outcome of product development, why is it so hard to find organisations that are measuring it?
When was the last time you worked with a Product Owner who really prioritised her backlog by business value?
One of the 12 agile principles is Customer satisfaction by early and continuous delivery of valuable software. Yet, we are not measuring business value.
One possible explanation is that in sub-optimal implementations, agile principles and techniques are seen as something that is confined to development teams. And Product Owners are being rewarded for delivering pre-defined scope on time.
Ironically, agile theory favours a fixed time, fixed quality and variable scope approach. There seems to be a natural tendency to impose the old mindset onto new frameworks: we are using Waterfall patterns — upfront design, fixed scope, late integration and testing — mixed with the ability to work in cross-functional teams and build things in sprints.
Why be agile?
Undeniably, part of the reason why agile development has gained traction in the last decade is its ability to provide predictability and mitigate risk. But the ultimate reason why we should want to be agile is that it helps maximise the chance that what we’re making is going to be used by our customer. In other words, we do agile so that we don’t end up making a product that no-one wants; we achieve this through hypothesis validation, Minimum Viable Product, quick iterations and sustainable development cycles.
The spreading of agile techniques and tools has somehow diverted everyone’s attention towards how to do product development faster. We now invest considerable amounts of money to write, test and deploy software faster. Delivering software frequently is a game-changer, the purpose for pursuing a faster feedback cycle is that it helps us achieve your business outcomes.
At the very least, we should be measuring business value and lead time. All other variables being equal, we want to deliver more value in less time. It’s a simple as that. When we optimise for flow we do it to deliver more customer value in less time. Every other metric, such as team’s velocity, cycle time, defect rates, etc. is in fact an intermediate metric. In reality, however, these intermediate metrics become the obsession of managers who are being rewarded for fixing these numbers at team level, often without a real impact on overall value creation and lead time.
