You are months into a project, knee deep in user stories, bugs and of course technical debt.
Where did it all go wrong?
It doesn’t matter right now, leave that for the project post-mortem. The real problem is how to take the project that is in flux to completion. That’s where Metrics Driven Development (MDD) comes in. This is a framework that will not so much hold your hand to the end of the project but drag you faster to those far off goals.
What you talking ’bout?
Metrics Driven Development. Let’s say you are moving data from one Database to another, breaking a monolith application into an array of services or you are creating a new project and trying to convert customers through the funnel. This is where MDD will help you succeed. It focuses the developers, the project managers and the entire business to recognise what success looks like. That’s really important.
Metrics Driven Development helps identify what success looks like.
So half way through a project, it’s useful to say “okay, where are we now?” and to look at the state of play. What factors demonstrate that the project/feature are complete? What metric(s) says to everyone “we are code complete?”
The engineering team then write this on their white board or the wall and never forget the goal.
- Everyday at stand up, you pick up the ticket and say “how does that get us closer to our target?”
- Every time a ticket is moved into “Done” you should see that graph move closer to the end result.
If it is not helping you progress, chances are you are working on the wrong things. This is a culture shift for sure. Although, if the task does not feed directly into moving that graph, it needs to either be a technical task that will help the team deliver faster, or fixing a defect. This should change the stand-up conversation entirely. “What are we doing to get closer to our goal?” This allows engineers to be more accountable for the success of the project as they are pushing for the wider picture than just individual coding tasks.
A more recent example of MDD in use would be the project my development team are finishing up; migration of traffic from a monolith application to a new micro-service. The goal is to have 100% traffic going through this new API rather than the old one. We only work on tasks that move that percentage closer to our goal. We have this percentage and the graph on big TVs, and every release we do we are looking at how our changes impact these metrics.
Where on Earth….
This all came from several years of failing to deliver quick enough. This helped finally putting the finger on it as to why myself and companies I have worked for have been failing for so long.
In the past I worked on a financial reporting application that was moving from an old system to a new one, 10 months in and we still had no visibility of where we were. That is until we built a dashboard comparing the old system to the new one, and we were getting realtime data everyday. That changed the stand up conversations to what everyone is working on to “How do we get closer to 100%?” And that fed into our tickets and planning too.
Sean Covey has coined “4 Disciplines of Execution” that focuses on talking about Lead Measures and Lag Measures which we used later in that same company. And Christina Wodtke has written a book “Radical Focus” based on Objectives and Key Results (OKRs) and this really is to allow you to focus on the Key Results that will allow you to achieve your goal. Take ideas from both these methodologies you come to what I call Metrics Driven Development:
- Goal. Write down what Goal of your project or feature is.
- Visualise. What does success look like on a graph?
- Work. Only pick up tasks or plan tasks that are going to move you closer to that goal.
- Commit. At the start of the week commit to what % or # you want to achieve for and plan for it.
If you stick to this plan you will deliver faster, which will increase the likely hood of success and prevent the team from ended up in no mans land.