7 real values from software beyond estimates
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 start and where variation and uncertain is 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 poo 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 a 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 come 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 todo business and learn new mindsets, skills 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 change. That happens to the top of market look Blockbuster, Codak 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 bareilly learn how to learn and actually we was tought 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 luck and got great education even so we are not tought to underlearn, 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 an others innovations instead of traditional virtualization. This year(2019) I had the pleasure to goto 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 is only 2 kinds of measurement. A) By value. B) By ability to GUESS right. unfortunately too many companies only care about item B. In 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 endup 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 in 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 beyond a professional guesser(which nobody is - everybody suck doing guesstimates).
1. Sustainability / Safety / Quality
I really try to avoid the world "quality" as much as I can but I'm talking about quality. The reason I try to avoid the world quality is because 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 enought automation and they are swinging on technical debt which really kills they 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 piple 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 want 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 think 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 tought 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 see as value, companies need to start realizing there is extreme value in 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 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 learn 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 priorisation, is very likely you reduced waste, this means cost savings. Removing waste is value. Even if you did not deliver as much items as your business want. This is the fourth real value from software, reduce waste and this value has lots of importante not only economically but as a mindset so your team learn 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 sometime most of managers do not understand. Also one of the main reasons why estimators are never get it right. Variation could be cased on the size of the user story, complexity level, hidden dependencies(which appear on last minute), technology 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 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 need 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 point of view. IMHO the right solution is discovered, so you need to have structured discovery process like DTA(Dual Track Agile). Companies do Design Sprints and use some lean startup techniques but often they do that as as Single shot on the beginning of a project or product, however that need 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 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 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 deliver 10 items people, in a month(4 weeks) you will have 40 items, Let's say you define a MVP release and you allocate 80 items. All items have 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 done by doing RCA(Root Cause Analysis) for bugs and user stories which did not happen on normal basis(meaning anomalies or +8h work).
This is much better than asking the engineers to estimate items because they 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 todo a killer work on discovery), you still could have dependencies on other teams(you need todo a killer work on foundation track - TTA post). Also is possible that you introduce new technology which your teams does not master which will add variation and again affect your toughtput.
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 them 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.
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 feature 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 is that for new softwares is always easier to create MVPs however even for existing softwares(digital modernization) is 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 in provide better education for your business and customers on what value means but also fail in have small frequent releases to reduce tension and make progress more visible.
Cheers,
Diego Pacheco
