7 real values from software beyond estimates

Estimates are lies, estimates are not reliable. It’s super common to have companies doing estimates completely wrong. There is no way to do estimates right, however, there are ways they can be even worse than usual like:

A) Having managers doing estimating for engineers.

B) Not accounting holidays, Refactorings and Bugs.

C) Not comparing working items

D) Ignoring variation: Different sizes, complexities, technologies, needs.

E) Not understand when the system is stable or not.

Very often estimates are done before the project or product starts and where variation and uncertain are sky-high. When we take a look into PMI, which is based on bridges and buildings we still see buildings and bridges with extreme delays, extreme over budget and poor quality. If this is true for construction engineering why the hell would not be true for software engineering where we barely have 50 years of experience as an industry compared with the +2K years in construction engineering. Project after project, year after year, company after company no matter how mature or immature or how sexy or old school the project/company is, this matter always comes to surface which great disagreement and often stress related to the discussions.

The Need for Mindset shifts

Time to time, companies who want to survive and reinvent themselves need to let some old culture, values and old ways of doing things go in order to achieve better results. In order to change companies need to break old paradigms and learn different ways to do business and learn new mindsets, skill sets, and toolsets. The past does not define the future. No matter how good and how top performer you were there is a point where everything changes. What happens to the top of the market look Blockbuster, Kodak and several other companies who were leaders and basically bankrupt. However you cannot do a different process, and use different tools, if you still think the same and your values are the same.

In order to Learn you need to Unlearn

When we were kids we “kind of learn” to learn things. Easily someone could point out that we barely learn how to learn and actually we were thought to “follow” and to be “complainant” but never to truly think critically and outside-of-the-box. Besides the fact education sucks, let’s say you were lucky and got a great education even so we are not thought to unlearn, to let it go and to re-invent our values and mindsets. I really like AWS philosophy of learning, they pretty much innovate based on the idea of “recreating” what never changed. They did it very successfully in AWS in several fronts like SOA/Microservices instead of traditional monolith solutions, Cloud-native databases like Aurora(where they decoupled storage from computing) instead of traditional monolith DB architecture, Firecracker and others innovations instead of traditional virtualization. This year(2019) I had the pleasure to go to Vegas on the very first re-invent and sow this philosophy in practice, for sure this is one of the reasons why AWS is so innovative and successful because they unlearn all the time.

Tell me how you measure me

There are only 2 kinds of measurement. A) By value. B) By the ability to guess right. Unfortunately, too many companies only care about item B. At the end of the day looks like the only thing that matters is if you delivery all items you guessed on time. Allan kelly wrote some amazing books about no-projects and continuous digital and project myopia. Where companies end up pursuing Dates, Features, Cost instead of benefit (value). Talking to management, business leaders, product leaders often they will say to you that they care about value, but at the end of the day, they don’t know what value means, they only know what cost, time and list of feature which is a very old school management 1.0 behavior which does not work well on the digital world we live.

What Value means? What real values can we get?

I you like to deconstruct value and pretty much say 7 samples or 7 real values we can get from software beyond a professional guesser (which nobody is — everybody sucks doing guesstimates).

1. Sustainability / Safety / Quality

I really try to avoid the word “quality” as much as I can but I’m talking about quality. The reason I try to avoid the world quality is that I dont think it best map the concept to the reality we need. Secondly, because people often think about quality with compromises. The first thing is sacrificed is tests, people often dont have enough automation and they are swinging on technical debt which really kills their productivity.

Having a Safe or Sustainable system means this is a pre-requirement and is non-negotiable, there is no way to work without safety, we need understand that when we: kill tests, deliver crap code, dont automate and pile up technical debt we are killing our productivity and creating bad experience for the final user and really throwing away all the business investing on the product.

Even if you dont deliver all the 100 items your business wants or you think you could do it you still are adding lots of value if you deliver 50 items with proper safety and sustainability. This is the first thing people need to realize, the first real value in software is sustainability.

2. Culture Transformation

Very often as a by-product, delivery projects or transformation projects often delivery new mindsets, new culture, new toolsets, new business capabilities for the company. Even if you are not delivering the 100 items you promised to the business and you taught you could do it, let say you delivered 40. There is still value if you help the customer to acquire new mindsets, therefore, transformed the customer.

There is a real value in learning: A) how to do proper software engineering. B) Proper software architecture. C) Proper software Design. D) Proper DevOps Engineering. E) Proper Agile Coaching. F) Proper team culture, feedbacks, psychological safety. The list goes on and on. This is often not seen as a value, companies need to start realizing there is extreme value to deliver a digital transformation to the customer. Even if you miss your deadline and could not guess properly the all output they want on the day they want.

3. UX / CX

Customer Obsession is another super game-changing value Amazon and AWS have. The only way to compete properly is by doing the right investment in UX (User Experiment) and CX (Customer Experience) otherwise your competitors may outperform you. Often UX/CX is not measured, as companies only care about your GUESStimate which you missed. Let’s say you need to deliver 100 items but only delivered 45. This item as having the right UX it’s a huge value that potentially could drive revenue for your company and grow your user base. UX/CX is the third real value from software delivery which again is bigger than being able to guess the right number of features on the scheduled.

