In an ever-changing industry, it’s important to constantly keep re-evaluating your own methods and processes. Do they still serve the needs of today? Are you trying to solve yesterday’s problem? Are you setting yourself up to tackle tomorrow’s biggest issue head first, or are you digging yourself deeper and deeper into a pool of quietly suffocating quicksand?

I feel that asking the above questions has helped me a lot to continuously improve the way I work, so I decided it might be worth it to document some of the insights they bring. One of those insights I had recently concerned estimations in a rapidly moving product environment. Are they actually delivering value, and are they worth the effort?

Red flag alert: developers probably dislike doing estimations

A huge amount of software development these days follows the Scrum or Kanban paradigms (or any of their varieties). In their classic forms, they often come with a prioritised and estimated backlog of user stories that a team should pick up in order to ensure a steady delivery of value. Estimating user stories (or backlog items, however you want to call them) takes a lot of time for a team and most people dislike doing it. Something that makes people in a team unhappy immediately raises a red flag for me, begging for re-evaluation and further inspection.

Proper estimations are hard

I don’t think I still need to convince anyone that estimations are really hard, if not impossible, to get right. When something is really hard to get right and is considered generally unfun, there must be a lot of business value in it to force it onto people.

Well, not really. Since your estimates are shaky at best, every decision you make based on them will add just another layer of assumptions. Your perceived predictability then comes with a nice false sense of security that can cost your business a lot of money down the line.

What we really want is more accurate predictability

That makes the actual question really simple: How do we improve predictability if getting better at estimates is not the answer?

Scope down

When I say “scope down”, I don’t mean “be less ambitious”. What I really mean is that you should deliver smaller chunks. It’s something the Agile community already does to get more accurate estimations. Scope down enough and your estimations become pointless compared to just shipping things.

A good technique here could be to change the questions you ask a team. They say restrictions breed creativity, so what if you ask a team, “what would it take to ship a solution tomorrow” instead of letting them estimate your chosen solutions. Questions like these make you more agile and invite everyone involved to think outside the box. This is often when breakthroughs happen.

Small, stable, autonomous teams

Small teams generally communicate (and thus collaborate) better due to a massive reduction of possible lines of communication. To give you an idea, a team of three people has exactly three unique lines of communication. This becomes a whopping twenty-one unique lines in a team of seven people. Twenty-one lines ready for miscommunication. Twenty-one lines where things can (and will) get lost. Think about this before adding people to a team.

Keeping your small teams stable improves their collaboration and trust. A stable team of good people quickly becomes a well-oiled machine that can easily be disrupted by adding or removing people.

Give the teams the autonomy to solve a problem instead of trying to micromanage their every move. People that solve problems together feel accomplished and happy, they perform faster and will be capable of coming up with solutions you haven’t even thought of. If you don’t trust your engineers to solve a problem autonomously, why did you even hire them in the first place?

Ship things, earn trust

This is probably the most important thing to do. Instead of providing your business with a bunch of estimations, work with them to pinpoint the biggest issue. Solve that issue and ship it. Ask them the next problem on their list and start working on it. It might take some faith from your business the first couple of times, but once they see you shipping actual solutions they’ll be too busy figuring out which problems they want to have solved first to actually ask you for estimations.

Being agile means experimentation. Are you ready?

If you deem yourself agile and take pride in constantly re-evaluating your workflows in order to optimize, I invite you to give this a try. After all, agile is all about small controlled experiments and this seems like something very safe to do for a couple of weeks. Worst case scenario, you’ll ship a couple of valuable solutions or you just learned that the solution you chose is not solving the entire problem and you need to iterate on it. Isn’t that what being agile is all about?

How can madewithlove help with this?

At madewithlove we constantly strive to optimize processes by performing small, controlled experiments. Every team and every project is different; there are no silver bullets. We believe we can help your team deliver, increase predictability and keep you focused on building a better product. Check out our product management service page to find out more about this.

Also read: Why You Don't Need Estimates