Snowing Code

Personal notes on software development

How did we go NoEstimates?

(Publish date: 29/11/2014)

This is an account of how the IT department at my work place has decided to drop our old process that relied on estimates and go the #NoEstimates way. This should serve as a testimonial reading of how we got to this position and what worked for us. I will try to update my blog from time to time to say how this new situation is working for us. In no way this should be read as an attempt to voice an authoritative opinion or anything of the kind- this is simply what works/worked for us and if you find any help in these words- tant mieux!
While I talk about how things were done at my work place, this post and the whole blog is a reflection of my opinions only and represent me alone.

Recently the company I work for has gone through a rather rough patch and reached a point where some decisions had to be taken in order to change significantly the way we are working. Rebuilding trust was capital in order to save the situation and needless to say, rebuilding trust is an extremely demanding process, one that takes a lot of time and patience if you wish to succeed and we're still trying to make it work. Above all, it means that if you stay, whatever your role is, you are committed to try the best you can to make it work. So rebuilding trust is not just some steps that are taken by the people at the top, or the developers or the product team or whoever it is- but a joint effort by everyone. And I cannot stress how important it is, for every company that wishes to succeed, to build trust as a joint effort.

And as far as I'm concerned, trust is one of the main pillars (if not the main pillar) of the lean approach / the Toyota way. It's been a year ago or so that I've started reading about the Toyota way and got exposed to lean thinking, theories and practices- and discovered that a lot of the tools and methods that agile brought were actually based on Toyota and the work of Deming. And this is where I learned about the idea of continuous and relentless improvement (Kaizen) and started questioning the processes that became the bread and butter of Agile and Scrum, trying to find out if there are no ways to get better at what we do and how we do it. I remember how estimating user stories used to put so much pressure on the teams I worked with and create such an unhealthy environment. But what could I have done as a developer, who is just one part of a team and an even smaller part of a department/company? Then I came across this great blog post by Nick Tune about estimates and broken confidence and it was as if reading about my situation at the time.

Ideas never grow in a void, and after I posted my own thoughts about estimates I got exposed to the #NoEstimates twitter hash and the works of Woody Zuill, Neil Killick or Vasco Duarte. Soon after I constantly made sure my opinion on estimates were known by my peers and colleagues and relentlessly tried to pitch the idea of loosing our dependency on estimates. As far as I can say, the key points that helped me to succeed were eventually the amazing work my team has been doing in our attempt to reach a process of more frequent deployments (to not use the name of continuous delivery/deployment in vain) and a conversation I had with Woody Zuill. In our conversation, Woody said a lot of things, but two points he made were capital:

  • Go to your users/customers and ask them if there's one thing you can do today to make their work better, what should it be? You'd be amazed how quickly you can build trust by simply delivering value added work on a daily basis and making sure people see the value piling up.
  • Make sure you slice your work / stories into the smallest pieces of work that would make sense to the stockholders of these stories.

By being able to release new work on a daily basis (at least) and following these two points Woody made, my department work flow has been growing steadily and making a difference. And after keeping at it for a few months, we eventually had a quick meeting, the developers, the head of product, our project manager and tried to come up with a better way of working. We decided that no specific teams should be allocated with a specific stream of work- all of us should be able to pick up any story that is on the board. WIP constraints should become a part and parcel of our process- we will start with a specific fixed number of stories we will try to deliver within a day- if that will be too much we will decrease the number, and if it'll be too little we will increase it, until we find our flow. This, you could say, is the parallel to what we the scrum world calls 'velocity' (or at least this is how I see this). Note the difference though: the former focuses on value added, the latter on proxy value (points, estimates, whatever you want to call it).
At that point, our manager said that the last question that is left is how should we estimate our stories. I jumped at the occasion and offered a point per story. Our head of product agreed, by arguing that outside the room we were in these points don't have any meaning anyway- no cares how many points we deliver, he said, as long as we continue to deliver value. And that was it. It was as natural as possible a decision to take.

The road is still long and we still have a lot of work to do if we wish to improve and get better at what we do. This is just a start as far as I'm concerned and getting here, I believe, was the easy part. Now we need to make sure we manage to stay in this position (to begin with) and the improve our situation going forward. I will have to get back to this blog and continue to share with my imaginary readers how did we do and how did these decisions affected our work, department and the company. This, I suppose, is my attempt to commit to this blog.

blog comments powered by Disqus