4. Waste Reduction

Lean is all about learning how to see waste and reduce/remove waste. Kanban is a lean method therefore is all about waste reduction as well. Kanban is also all about changing your management behavior which could be a huge source of waste. Again let’s say did not deliver 100 items but delivered 35 but you did it properly which out doing feature yours users dont need and without Big Design Up to Front (BDUP) and piles of tech debt and proper prioritization, is very likely you reduced waste, this means cost savings. Removing waste is value. Even if you did not deliver as many items as your business want. This is the fourth real value from the software, reduce waste and this value has lots of importance not only economically but as a mindset, so your team learns how to self-improve and always tune the system, the process, and the solutions. There is value on it.

5. Stable System

Dr. Deming always talked about stable systems and variations. Unfortunately management still dont get this right. Several times variation is produced by the system itself and not by people, so it’s not people fault but is a system fault because the system is not stable.

Variation is sometimes most the managers do not understand. Also one of the main reasons why estimators are never got it right. The variation could be cased on the size of the user story, complexity level, hidden dependencies(which appear on last-minute), the technology in which the team is not productive yet. Having a stable system means we control the variation as much as possible and have mechanisms to deal with variation and reduce it as much as possible like doing: PoCs and/or Dual Track Agile Discovery Track and/or experiments. Having a stable system is a real value from the software because it means you understand what you’re doing and you can improve the solutions effectively and also the team throughput or maintain at least.

6. The Right Solution

It might sound obvious. However is common to have the “wrong” solution which means, features or software that people don’t want or dont want to use it. YC mantra is a successful startup that needs to build products that people love. Steve Jobs once said, “The life is too short to build products that people don’t use it”. Build the right product is complicated, it is not based on a single person’s point of view. IMHO the right solution is discovered, so you need to have a structured discovery process like DTA (Dual Track Agile). Companies do Design Sprints and use some lean startup techniques but often they do that as Single shot at the beginning of a project or product, however, that needs to happen continually and in full sync with Architects and Business Analysts.

Let’s say you need to deliver 100 items but you delivered only 60 by the time your business expected, IF of the 60 items you delivered they are the “right solution” there is lots of value on it.

7. Predictability

This is the last item I consider part of the value from software. This item is very “subtle” and could easily be confused with estimates. Predictability and Estimates are different things. Estimates are lies and they are not reliable however you still have a consistent “trend” and still do not ask your engineers to guess any work they will do. In order to archive it, which is not easy, you need to have a stable system, so variation is contained and managed (which often means break the stories at the same size — let’s say 8h stories). Kanban predictability work based on very simple math, like getting the weekly outcome of the team multiplied by the number of weeks. Let’s say your team delivers 10 items people, in a month (4 weeks) you will have 40 items. Let’s say you define an MVP release and you allocate 80 items. All items have the same size, therefore if you do 10 items per week in 8 weeks you can deliver it.

The good thing about having a “delivery goal” for the team is you can tune the system based on weekly progress. Basically thats did by doing RCA (Root Cause Analysis) for bugs and user stories which did not happen on a normal basis(meaning anomalies or +8h work).

This is much better than asking the engineers to estimate items because the items often have different sizes and different complexities. There are some gotchas here like, you still could have variation, meaning, unknown hidden dependencies(so you need to do a killer work on discovery), you still could have dependencies on other teams (you need to do a killer work on foundation track — TTA post). Also is possible that you introduce new technology that your teams do not master which will add variation and again affect your output.

How to deal with variation again? Basically you can create solutions that simply software engineering via an engineering organization or even a foundation track on TTA, Another option is to think about “generic” solutions like component and generic services where you could reduce good part of boilerplate or “common-code” and they let the engineer be more productivity.

You also could work on a: must, should, could targets. So let’s say you must deliver 30 items, should deliver 60 and could deliver 100. This way if you miss should is not the end of the world, also this technique forces the business todo better prioritization and reduce the blast radius of variation and might happen.

Another important practice is to show this Burn-Up chart every week to the business and negotiate if hidden dependencies appear, bugs arrive, people get sick, new stories appear. I’m not super in favor of changing dates but I prefer to use creativity and always reduce items on think in simple solutions.

What we can do better as technology professionals

First of all, we do a very poor job explaining to the business and customers what value means. By doing so, often people think value only means deliver the whole software on time on cost with all features they need (classical PMI success criteria for projects).

Small & Conninouts MVPs are also key for keeping the business engaged and always give visibility that the team is delivering value even if that value is not all the software or all super usable. My experience and understanding are that for new software is always easier to create MVPs however even for an existing software (digital modernization) are possible to create small MVPS but you need to know your game, be creative and sometimes trade features or process or more work on the user side.

As technology professionals, we not only fail to provide better education for your business and customers on what value means but also fail to have small frequent releases to reduce tension and make progress more visible.

Author: Diego Pacheco – Principal Software Architect at ilegra.

Source: Blog Diego Pacheco

Quer saber mais sobre o assunto? Clique aqui e faça uma análise completa sobre o cenário da arquitetura de software na atualidade!