We were sitting at an incredible event yesterday, standing in the second row at a conference on startups’ dynamics, eagerly listening to success stories made of hard work, some misfortune and bad times, incredibly motivated teams and dreamers’s dreams. Startups are like that, they’re fueled by the founders’ energy and the hard work of gaunt teams.
These are team where people often wear multiple hats at once: technical members may get involved in marketing activities, business-type people may be asked to test some code, designers are required to do marketing research.
By listening to founders' stories, we’ve noticed a trend that was only barely imaginable up to a couple of years ago and is a consolidate feeling today. Startups are experiments and as such they need to be started, treated, led and monitored. Which leads to an interesting conclusion: when you run an experiment you're just collecting data and evidence from a number of assumption which is exactly what the Lean Startup method is about. Guess what: the lean approach wins over the more traditional business approach everyday!
“Lean” happens when a minimum working/viable product is launched with minimum investment or even not built at all and the business plan and model are tracked and revised in very short cycles. And short mean even as low as a week, even less. There are no rules other then ones established by the change frequency of the effective (so-called actionable) metrics and the team ability to implement and manage change. The approach is in contrast with typical startup school-book business practices assuming you need to invest time and sweat in writing a five-years business plan which, guess what, it’ll never work out as you expected. What’s the point of writing one then?
Get a couple metrics such as the free-paid conversion factor, customer lifetime or plain and simple the amount of money you can cash-in each month and just stick to those. Even better, change them too but stick to effective ones.
Actionable metrics stand in contrast with so-called vanity metrics, and as you pay attention you’ll notice there’s plenty of the latter flying around. Number of visitors, who cares? You need paying customers, forget visitors! Nationality… who gives a d***! Payments take place in your own currency. Platform or operating system of the visiting browser. Forget that, you need to support them all anyway.
The idea of running a startup like a constant experiment is well described in Eric Ries “The Lean Startup” book and if you want to run your team and your software using contemporary standards you should read it even if you’re not involved in the business side of things, it is becoming part of the Lean and Agile culture, the theory / method / approach is well described in the book and it is so sensible that it has in fact been adopted by most contemporary startup initiatives.
Here at Venticento we feel there’s an amazing potential for importing lean practices into project management. Monitoring the efficiency of the software or product development process has always been a “desirable outcome” of project management, yet rarely achieved. Measuring the throughput of software development team is not an easy task because it involves people and people are not cogs: a living and breathing human being is the amazing connection between the cold and sharp logic of code and the fuzziness of complex requirements. As such, the software developer stands in the middle of a constant mess and tries to makes sense of foggy business requirements and harmonize them in terms of data structures, algorithms and architecture.
Agile proves useful when this constant mess is reduced and governed by adopting a common language for developers and non-developers to share the path, to talk about requirements and specifications and to review progress in short cycles, empowering communications and feedback.
Given the messy process, the unstable scaffolding of a set of interdependent requirements, the constant moving targets and short deadlines, how can you then measure the efficiency of a software developer? On which basis? The line of codes he/she writes? The number of bugs? The ability to cope with stress? Bullocks, these are all vanity metrics. We feel there is just one way to do it and it is surprisingly close to the Lean approach: using actionable metrics and these are called story points, issues rates and velocity.
Story points measure the complexity of a story, aka how difficult it is to implement it. It’s just a ranking system nothing more: take three stories, assign one point to the simplest and ten points to the hardest, all others fall in between. That’s it. Any developer can guess story points in a minute. Herogami makes it amazingly simple to review stories given the ability to group stories using attributes such as context, components, environments, different views and plenty of filters. Enter the Planner View and you’ll also get a at-a-glance perspective of all the tasks associated with them, isn’t is a great way to express their complexity?
Issue rates. I write code, my pal sitting close to me too. But guess what, when he does he writes more bugs than me. We know it because we track issues and run post-release analysis. Actually my friend has an average of 2 issues per story in the last three milestones. If you track it, you know it. Herogami does.
Velocity. This is hard and in fact nobody measures it. It falls very close to the border line of vanity metrics, in fact. Basically is the number or stories a developer or a team completes in a given time frame or sprint. It can be measured too also taking into account the number of issues an story points. Measuring velocity requires a lot of post-release analysis but it can be done and in fact we are actively working on Herogami to provide an automated report for it.
We add another metric to our set. This is not in the books, it is called Awareness and it measures the ability of predicting the effort required for a given task. Activities in Herogami such as tasks, requirements and issues have attributes that record and track the effort associated with them. In particular, two fields which are super simple to use: the expected effort and the actual effort. The former is entered at the start of each sprint, the latter when the activity is completed. By periodically extracting a report listing any gap between expected and actual effort we’re able to measure the team members' Awareness and add some contingency percentage accordingly.
Story points, issue rates, velocity and awareness: effective, actionable metrics for Lean and Agile software development teams. Available today at Herogami.com.