Job Opening: Principal Software Engineer - Mob (US, CAN, MX)
Hunter Industries Careers

#NoEstimates Questions Deep Dive

I have had a lot of great questions come in about my discussions on software estimation. I want to run through these and slowly add to them as more come in.

Chris Lucian answering Q&A about estimates, value streams, and their relationship to lean!

What are the “costs” of software estimates?

Wrote a WHOLE BLOG on this one :)

How do no estimates relate to zero bugs, and how does that synergy evolve over time?

To add some context, Zero Bugs is the idea that the team will use automated testing to reduce the bug count to zero. If there are any new bugs discovered in production they will get new automated tests around that bug to prove it is permanently fixed. This leads to a resilient fix. On the to the question:

Allow me to answer in Haiku:

Manager pressure 
No estimates enables
Zero bug creation

Seriously though, these two concepts are heavily intertwined. Every environment I have done #NoEstimates in has resulted in a lower bug count. Even though these projects were time sensitive. I believe the results were better and the rework was less. This gave us time to write more features.

Zero Bugs philosophy is enabled by #NoEstimates

Anecdotally, estimation promotes bad behaviors like fake pressure on the development team, and measurement on random values. Zero bugs means you are asking the developers to do things the right way the first time, not make it faster than is safe.

Zero Bugs creates an incentive for us to make fewer design trade-offs

If we promote the idea of quality as a way off life, refactoring and good design is also creates incentives.

Zero Bugs also creates safety around Stop the Line

Stop the line! Is that easy when an estimate is looming over you?

Developers can become afraid when an estimate turned deadline looms over head. This means that we create the same environment that american auto companies were facing when Toyota was asked to do training in the US. If it is unsafe to stop the line, the resulting environment promotes the propagation of bugs through the system, increasing rework and reducing productivity.

Zero Bugs helps prevent business pressure from derailing the team.

Even with #NoEstimates, business pressure can derail the team. The important thing is to, as a team, keep our collective cool. Zero bugs allows developers to execute on the original quality vision and feel empowered to stay the course if it makes sense to them.

In the long term the team can get more done because there is little skating around bugs

This all boils down the lean. If you look at your code production as a Value Stream Map, reducing the occurrences of the 7 deadly wastes will accelerate the development even though it might be counter intuitive.

Estimates lead to increased re-work due to unintentional time pressures. Quality practices are usually the first to go when you ask a team for a design trade-off. These situations almost always do not end well.

Can you explain the relationship between vertical slices and no estimates (this seems like a critical one to me)?

Have you ever had a retro on the value of estimates?

To provide context, vertical slices in software is simply the idea that each feature or task will be deploy-able to production each time it is pushed to source control. For those using scrum, imagine sprints that are 4 hours long not 2 weeks. This requires developers that know every level of the stack to make everything necessary. We use a combination of XP and Kanban to accomplish this.

Horizontal Slicing on the other hand is the idea that you complete large batches of work across entire segments of infrastructure. The idea here is you do work in specialist silos.

On to the the related answers:

#NoEstimates enables Vertical Slices

Taking into account any sort of batching process, sprints or waterfall, the process of creating a larger block of work will encourage horizontal slicing. It seems more efficient to assign 2 weeks of database work to the database people rather than having a cross functional team deploy a full solution to production.

Vertical Slices enable us to be lean

Vertical slices make the team more lean. Take into account the 7 deadly wastes. Some specifics are both the rework waste and the waiting waste. Individuals in a cross functional team will be required to wait less on dependencies especially relate to rework.

Better mitigation of the 80/20 rule

Both #NoEstimates and Vertical Slices encourage making a minimum viable product. Since there is no investment in features that do not yet exist, there is no sunk cost fallacy fallout to deal with. This means the team can change priorities feature by feature rather than sprint by sprint. 

Higher frequency Cost of Delay evaluation

At any point the team can change priorities, this means that a feature that seems less important once another feature is completed can be discarded rather than charging forward on the requested feature. You can also respond to customer issues more quickly increasing their satisfaction.

Faster discovery of UnKnown UnKnowns

Since your users can use your software faster, we can discover the unknown unknowns quickly. This saves time and effort in waiting cost in the future. This also prevents excess inventory waste by reducing the completed code you current do not have deployed to production. Therefore eliminating risk around that existing code.

Faster User Feedback

Get feedback from your users as quickly as possible. Are you vertical slicing?
Since you can deploy to users feature by feature, you now can receive feedback and change course more quickly. This means that items scheduled in a sprint can be de-prioritized if another feature solves a problem.

Horizontal Slices prevent us from getting these benefits

Try an identify when you are stuck in a situation because of horizontal slicing. Have you ever had to do feature cuts on a horizontal slice. Effectively throwing away database, ui, or server work because one of the tiers is not complete on time?

If the software developers are not creating estimates, who is creating estimates (Marketing, Product owners, others?) and how successful is that process?

#NoEstimates is more about creating an environment where waste is visible to everyone, not just the software developers. Then Business asks our Product Owners to make the estimates on delivery dates and they get a good idea based on the features getting released to production. After transitioning many projects now from estimates to no estimates, the result has been more deliveries at the right time without making un-necessary features. I would say today our Product Owners are bought into the idea, or at least accept it. Trust can be built quickly when your system continues to work with high quality and frequent deliveries. I don't believe it works as well if the quality is not there.

How do you explain the difference between an estimate and a deadline?

What is the difference between an estimate and a deadline? How does it effect your work?

Estimate: Roughly calculate or judge the value, number, quantity, or extent of.
“We think <Feature 1> will be done in May”
“We think <Feature Group 2> will be done in February”
Deadline: A date or time before which something must be done
“<Project 1> release will have to wait until next year if we don’t release in July” “Hardware for old product will be exhausted in July, We need to make more or finish the new product”

