Value driven technical decisions in software development
Some years ago I delivered a talk at SwitchON in Stockholm.
At the conference I got to deliver my talk “Value Driven Technical Decisions in Software Development” for the first time in public.
In this article I outline the talk as well as provide (a lot) more detail and context to the 3 parts of the talk:
I. Technical reasons why software projects fail
II. The psychology of overengineering
III. Value driven decisions in software development
I. Technical reasons why software projects fail
Let’s start by investigating technical reasons why projects fail.
There are a couple of reasons why I narrow it down to “technical” decisions. First of all I think we as developers and architects have a tendency to attribute too much importance to our technical decisions. At the same time we downplay or ignore the risk we introduce with certain types of technical decisions. We are, in my view, not that great at taking into consideration:
Professor Søren Lauesen at the IT university of Copenhagen has written the report report “Damage and Damage causes in large government IT projects”.
The report investigates some big government IT projects in Denmark that has succeeded or (mostly) failed.
When reading the report, what immediately strikes you is that the phenomena and mistakes Søren Lauesen describes, are by no means exclusively something happening in large government IT projects. I have seen the mistakes repeatedly on projects ranging from 50.000 DKK to tens of millions.
I therefore think it is safe to say, that the findings from the report are more universal, than the title of the report indicates. I think a lot of big companies (banks, energy, retail) are happy that many of their projects are not subjected to this level of scrutiny/post-mortem. And that they do not have to divulge these kinds of reports to their shareholders.
In the report Søren Lauesen outlines what primary damages occur in software projects. What their causes are and what possible cures are available. Different projects encounter different damages and to different degrees. The primary damage types and examples of their impact on different projects are:
Time
The first damage is Time. I.e. the project taking longer than initially expected. This has several additional impacts. It is not only that we spend more time. It can be getting later to market, getting cost reduction or profit increase much later than projected. It can be certain business capabilities are not possible to realise because of a project being delayed. (I recommend reading The Unicorn Project about this). It can also result in not fulfilling certain obligations or compliance requirements.
Looking at the differences between Expected and Actual in the time graph, we see several years added to the projects before they were finished.
That is a lot of time for other damages to occur, a lot of time for the target landscape to move or, as we will see later, enough time for tax debt to grow too old…
Cost
The Cost damage can be related to multiple factors. It can be the additional development costs, but can also be the costs induced of being delayed (additional license fees, subscription, non-automation).
It can also be migration work or similar, that was assumed to be automatable, but turned out to require manual handling. There are many cost-increasing factors in a project. It is not merely caused by “wrong estimates”.
The Travel Card project, was aimed at introducing a common digital card solution for all 20+ public transport operators in Denmark.
Even though Travel Card was somewhat a success on the cost parameter, it actually cost the supplier 500 mio dkk in loss, because they had “overlooked” that they should also deliver a back office system.
The time delays also meant that the entire project was overtaken by the Smartphone revolution, which would have thoroughly changed the possible infrastructure for it. And basically meant that when it went live, it already felt outdated. If they had pivoted to a smartphone enabled solution, then the budget might not have been as close to the estimate, but it might have been a much better solution overall and a much better adoption by users of public transportation.
Business result
Damages can also be Business Results. For example ensuring some SLA towards the customer/citizen or basic ROI. It can also be the case, that the project simply did not produce the opportunities initially expected or maybe the reduction of staff or high training costs did not materialize.
The purpose of the Debt Collection project (EFI) was to automate tax-related debt from citizens in Denmark in a centralized fashion and make 300 bailif jobs obsolete.
Debt Collection had 450 different complicated kinds of taxes it should collect. I won’t go into the details of the many different factors resulting in this clusterf**k of a project, suffice it to say, what a f**king s**tshow. Not only was the project basically scrapped after 8 years (3 x the initial estimated timeline) and not only did it NOT produce the savings of 300 jobs (It merely turned them from highly skilled bailifs to highly skilled casehandlers). They also decided to realise their business case way before the system was actually ready, letting the 300 bailifs go before the system was live and working. This had as a result that somewhere between 30 to 70 billion dkk has been lost due to the tax debt getting to old. This was the result of trying to save something like 300 mio dkk per year. A saving that was nowhere near realised because of the conversion of 300 employees from one type to another type.
This is an extremely depressing example of bad risk management. And insisting on “100%” solutions, instead of automating the 80% manual work that contains 20% of the complexity.
I imagine someone saying something like: “Why only automate 80% when you can automate 100%?” — and not realising that the last 20% would increase complexity, cost, time etc. by factor of 10 or more.
Feasibility doubts
When projects begin to be delayed, increase in cost or the business results seem out of reach, we risk the Feasibility Doubt damage.
This damage is basically that the entire project’s feasibility and thus continued existence is questioned.
This is when the stakeholders are posing the questions like:
Are we throwing good money after bad? Are we victims of the sunk cost effect? Is the project or business goal salvageable?
PolSag (Police Case) contains a fun story (or maybe fun is not actually the correct word). The purpose of the project was to build a new casehandling system for the Police in Denmark.
The “funny” thing is that no one could define what the purpose or business case of the new system was. I.e. it was basically unknown why it was being built.
During the pilot testing the system suffered from incredible slow login times, which gave a very bad impression of the system. When technical people were finally given access to inspect the configuration and logs, they discovered that the login used a list of Active Directory servers where the first few did not exist. Thus a 30 second timeout a few times, before trying the one that existed. Always.. A great example of getting close to the end user and see what they mean by “bad performance”. When scrapping the project, it had also been realised that even though they did not expect a positive business case, it would cost 5 times as much in operations…
Usability
The final damage listed here, is Usability damage.
I.e. questions like:
The Land registry system had been defined partially by a subject matter expert, but most of the users were not experts in registering ownership of land and what else the system enabled. So the users basically gave up. For the more than half a year, it took several weeks to get through to the hotline, to get help to use the system.
This was for a system that should support user-start-to-user-finished in 10 days…
Technical decision damage causes
If you go through the list of 37 prominent damage causes in the excel overview, and exclude the causes not directly related to “Technical decisions”, you are basically left with two damage causes:
And these cures:
So quite simple. “Try it out” and “ask someone more knowledgeable than you”.
Another way of describing these causes is:
One is (over)engineering without due diligence,
To give a sense of these damage causes, here are couple of examples from the Land Registry project and one from the Debt Collection project.
Service Oriented Architecture
The Land Registry system had a very black-and-white SOA requirement and not only that, but also a very rigid interpretation of SOA. SOA had been identified as a risk, but was largely ignored, with the reason that “Tax uses SOA”. This was technically correct, but they were not using it in production/live. And they actually had a lot of challenges with it.
Søren Lauesen dives into the source of this rigid SOA requirement but as we can read in the report:
Thus SOA was an unnecessary source of a lot of time and cost damage. And possible also feasibility damage.
Uptime
There was an uptime requirement for Land Registry system.
The requirement was to have a 99.8% uptime. Where this specific number comes from is unknown, but a calculation performed by the supplier lets the customer know that a 99.5% uptime would cost approximately 5 mio. DKK a year in operations.
99.9 would cost approximately 15 mio.
So they are actually deciding to spend 10 mio dkk per year, to avoid 35 hours of downtime. I think this is way past the point of diminishing returns. Are they expecting that 35 hours will cost them 10 mio. DKK? Per year?
Data foundation
In the Debt Collection Project, we see untested assumptions about data quality or automatic handling of data creating a lot of different damages:
“The plan was that the system should save salaries of 300 bailiffs and speed up debt collection. The bailiffs were actually dismissed, saving around 150 M DKK per year. However, it turned out that most debts could not be collected automatically, either because data were wrong or missing, or because human judgment was needed (ref. 1, page 48). Automatic debt collection was soon stopped, becoming partly manual. Around 300 case managers were employed to do this, eliminating the gain of saving the 300 bailiffs.”
The fact that data was of poor quality and furthermore required more complicated manual/human judgment caused damage to business results, time, cost and feasibility. This would have been possible to spike or PoC early in the project. At least before sacking 300 bailiffs…
II. The psychology of overengineering
I see the main culprit related to “technical-decision”-induced damages to be overengineering. I.e. letting technology play a bigger or more critical part in the solution than the research merits. We buy in to the illusion that selecting the correct technology or architecture up front, will magically solve a lot of problems down the line, so we do not need to consider the problems up-front. We overlook the risks introduced by the technology or architecture and end up ignoring fundamental problems or risks because we see it as already mitigated by this early technical choice.
Of the 37 prominent damage causes, 2 are related to technology. That means that 95% of the damage causes are NOT directly inflicted by technology choices. (Although do note that the percentage does not represent the actual impact of technological choices, but instead how many in absolute terms are technology choices.) Typically, when technological choices have a big influence on the success of a project, it is most often a negative influence.
So why do we again and again fail to:
and
Or why do we not do it thoroughly and critically enough?
Why do we do overengineering and introduce risk and damages as a result?
In my view we have three primary components of “The overengineering triad”, that are the main culprits for introducing technical induced risk and damages.
Learning fallacies
One of the best examples of how we often learning the wrong lessons and act wrong accordingly is the story about the RAF bombing planes from world war 2.
During World War II, the statistician Abraham Wald took survivorship bias into his calculations when considering how to minimize bomber losses to enemy fire. Researchers from the Center for Naval Analyses had conducted a study of the damage done to aircraft that had returned from missions, and had recommended that armor be added to the areas that showed the most damage. Wald noted that the study only considered the aircraft that had survived their missions — the bombers that had been shot down were not present for the damage assessment. The holes in the returning aircraft, then, represented areas where a bomber could take damage and still return home safely. Wald proposed that the Navy reinforce areas where the returning aircraft were unscathed, since those were the areas that, if hit, would cause the plane to be lost.
In the software development profession, we seem to have some deeply rooted learning fallacies.
These are partly induced by cognitive biases and partly the industry hype machine.
Lottery fallacy
The first learning fallacy I see, is the lottery fallacy. We see the successful companies as doing some unique that made them win in the marketplace.
It is basically saying: “It is very unlikely for a person to win the lottery, so the person must have done something when picking the numbers, to increase his chance of winning”.
And then we try to investigate their number-picking process. And as developers, architects, etc. we look at their technological choices and setup. And remember even if this was a viable strategy (figuring out how to pick the lottery numbers. Hint: It is not) we are looking into something that represents a small percentage of the damage causes. I.e. the technology-choice induced damage causes.
We should realize that it is highly likely that someone (or very few) WILL win in the marketplace. And that can easily be DESPITE their technology stack, technology choices or their architecture. To be clear about this, the many factors contributing to “winning in the marketplace”, means that you can take incredible bad technological choices and still win.
This is not to say that technology choices do not have an impact. It is just to highlight that it is not an all-defining impact. And probably often has a lot less importance than it is attributed.
Recommended by LinkedIn
Survivership bias
When we talk of examples of survivorship bias from world war 1 and 2, it is quite easy for us to see what the logical fallacies. I.e. the soldiers being injured when wearing helmets, means that a lot more of them arrives at the hospital because they previously just died in the battlefield. (and thus did not get to the hospital).
How are we, in the software development profession, victims of this bias?
I think we are hit in two ways. One is that we look at the extremely successful companies, e.g. the FANGS (Facebook, Amazon, Netflix, Google, Spotify), and not the other 1000s mildly successful (or not-unsuccessful) software development organizations out there. For most of us, it would probably be better to learn from those organizations, instead of the FANGS, as those organizations represent our most likely non-failing trajectory.
A second logical mistake we do, is to emulate how the FANGS handled the growth pains, not how their success was created.
This is a very important point, because you actually want to suffer from growth pains. There is a saying something like “I envy you your problems”, and that is very applicable here.
We want to suffer from growth pains and we want to be able to handle it. But it is not the handling of growth pains that make you grow. There is quite a lot of cargo culting involved here. We emulate how to unload the planes arriving. But we do not understand how to make them come.
Another way to say it, is that we are often spending time reenforcing the areas on the plane with bullet holes. Not the places that are actually critical for success.
We do this in a number of ways. We copy the technology stack and architectures that enable extreme scalability. We spend time planning and mitigating for the growth we expect to come and get ready for it. And that is turning the problem on its head.
The time we spend overengineering, learning the bleeding edge technology, gold plating the architecture, and doing all the best practices, could have been spent delivering fast and learning.
It is a case of opportunity cost. The time we spend planning and building for “the great pay day”, is time we could use trying to make it happen instead.
We don’t even emulate what we would have like to happen. We emulate handling growth pains, not inducing them.
Hype and effect
The hype curve is a well-known phenomenon in tech.
We are usually subjected to an artillery barrage of the wonders of a technology, architecture or paradigm (TAP) at the peak of inflated expectations, well before we understand what it is not useful for, and way before for we understand what it is actually useful for.
E.g. who would have guessed recommendation algorithms were great at creating political extremists and propagating anti-scientific beliefs?
So usually when we are primed to introduce a new TAP, we are usually very unqualified to do so. We are basically pushed to introduce the new TAP when we are at the peak of unknown unknowns. I.e. at the peak of riskiness of introducing the TAP.
We will see a graph a bit later, which is very similar to this.
So, one aspect is that we get the new TAP introduced when it is very risky doing so, but at the time when we achieve Plateau of Productivity, the new TAP is suddenly not that anymore. Its just-the-tap. And thus probably overshadowed by the new ShinyTAP.
So, to summarize. We are nudged most to introduce technology, architectures and paradigms in our projects when they are very risky because of unknown unknowns. At the same time, we are nudged opposite for stable “boring” tech and patterns, because we fear getting left behind or missing out on the “next big thing”. We do this as an industry wide lemming effect, where people are brainwashed to feel that they are becoming obsolete if they do not jump on the new bandwagon.
Fortunately it is possible to find counter points to this behavior. Many seem to be recovering overengineerers (http://boringtechnology.club/ or https://thenewstack.io/reddit-cto-sxsw-stick-boring-tech-building-start/ )
Value substitutes
Most developers (and humans in general) want to do something meaningful, and a way of doing that, is to create some sort of value.
Value is a very abstract term, but a basic definition is that the time we have spent doing something, was better spent doing that, instead of doing something else or nothing at all.
It is, however, often very difficult identifying exactly what value we are providing. This is the case when the developers, teams, etc. are too far removed from the end user or customer.
If this happen, the need these people have for creating value, does not disappear. It risks getting fulfilled by a value substitute. Some concrete thing, they can put in as a proxy for the value they actually are providing.
Most often these value substitutes have nothing to do with actual end-user or customer value. We intuitively know this, but counter this with concerns like: “it will pay off in the long term” or similar. But if you are already too far from the recipient of the actual value you create, how can you evaluate that it “will pay of in the long term”? And furthermore, evaluate that it is desirable to prioritize long term benefits over short term gains? Even more to the point, that the value of the long term gain is greater than the short term value creation? (and the interest with dividend created).
Silver bullets
Very early in software projects, we decide what technological silver bullets are going to help us bring value to the customer. Often we exaggerate the importance of bringing in a new TAP and follow current “best practices” (or loudest hype) for the system challenges we are facing.
At this point in the project, however, we are often not very knowledgeable about the actual end use of the system, and by introducing new “things too master” (not just get acquainted with or learn) in the beginning of the project, the primary side effect is a greater risk of unknown unknowns in a phase of the project where we already have much uncertainty and a ton of unknown unknowns.
But hey, at least the customer will be happy they got the newest NoSql storage technology, Eventsourcing architecture or nano-services? Right? Riiiight…?
All-of-the-above
We are constantly being bombarded with ways of “futureproofing” our applications and systems. We are subjected to the wonders of architectural principles, frameworks and technologies, and even before we know what problem the customer or user need to have solved, we begin introducing a lot of overhead targeted at growth pains that may never come.
The mindset is something like:
“I may not actually know what the customer want, but if I build it with these two architectural principles, these frameworks and with this technology, then I have myself set up to with the ability to pivot the system towards the customer’s needs, when I finally do understand those. In any case, they get an awesome system.”
It may not solve the problem they need solved in a simple and cheap way, but it will be quite a sight…
Process perfections
If we are too far removed from the value we bring, we can also put “following the process” up as a proof that we deliver value. The mindset is something like: “We follow development process X to the letter, hence we must be providing value to the customer”.
This is not value. Actually, it can be quite the opposite where we cannot take in changing requirements or circumstances from the real world, because it is in conflict with our process or our plans. Then better to just continue following the process and plan, and disregard reality.
There are other ways in which we substitute actual value with some proxy for the value. We also sometimes proxy a solution by introducing something overly complicated and generic to compensate for not understanding what we are actually trying to solve.
Try to ensure the developers experience the actual value of what they spend their time on. It may not result in avoiding value substitutes entirely, but it will increase the likelihood that they are spotted and dealt with.
Overengineering bias
In software development, we have an inherent combination of biases that induce overengineering. There are also game theoretic phenomena and phenomena akin to evolutionary stable strategies present because of the biases and circumstances of team population compositions.
What he lacks in knowledge, he makes up for in confidence
Dunning-Kruger effect
First of all, we, as an industry, are very susceptible to the Dunning-Kruger effect.
“In the field of psychology, the Dunning–Kruger effect is a cognitive bias in which people assess their cognitive ability as greater than it is. It is related to the cognitive bias of illusory superiority and comes from the inability of people to recognize their lack of ability.”
The peak in the beginning of the graph, is called mount stupid. When people are standing on Mount Stupid, they have a tendency to yell and evangelize a lot.
The dunning-Kruger effect hits us at multiple levels. It hits us on an industry level, with the hype curve. The similarity between the hype curve and the Dunning-Kruger effect is no coincidence. It is the same underlying bias. In the industry we have a tendency to be very vocal about TAPs when we are on the top of Mount Stupid.
Organizations adopt these TAPs with very high confidence and very little knowledge. Typically people not onboard are deemed old school or shamed in other ways. Here the scarcity bias plays in a bit, i.e. the fear of missing out on the future market and opportunities if we miss this silver TAP.
On the team level it is a bit of a different dynamic.
Imposter Syndrome
On the team level there are multiple reason for introducing new TAPs. It can be curiosity, wanting to improve professionally, the CV or just trying something new and shiny.
Regardless of the motivation, it is typically a single or small amount of people pushing the new silver TAP.
The software development profession is the profession with the highest degree of people suffering from imposter syndrome. Above 60%.
Impostor syndrome (also known as impostor phenomenon, impostorism, fraud syndrome or the impostor experience) is a psychological pattern in which one doubts one’s accomplishments and has a persistent internalized fear of being exposed as a “fraud”.
Imposter syndrome means that the majority of team members, will assume that the reason they think the TAP seems too complicated, risky or downright stupid, is just because they themselves are themselves and not as competent as the proponents of the TAP.
This is exacerbated by the fact that it is very difficult to infer, as an outsider, whether people are evangelizing from Mount Stupid or from a Plateau of actual Competence.
Technologic Stockholm syndrome
The Dunning-Kruger effect and Imposter syndrome works together, to introduce new shiny and risky TAPs. The question is then, why do we not discard the TAP when it turns out that we made a wrong choice?
There are multiple explanations for this. It is a combination of the boiling frog, sunk cost fallacy and some version of technological Stockholm syndrome.
The TAP does usually not explode in one major incident. It is typically minor incidents of increasing scope, seriousness and damage.
We typically see tensions beginning to rise, when we break new ground, either feature or adoption-wise. As the tensions begin to rise, the chance of an actual fully blown incident starts to increase. The incident can be an actual production incident or it can be “the f***ing thing does not handle X/support Y/enable Z!”.
Under all circumstances something happens that creates a lot of stress, additional work and general “unwellbeing”.
We fight through the challenges, the pains and the frustration.
At some point we end up on the other side of the incident and begin to rationalize it and make excuses for why the TAP treated us, behaved or reacted like it did. And very often we end up blaming ourselves for the shortcomings or damage induced by the TAP. “We should have known that it would act up like…”.
We get to the other side of this bad experience, dig in deeper, add more sunk cost, and on the next iteration of this vicious cycle, we are even more determined to blame ourselves for the damages induced by the TAP. And even more determined to stand our ground defending it.
III. Value driven decisions in software development
What do we know about what makes the software delivery organizations tick?
Looking at the insights from State of devops Reports/Accelerate or if we look at research into what makes teams high performers, we are left with a short list:
Note that none of these mention specific technological choices. Some technological choices can support these, e.g. by decoupling teams to remove recurring blockers, but it is not a specific TAP that enables teams and organizations to be high performers or, to quote Gene Kim “To win in the market place” (although, after reading the Unicorn Project, I think he may have a caveat here about functional programming).
So my point here is that from the research into what makes software projects fail “Damage and damage causes in Large Government IT projects” we see that the places where technological decisions or TAPs makes a difference, it is when they jeopardize the projects through overengineering or untested assumptions. We see from other research into what makes teams and organizations perform well, that it is not specific TAP, but some quite simple and lean practices and cultural aspects. Simple, but difficult.
Thus we should ensure we get the best environment for high performance and avoid introducing unnecessary risks and damages into projects. As simple as that.
My current suggestion is a combination of nudging people to value driven technical decisions (NB: this list is intended to grow over time) as well as ensuring the psychological safety to do so.
1. Projects or products start out with at most 2 or 3 “risk tokens”
The idea with risk tokens is, at its core, to constrain development teams from taking too much risk on board in projects or products. When “Risk” is a scarce ressource, it nudges teams to discuss:
“Would we rather take on this risk A to get this value/gain X or would we rather take risk B to get Y?”
This encourages the discourse of value driven technical discussions and makes explicit that software development is, to a great degree, an exercise of managing risk. And risks should only be taken to get a corresponding value.
2. Identify, evaluate and remove things that block or delay
The keyword here is evaluate. Every time we see something in our work that creates friction, we should evaluate what we are trying to get out of it. I.e. what value is the process/tool/whatever intended to create? Is the friction created by it greater than the value we actually gain? Could we get that another way, without or with less of the friction and negative impact?
3. When people disagree, identify what they value or weigh differently, resulting in their different conclusions
People probably have their reasoning close to correct, so it is often not the case that one of the people disagreeing is correct and the other(s) did not reason correctly. It is often because they have different priorities or assigned importance to some of the factors going into the reasoning. More about this later.
4. Ensure developers know the user and customer
Please make sure your developers go on Gembas and get to see the place where they contribute value. It helps avoid value substitutes, it motivates people and it enables them to prioritize their focus and identify low hanging fruits. These things combined improves innovation greatly.
Do we measure value?
I got a good question in Stockholm about how value is measured in the decision process. This is a great question. Most often it is not important exactly what value or weight we assign to some basic requirement to, or benefit from, our solution. E.g. scalability, ease of use, simplicity, etc. But when we outline that we choose a specific solution over another, because we believe X to be important and Y to be much more important than Z, then we suddenly have hypotheses we are able to (try to) disprove or validate. This brings us much closer to an actual objective evaluation tailored to the specific challenge we face in a given situation, instead of basing it on unconscious biases and kneejerk reactions. This is especially important when exploring the underlying reasons for disagreements about what solution to use. (i.e. when trying to identify what people value differently resulting in their different conclusions).
We do not only have the exploration of what weight or priority we assign to various aspects of a solution, to make us understand each other. We actually do it to identify what discussion actually has a chance of changing our minds or clear up misconceptions. When we identify the a priori assumptions people have, these can be challenged and are often much easier to investigate the validity of with spikes or back of a napkin analysis. It can also act as an incentive or nudge for us to ask or talk to someone more knowledgeable (than us).
A way to induce good value evaluation
I have found that teams become better at focusing on values, when friction is removed, the process is stripped down to the bare minimum and the focus is on goals that solves specific problems or achieves certain outcomes.
By removing as much obligatory process as possible, the team is forced to evaluate the relevance and applicability of methodologies and tools in their specific context, enabling a much better software delivery performance.
A very concrete example of this, is described in my other articles, or in this video on Modern Software Engineering.
Post Script
In this post, I have focused very much on the dangers of overengineering. This does not mean I am unaware of the dangers of “underengineering” or using “legacy TAPs”. I simply think this latter danger or risk, is extremely exaggerated and the risks and dangers of introducing new shiny TAPs are very much downplayed or simply ignored.
I hope this “short” writeup makes you reflect a bit more, next time a TAP presents itself or you are starting a new project or product.
I look forward to discussing the finer details or the overall message. And please send me suggestions for items for the anti-overengineering list😊
This is a relatable article. Most customers and developers don't even consider what they're paying for in order to get value. This isn't a development issue, but rather a discussion of what to focus on and what to sacrifice in the business funnel.
Most damning insight: The 37 identified causes mostly appear in multiple projects. We keep making the same mistakes.
the distribution of failure modes across decisions is crucial. most teams focus on avoiding disasters but dont optimize for recovery velocity. strong post
When I look at success stories, most of what's needed for success is not only not in the popular Agile frameworks, its denied to exist. Here's a little of what I see missing but essential: 1. clarity on who your critical stakeholders are and what their values, success criteria, and constraints are 2. an appreciation for inherent simplicity (actually denied in Scrum and insufficient in SAFe). 3. an understanding of flow 4. a focus on stakeholders in defining value instead of users 5. a systems thinking view 6. having someone on the adoption who has good coaching skills (frameworks often fail because they leave out coaching or consider it a 2nd-3rd round training option) 7. trying to adopt someone else's solution to your situation (e.g., a framework that doesn't include how to tailor it - i.e., all frameworks) 8. belief in the iron triangle. so much more. This is a lot. And the reason it's not taught is that people take the easy hyped road of frameworks. This has resulted in a focus on certification and incredibly ineffective, expensive training. AI is the next hype It's useful, but AI is a mirror of who is driving Training from framework companies is designed to require more training and more consulting. https://bit.ly/4ss2EAa
I've seen this so often in private and public sector projects. Tom Gilb, Al Shalloway and Niels Malotaux have been saying much the same for quite a while, and they all have success stories that show that the problem can be solved, so long as top management has the will to solve it.