Who has been most resistant to no estimates – executives, product owners, software developers, some other group?

No group in particular has been resistant to the idea, just individuals. This relates directly to the distribution of innovation theory. At any organization a new idea will need to cross the chasm. It is valuable to understand that in any change initiative there will be people who are resistant. This is ok, they are not there just to be mean to you. The real way to make these things grow is find the early adopters, then make it successful until you can bring in the early majority. Showing successes over time will grow the buy-in to your process. If you are able, assemble a team with similar ideas on how to work and show how successful it can be, your successes will garner interest in your work.

One more note on this, make sure you treat your detractors well! This is extremely important. Since the distribution of innovation is a natural occurrence, you must understand the people resisting your grand idea are not bad people. In fact you should try your best to empathize with them and provide them as much transparency as you can. Engage with them and answer their criticism and skepticism with empirical evidence and anecdotal stories about successes. Find publications they trust and deliver them supporting material from those publications. Ask them for feedback on your change initiative presentations before delivering them. Incorporate some of the feedback. Make anyone and everyone feel included in your idea.

There is no better way to isolate yourself from the collaborators you need than to make them feel excluded.

To what extent is it an ongoing challenge to convince people that no estimates work?

Ultimately you will receive scrutiny until you see profit and customer satisfaction go up. Strategically speaking you want to get there as fast as possible. If you have limited power to do so, do what you can to become as lean as possible at the edges of your control in order to make it easier for others to buy-in and make the transition as well. Currently the products we work on are delivered to production and receiving continuous updates. Those that have visibility into this have more buy-in, those who are isolated from our progress continue to be skeptical. Our job is to help break down those barriers and foster transparency over time.

What are some of the most successful arguments you’ve used to convince other people to embrace no estimates?

I have many stories in this area that have resulted in increased buy in for our practices in the organization.

Find their favorite publication

Imagine you are an executive and someone has just said #NoEstimates to you? Sounds harsh right? As an executive you pay attention to publications like Forbes and Harvard Business Review, and they have never said anything about such an initiative that you have read so far. You and your company now stand to take on all of the risk related to this idea that your employee has. Now imagine that this person sends you a few articles from your favorite publications that relate to this topic. Would you be a little more bought in?

This is exactly how I have begun to approach conversations with people unfamiliar with things that I think are important. I find out what publications they read and then forward articles/audio/video related to my change initiative in the format they like the most from the publication they trust the most. One article that has gone a long way for me to bridge the gap was an article from HBR on Budgeting vs Estimating. This article is related just enough to get the conversation going with someone who possibly would have dismissed the idea outright.

Dig into their analogy

My last two bosses have both come from a background in Bridge building. I imagine having a background in bridge building will make you more likely to compare software development to bridge building, like the ubiquitous analogy of building a house. A great way to have a deep conversation about #NoEstimates is to find a common analogy you share and then elaborate on the software side of the analogy until it supports the core idea. Here is what I mean:

Initial Analogy: Why can we estimate building a bridge and not building software?

Response: The problems with the analogy are the laws of physics. When working on a bridge, it is extremely expensive to build a bridge and it is extremely costly to fail at the building of the bridge. Therefore we spend a lot of time on architecture. Then the bridge gets built based off of the blueprint. The reason we cannot do this well in software is the fact that the operating system, frameworks, and dependencies we rely on are constantly changing. This would be like trying to architect a bridge when the laws of physics change every Tuesday. Further more, it is cheap to build software and expensive to write the blueprint. This means that we should operate in the exact opposite way, capitalize on the fact that we can make failures inexpensive and learn from our failures as frequently as possible.

Key Point: If you contrast the analogy with reality you can "bridge" the gap in your understanding.

Vertical Slices Vs Horizontal

This one is fairly straight forward. The discussion of Vertical Slicing vs Horizontal Slicing makes sense because everyone in software has experienced the need to change direction or do feature cuts and the horizontal slicing creates a large amount of waste.

Historical Gantt Chart!

Gherkin 2 Gantt is a great way to help people get past the idea that you are not accountable when not making estimates!

This story is a good one. When I first became director of this department there was a lot of skepticism for the #NoEstimates concept. One strategy I stumbled on early on was to find out who was skeptical and then ask them for feedback on a presentation I was giving on our software practices. We inevitably got into a discussion about #NoEstimates. I then discovered the reason this person was uncomfortable was because they believed there was no accountability. I though about their feedback and created a timeline of everything that was completed. Once they saw the timeline this person said "Wow you actually got a lot done, now if I could see this in a Gantt chart I think it would communicate really well" Then I made a historic Gantt chart of our progress and they loved it. In fact every skeptic I interacted with loved it too. I eventually made the project Gherkin 2 Gantt which automatically took our passing Gherkin scenarios and plotted them in a Gantt Chart eliminating the need to make them by hand!

The Software Estimation Paradox

This one is another blog I wrote but the paradox has gone over very well with people that enjoy logic riddles. I also used it in a lightning talk at Agile 2018 which got a lot of laughs.

Speaking entirely in financial terms when discussing the cost of estimation

How do you explain to the business the cost of estimation?
Finally you will want to cover this one. It is important to know what language your finance counterparts use and elaborate on that. They went to school for this stuff and are the experts. In order to create acceptance of new ideas you must be able to articulate it in such a way that you become inclusive to the people managing the finances of the organisation. On the other side of this concept, if you are able to do these things it is much easier to break down barriers when you can use the language of a Finance graduate or MBA. I believe this is a fact of life in any business. 


Post a Comment