1.1 Operational Excellence and How Software Development Works
A long-standing curiosity about certain aspects of software development has accompanied me for 18 years of professional experience. After enough sweat and tears, I could paint a coherent picture of what this curiosity consisted of and even some insights into its answers. It could be expressed as follows:
Both questions could be condensed further and fused into one: how can software organisations achieve operational excellence in their development and delivery projects?
The answer to the first doubt on the presence of a deep philosophy and coherent framework for understanding software is as follows. Until a few years ago, my understanding of software development and business management consisted of parallel narratives occasionally presenting irreconcilable paradoxes. For instance, the following (apparent) paradoxes were most intriguing:
Depending on whom you talk to (management vs. employee, individual vs. group), different justifications would be laid on the table, each equally compelling and truthful, at least in the eyes of their beholders.
After much research, the answer to the second question concerning the universality of methodologies, methods, and practices ran like this. It turned out that methodologies, methods, and practices are not context-free, as Dave Snowden tries to explain using his Cynefin framework. The question of context is key, and methodologies, processes, tools, and practices rarely apply efficiently in all situations.
What about cults and rituals and the dogmatic wars between the different schools of project management (Agile vs Waterfall vs DevOps, Scrum vs Kanban, or Safe vs Waterfall)? How can we separate the core principles (delivery on time and budget of quality software) from commoditised half-truths? That was a follow-up question to the second, which also deserved close inspection.
1.2 A Philosophy and Framework of Software Rooted in Science
In the first part of this series, we focused on the structure of software development, relying on theories from cognitive science, group psychology, natural science, and organisational theory to define solid assumptions from which we could derive (with sufficient rigour) the seven disciples that will be the central topics of our discussions here.
These seven disciplines of operational excellence are not universal and will apply in a specific context, which we will define in detail in the coming paragraphs. Although this boundary on the domain of applicability of these ideas is a limiting factor, the domain itself is broad enough to encompass many projects forming the bulk of the work in most software organisations.
More specifically, the principles of operational excellence will apply to large software development or integration projects with varying team sizes. Some of the seven principles will apply less effectively in small teams (or startups) working on novel ideas, technologies, or industries requiring a less structured, more dynamic approach.
In the remainder of this article, we will define Operational Excellence, specifically focusing on software development. We will discuss The Toyota Way and the Toyota Production System. We then describe the seven principles of Operational Excellence in Software Development and to effectively deploy them in an organisation.
2. Operational Excellence in Software Development
2.1 A Brief History of Toyota and the Toyota Production System
Operational Excellence has its roots in the automotive industry. It started in the 1950s when post-war Japanese car manufacturers struggled to catch up with the potency of mass production – a method in which their giant American competitors had a significant edge. Henry Ford deployed the assembly line for the first time in 1913, capable of mass-producing an entire vehicle.
With massive resources and a vast market at Ford’s disposal, there was very little the Japanese automakers could do to compete. The situation, however, changed drastically in the late 1980s, and the Japanese carmakers, especially Toyota, were doing significantly better than their American counterparts. For the next few decades, the Japanese produced exceptionally better cars at highly-competitive costs. Their market share kept increasing year on year.
To make that happen, Toyota and other Japanese manufacturers deployed a strategic weapon that would later be known as the Toyota Production System (or TPS), a set of 14 business management principles (articulated fluently in a now classic work by Dr Jefferey Liker) that Toyota lived by. The principles were also supplemented by a philosophy of business management that gave meaning to the organisation’s existence and the work Toyota’s employees are doing.
As Toyota grew from a Japanese car manufacturer to a global player, it had to promote and apply the Toyota Production System in its overseas factories. To explain TPS in a language that transcended culture, The Toyota Way was introduced. Essentially, The Toyota Way is centred around respecting people and applying continuous improvement.
The Toyota Way and the Toyota Production System were so efficient that professionals from different industries started looking at incorporating its ideals into their businesses. Think of Kaizen, Kanban, and 5S. All three originated at Toyota and carried its trademark. Although, on the surface, car manufacturing bears minimal resemblance to software product development (or services in general), there is enough overlap to warrant a serious discussion, as we have thoroughly discussed in Part 1.
We believe software development can benefit from various concepts successfully applied in the car business. This article will look at how software development and delivery can profit from the philosophy and principles of Toyota, not by repeating principles most elegantly narrated in Liker’s book but through practical guidelines that developers can immediately relate to.
2.2 Chaotic Organisations and Operational Excellence
In our preliminary (mostly theoretical) discussion of Operational Excellence and the Structure of Software Development and Delivery, we tried to convey a central idea on strategic management that applied equally well to specific instances like software development. The idea is that organisations are complex systems, and their evolution is chaotic and uncontrollable. This brings us to the question of how Toyota, for example, managed to negotiate the high waves associated with this complexity and consistently grow and do well over many decades.
Toyota’s success has been described briefly in an interview Dr Liker gave (the full story is, of course, in his books) and goes as follows. Management’s vision for the next years or decades is articulated into clear targets and objectives, which are then attained by deploying Operational Excellence. In Liker’s words, Operational Excellence is about execution (people, processes, tools) or how to achieve those objectives.
Once again, the ideas in the last few paragraphs seem paradoxical; on the one hand, we have a complex system that is practically unpredictable or unmanageable in the long term. On the other hand, we have a proven framework (Toyota Production System) for working under what we believe would be similar conditions.
When we look at the details, however, we find that the lower-level concepts, frameworks, and processes (partially) overlap between the Toyota Production System and those from Complexity Theory (promoted by key thinkers like Dave Snowden and Ralph Stacey). These similarities and differences are illustrated in the following table:
|Problem||TPS Solution||Complexity Theory Solution|
|Theoretical framework||Long-term systems thinking||Complexity theory|
|Meaning and purpose||Benefiting society through meaningful contributions||[No equivalent]|
|Vision||Set by top management||The future is almost uncontrollable; management should focus on the present.|
Genchi Genbutsu (personal involvement or “go see for yourself”)
|Collecting intelligence via a human sensor network in real-time. Indexing narratives and stories told around watercoolers.|
|Hierarchies and decision-making||Top-down, making decisions slowly, coaching instead of forcing solutions||Self-organisation with boundaries, distributed ideation with centralised decision-making (or any other combination)|
|Planning||Cascading vision and plans from top management all the way to employees on the shop floor||Managing in the present, Agile, Scrum, sprints, adjacent possible|
|Root-cause analysis||5 Whys, the Fishbone diagram||Causality is difficult to establish, strange attractors|
|Solution finding||Exploring many alternatives, avoiding solutions from above||Conducting safe-to-fail experiments, distributed ideation|
|Continuous improvement||Challenging objectives, Kaizen, Plan-Do-Check-Act (PDCA)||Enabling constraints, micro-interventions, fractal engagement|
|Establishing order||Standardized processes, a conservative approach, and a healthy respect for authority||Boundaries and governing constraints|
|Innovation||[No equivalent]||Exaptation, Serendipity|
|Leadership||Internally grow leaders who live the philosophy and understand the culture||Leaders must manage, and managers must lead. Leaders must manage the present and abandon hopes of controlling the long-term evolution of the organisation.|
|Quality Control||Built-in quality, visual controls, and one-piece flow to prevent issues from being hidden||[No equivalent]|
|Warehouse management||5S||[No equivalent]|
|Design||Getting feedback from many sources, possibly from experts outside the field||Agile design, designing for serendipity|
|Flow||Respect for people, meaningful jobs||Changing the nature of people’s interactions rather than their mindsets|
|Technology||Technology serving the customers and the processes||The interplay between technology and changing client preferences.|
The columns in the table above are not isomorphic (share the same meaning) but are loosely coupled. To clarify that isomorphism, we observe the following:
2.3 Operational Excellence in Software Development
So where does that leave us regarding Operational Excellence in software development? First, I believe we need to understand the sources of complexity in software, without which this conversation may not be worthwhile. Experience shows us that, in software development, complexity arises as follows:
Complex, uncertain, and uncontrollable as it may, we are not saying that managing large software projects or businesses is hopeless. On the contrary, excellent theories and practices have been published and are ready to be deployed, even though many have not yet become mainstream. For example, we have tangible evidence of the benefits of Agile, DevOps, and test automation. However, these wins fall short of our objectives (and needs) for achieving Operational Excellence, hence the seven principles we will discuss shortly. Even with those principles, Operational Excellence can be achieved in certain contexts while others remain out of scope. We will discuss the domain of applicability of those seven principles shortly.
3. Challenges of Delivering Software and a Novel Approach to Software Development
3.1 Successful Software Business
Successful software businesses have the following properties, which surprisingly resemble manufacturing to some degree, and services a lot.
3.2 Common Challenges of Delivering Software
Now that we know our targets for a successful software business, here are some examples of why that is more challenging than it looks.
These are just the high-level issues forming a common denominator between most software organisations. Differentiation and local problems will impose themselves when we get into the details. For the time being, I believe the list above will cover the majority of issues of interest.
In Operational Excellence and the Structure of Software Development and Delivery, we examined the complexity of diagnosing and troubleshooting organisational issues. We concluded that cheap solutions wouldn’t do, and successful ones would have to rise to the required level of sophistication and potency.
Luckily, many original thinkers have articulated what assumptions, frameworks, and paradigms those sophisticated solutions should be built upon. These assumptions, frameworks, and paradigms will form the basis for our approach, which we now describe.
3.2 A New Approach and Solution
As you might have guessed already, the fundamental ideas behind the seven Principles of Operational Excellence in Software Development will be based on those from the Toyota Production System, Organisational Theory, and Complexity Science. These ideas are heavily influenced by this author’s personal experience and the specificities of the software industry.
These three pillars, organisations as complex systems, the importance of the human element, and the commonality of the underlying drivers in the value chain, will form the basis of the seven Principles of Operational Excellence in Software Development. But before we tackle these seven principles, we must first discuss the limitations of this approach.
Software Delivery Value Chain: Unveiling the Key Challenges and Opportunities for Successful Delivery in Today’s Market
4. Context and Domain of Applicability
4.1 The Organisation’s Lifecycle
Various management scholars and practitioners have widely discussed and promoted the concept of an organization’s lifecycle and its different stages. Notable thinkers and management consultants were behind these ideas:
4.2 Critiques of the Organisation’s Lifecycle Model
While the model of organizational lifecycles has been widely discussed and utilized, it is not without its critiques. Here are some common criticisms of this model:
4.3 Organisation’s Lifecycle and Operational Excellence
This stability is, by definition, not present in startups or organisations in crisis. In startups, power hierarchies, typically dominated by the founders, dictate what can and can’t be done and how the organisation should operate. The main objective of startups is to establish themselves as viable players in the market. Sustainability, through Operational Excellence, is for a later stage.
Companies in crisis typically have high anxiety levels and have not had the luxury of slow, rational, and deliberate pondering on improvement through Operational Excellence. Their main objective is surviving the crisis.
At these two extremes, startups and times of crises, discussions on Operational Excellence can be futile. Therefore, the following prerequisites must be available before Operational Excellence can be conceived as a long-term goal.
Now that we have everything in place, let’s look at the seven principles of Operational Excellence in Software Development.
Principle 1: Eliminate Cultural Blockers
5.1 What are Cultural Blockers?
The 15th State of Agile Report and the 2021 State of DevOps Report cite cultural blockers as primary challenges in adopting Agile or DevOps. In this sense, perhaps it makes sense that the first principle of Operational Excellence would focus on managing cultural blockers that impede growth and success. We say managing and not eliminating as the latter would be too difficult, if not impossible, as we shall see in a moment. So what are those cultural challenges?
Cultural blockers are prime detractors of Operational Excellence and can be defined as the answer to the following question:
The answer to this question can be provided by acknowledging that organisations are not machines, a point we have discussed extensively in Part 1. If they were, a combination of superbly engineered processes and great talent and skills would be enough to drive performance and productivity.
What is missing is the human element called organisational culture; this can be summarized as shared beliefs on how the system should be designed, driven, and led and what its ultimate objectives must be. Also fundamental to this concept is the employee’s perception of the nature of their contribution and how much meaning these contributions give to their efforts.
5.2 Organisational Culture
Edgar Schein, an influential American organizational psychologist and consultant, describes organisational culture as consisting of three layers: artifacts, values, and assumptions:
In his seminal work, Gödel, Escher, Bach: an Eternal Golden Braid, professor Douglas Hofstadter explores the many layers of stability that underpin our individual worldview. To explain this concept, Hofstadter uses mathematical (and programming) notions of constants, parameters, and variables.
In the situation […] represented by the symbols, c establishes a global condition; p establishes some less global condition which can vary; and finally, v can run around while c and p are held fixed. It makes little sense to hold v fixed while c and p vary, for c and p establish the context in which v has meaning.
— Douglas Hofstadter, Gödel, Escher, Bach: an Eternal Golden Braid
The last sentence is pure insights. Shared assumptions and values (constants and parameters in Hofstadter’s metaphor) provide context without which our fleeting daily experiences have no meaning. This powerful idea explains why change (which consists of modifying what is supposed to be constant) is indigestible, traumatic, and anxiety-ridden.
To illustrate the impact of culture on organisational growth and evolution, consider the time management issue. For example, what are the mainstream views in your organisation on the following questions?
The perception of time in a group of individuals is integral to an organisation’s culture. How you answer the above questions determines the disposition of an organisation to move forward, backward, or maintain the status quo.
The perception of space is equally important in organisational culture. This can be observed mostly in how offices are designed and how space is allocated according to rank and hierarchy.
5.3 Change Resistance
Cultures (tribal, familial, national, organisational) are cognitive constructs deployed as defensive mechanisms that help groups cope with internal integration challenges and challenges their environment poses.
If the group were to survive, it would need to adapt and respond to those threats in new ways. Its leaders and members must unlearn old methods and learn new ones. This process is traumatic and does not necessarily succeed all the time.
Returning to our metaphor on constants, parameters, and values, and the different levels of stability that each offers, we can make the following straightforward observation. The higher the hierarchy, the stiffer the resistance will be.
Cultural Transformations and Resistance to Change: Understanding the Risks to Your Organization’s Growth
5.4 How Can Cultural Blockers Be Managed
It might sound a bit defeatist to admit that organisational and cultural transformations are extremely difficult, if not impossible, to execute. Nevertheless, eminent thinkers and practitioners have presented several ways of managing change and softening cultural blockers. Leaders play a central role in all these practices. Let’s see what these practices offer.
It is critical to understand that cultures are, as Snowden most eloquently puts it, emergent properties of complex systems and, therefore, cannot be engineered. You can’t design a social group, but you can manage an agent’s interactions to direct it. Most crucially, intervention in a complex system (such as changing interactions) will always have unintended consequences, making predictability ever more challenging.
Principle 2: Process Engineering, Management, and Governance
6.1 What Is a Process?
A process is a set of actions or tasks designed to produce a desired outcome by consuming and transforming resources like energy, data, and material. Processes are central to manufacturing, software development, science, and business management.
Processes can vary widely in nature (manual vs automated) and complexity (linear and sequential vs iterative, parallel, interlocking, with feedback loops).
6.2 The Relevance of Structure and Processes
Processes provide a structured method for delivering business value. However, too much structure stifles innovation, creativity, and the system’s ability to adapt to new challenges; it becomes fragile. On the other hand, too much dynamism induces chaos, an expensive state of affairs that cannot be maintained long, and which eventually forces the system to settle into an equilibrium state where processes emerge from self-organisation along paths not necessarily leading to desired outcomes (like maximum productivity or top quality).
The questions that arise can be stated as follows:
We will answer these questions briefly in the following sections. Still, the interested reader is invited to explore other articles on Process Engineering, Six Sigma, and Process Improvement on this website.
6.3 Agile Processes
Agile is currently in a state where every person you ask has a different opinion, interpretation, perspective, or story about it, to such an extent that there is hardly any common thread between them. This tragi-comical situation has left all Agile-related questions open-ended, and one, in particular, has to do with specifying software development processes and team structure. Let’s focus on processes and leave team structure for another article.
Agile answered concerns about the software development and delivery methodology employed at the time, which was heavily centred on Waterfall. The resulting practices (XP, Scrum, Kanban…) still involved well-defined processes. These practices have become so ritualised, varied, and specialised that they lost much of their original potency. At no point did Agile stipulate that the best way forward in software development is to throw away everything that has worked in the past and replace it with something novel.
Process engineering and flexibility are unrelated to Agile, Waterfall, or any other flavour of preferred software development methodology and can be discussed separately. This is exactly what Principle 2: Process Management and Governance aims to achieve.
6.4 Process Engineering
The underlying metaphor when approaching the subject of Process Engineering is that of manufacturing, where employees in the workshop perform repetitive tasks to produce thousands of identical pieces. Although at the heart of the Toyota Production System and Quality Management, this metaphor is out of sync with software development, and if we must discuss process engineering in software, an alternative metaphor must be found. Therefore, we propose expanding the scope of Process Engineering in software development to mean the following:
Process Engineering: Essential Concepts from Lean, Agile, and Toyota for Effective Software Development Processes
6.5 Process Improvement, Reengineering, and Redesign
Managers dedicate much energy to discussing continuous improvement, a term that has become so cliche that it lost all meaning. In Toyota, continuous improvement has a well-defined meaning: How can the organisation rebuild its products, people, and processes to match a future vision?
In Principle 2: Process Engineering, Management, and Governance, we will focus more on the continuous improvement of software development processes and what guidelines software organisations should follow to keep their processes on par with the present challenges.
The below list includes our definitions of the relevant terms:
In the next section, we will cover a few ideas on how best (or mainly what prerequisites are needed) to implement process changes.
6.6 Process Engineering Guidelines for Software Development
The reader will find that the ideas we will present shortly on engineering and improving processes are in the same spirit as those in Part 1: Operational Excellence and the Structure of Software Development and Delivery and the remainder of this article. This consistency is reassuring as it shows that the models and frameworks we use (complexity management and The Toyota Way) are coherent, covering most dimensions of the interesting aspects of software development.
So how can we design and improve software development processes using concepts from complexity management and the Toyota Production System? Here are some guidelines.
These guidelines are enough to conclude a section on Principle 2: Process Engineering, Management, and Governance but remain at a high (and somehow abstract) level. Still, we have discussed them in sufficient detail in separate articles, focusing more on their implementations’ technical and practical aspects. The interested reader is invited to browse these articles for additional insights.
Principle 3: Draw a Line Below Which Quality Does Not Go
7.1 Problem Description
When you have aggressive deadlines or your project is running out of time or budget, there are only four things you can do:
- Reduce the scope
- Extend the deadline
- Commit additional resources
- Sacrifice quality
While the first two options are your best bets, and the third option is not always feasible, the fourth one (sacrificing product or delivery quality) is what most people would consider. There is a good explanation for why this can be appealing; sacrificing quality today will only surface in the future, and furthermore, it will be someone else’s responsibility.
Sacrificing quality creates a drag on your delivery capabilities. If left uncontrolled, it will transform your product from a lucrative asset to a liability. In the long run, sacrificing quality will have detrimental and irreversible effects on your business.
Peter M. Senge documented this organisational behavioural pattern in a 1990 book, The Fifth Discipline. Eroding Goals was the name Senge gave to an organisational dynamic describing a positive feedback loop where managers increasingly accept lowering standards to retain the same delivery capabilities.
In software development, Eroding Goals can be seen with rising technical debt. Technical debt makes the next delivery harder, requiring managers to accept more technical debt to keep deliveries on track. At some point, these become so slow that you risk being completely outrun by competition.
Keeping quality above a certain mark prevents organisations from slipping towards a path of Eroding Goals.
7.2 Levels of Software Quality
Technical debt can be subdivided into four categories, not all equally problematic. This means managers can be selective when deciding which to carry and which to avoid. Let’s see what these look like:
7.3 Draw a Line Below Which Quality Does Not Go
The best way to remedy such situations is to avoid being exposed in the first place. This can be achieved through an open and transparent discussion with business stakeholders every time the backlog is saturated with high-priority items and not waiting for it to overflow. A positive outcome of these discussions means a reshuffling of priorities, deadlines, or resources.
However, there will be times when moving things around (deadlines, scope, or resources) would not be feasible and when the only option left is delivering on time, regardless of the (technical) risk or cost (such as when the organisation’s reputation is at risk). What should managers do in this case?
The short answer to this question is drawing a line below which quality doesn’t go. The long answer can be found in the following paragraphs, where we list a few guidelines and best practices for keeping software quality up to scratch.
7.4 Guidelines for Maintaining Product and Delivery Quality
Though not mutually exclusive, product and delivery quality might collide head-on with scarce resources or aggressive deadlines. Product quality means building the right thing right. Quality delivery means fast and affordable delivery. Here is a list of actions managers can take when struggling with product vs delivery priorities. The list is ordered from top recommended to least.
A fourth option, which must never be applied, is sacrificing long-term quality (carrying architectural debt and ignoring technical debt) for short-term wins. Despite its undeniable irrationality, managers may focus solely on the present if their jobs, bonuses, or careers depend on it. This can be observed in a system where the individual and the group’s interests are not aligned or contradictory. Therefore, the rewards system of incentives, benefits, and promotions must favour strategic goals.
Software Testing and Quality Assurance: A Modern Analysis of Its Internal Dynamics and Impact on Delivery
Principle 4: Implement Agile Processes Where Applicable
8.1 What Is Agile and How Will It Help
Interestingly, two decades after the Agile Manifesto was announced, there is still no widespread agreement on what Agile looks like. While everybody agrees that Agile practices must include user stories, sprints, backlogs, and Kanban boards, the basic underlying principles of Agile (and what problems its original creators’ intended it to resolve) seems elusive.
While Agile training, certifications, and coaches abound, Agile seems to have lost its teeth. In Snowden’s words, Agile has been “domesticated”. The domestication metaphor and the subsequent call by Snowden to wilden Agile again deserve some explanation. The curious reader is invited to view any of Snowden’s lectures on Agile or head to our article on Agile’s history and first principles.
So what is Agile, and why is it vital for operational excellence in software development? Agile was born from Extreme Programming (XP), Scrum, and what was known back then as lightweight methodologies. These were presented as an alternative to Waterfall and were destined to solve some of the problems that plagued large software development projects, of which the following two are most relevant to our discussion:
Does this mean that Agile is the universal solution to software development projects? Is Waterfall obsolete? Not quite. Let’s look at why this is not the case.
8.2 It’s Not Agile’s Fault That It Can’t Scale
Agile does a fantastic job in small teams. However, because of its high interaction levels and dynamic nature, its cost at scale becomes prohibitive. Consider the following scenarios:
It might seem absurd to discuss organisational strategy after everything we said above and in the first part on the challenges involved in predicting an organisation’s future behaviour, let alone controlling it. A closer look, however, would dispel those doubts. Short sprints (a couple of weeks) in small teams seem appropriate. Larger teams can go for 3-6 month sprints, while it’s entirely reasonable for organisations to have 2-5 year plans.
Agile can scale, but not necessarily through SAFe, Kanban, or Scrum. A bit more on that in the next section.
8.3 Agile Across the Organisation
The following are some guidelines on how to make the best of Agile in your organisation.
Principle 5: Focus on Business Value
9.1 Customer and Business Value
So far, we have used customer value and business value interchangeably. It’s now time to get the right definitions in place.
Customer value can be measured in various ways, such as through:
Businesses must understand and deliver customer value as it contributes to customer retention, market competitiveness, and long-term success.
Business value can be measured through various financial metrics, such as:
Business value focuses on the outcomes and results achieved by the business as a whole.
Customer and business values are the north stars on the map of operational excellence in software development. They are the centre of mass around which everything else gravitates.
While such a fact seems fairly obvious and does not need further elaboration, the reality is a bit more complex.
These complications typically manifest themselves in constant arguments between departments on whether to build the right product, the best product, or that which is easiest to launch in the market. While these discussions might be healthy in some cases, there will be instances where different units pull the cart in opposite directions. Rather than zigzagging towards the ultimate goal, they get stuck in vicious loops.
To remedy this problem, the role of a product manager was put in place. However, looking after a software product from a commercial and customer value perspective is insufficient; technical considerations must also be considered to sustain the product. This leads us to conclude that every resource involved in a software product must understand why this software is built (customer value) and why it is important for the organisation (business value).
9.2 Product Management
Product management encompasses the end-to-end process of conceptualizing, developing, launching, and managing products throughout their lifecycle. It involves a multidisciplinary approach, combining:
Product managers act as the orchestrators, aligning customer insights, market trends, and organizational goals to deliver value-added solutions. Their roles typically include the following activities:
Many things can go wrong when managing large software products in complex ecosystems. However, the following are the top pitfalls encountered:
9.3 Minimum Viable Products
The Minimum Viable Product (MVP) is a strategic concept that focuses on delivering:
A Minimum Viable Product (MVP) is like a usable prototype put into active service and monitored for insights. An MVP provides the following advantages:
There is, however, one common pitfall in working with MVPs regarding interpreting user feedback. Misinterpreting user feedback or relying solely on anecdotal evidence can lead to misguided decisions. Teams should leverage robust feedback mechanisms like user analytics and surveys to extract actionable insights and make data-driven improvements.
9.4 Modernizing Legacy Software Products
Legacy software modernization involves upgrading and revitalizing existing software applications to:
Modernizing legacy software requires a significant initial investment and immense leadership support for the following reasons:
Finally, organisations must recognize the difference between upgrading legacy software because of its inherent limitations or the presence of imminent threat from competition on one hand and the need for technicians in the organisation to switch to the latest and greatest technology stack. In the former case, we are correctly focusing on business value and its future. In the latter, we are succumbing to hype.
9.5 Guidelines for Prioritizing Business and Customer Value
Following are powerful guidelines that organisations can apply to ensure they always focus on customer and business value.
Principle 6: Use Mature and Proven Technology to Serve Your Customers
10.1 Business, Software, and Technology
The complex interplay between technology and business, especially in software, can be abstracted to the following ideas:
Software, in this sense, can be quite different from manufacturing. For example, Toyota cars benefit from 50 years of incremental improvements in precision instruments, electronics, engine and transmission designs, and aerodynamics. The first car to be mass-produced was the Ford Model T, launched in 1908, more than 110 years ago. Software is comparatively young, by contrast.
Software is also more dynamic. In Part 1 (Operational Excellence and the Structure of Software Development and Delivery), we listed the most notable revolutions in the software industry since its inception, and there are quite a few, especially considering the short lifespan of the industry. By comparison, the automotive industry has progressed through fewer revolutions.
Let’s examine this statement in more detail by exploring the pros and cons of the (sometimes premature) adoption of novel tech.
10.2 Mature vs Novel Tech, Which Is Best?
Unless you work in high-tech mega-corporations like Google or Tesla or in Research and Development projects, relying on mature and proven technology is generally advisable for a safer and more efficient approach.
The advantages of adopting such an approach are readily apparent:
While some may perceive this approach as lacking excitement or novelty, it is undeniably a safe, dependable, and profitable strategy. Let’s explore some concrete examples to illustrate these advantages further:
These examples highlight how mature technologies bring tangible benefits across diverse sectors. By leveraging established solutions, businesses can capitalize on their wealth of resources, stability, and compatibility, resulting in safer, more efficient operations and ultimately driving profitability.
10.3 Guidelines for Working with Technolgy
Following are some best practices that can be used to great effect when dealing with technology:
11. Have We Missed Anything?
Yes — communication, leadership, group psychology, norms, culture, organisational behaviour and theory, interpersonal relationships, conflict resolution, resource allocation and management, the list can stretch quite a bit more. So where does Operational Excellence stand on these points, and how do these issues, in turn, affect an organisation’s ability to achieve high execution standards? We will try to answer these questions through a chess metaphor and some basic game theory concepts, specifically on infinite games.
11.1 Operational Excellence and Middle Game Mastery
In chess, the game can be divided into three main phases: the opening, the middle game, and the end game. Each phase has its own goals and strategies. We can think of organisational development and evolution along similar lines.
The opening game is similar to the founding stages of the organisation or group where culture, norms, and processes are created (initial conditions in complex systems parlance). These initial conditions have a long-standing impact on the group’s future development. The goal of the “opening game” in organisational development is to create a great culture, identify your value proposition, hire the right talent, and work on a strategy for growth and development.
Operational Excellence is particularly out of context in the following situations:
What about end games? The objectives and strategies can vary in chess endgames depending on the position and material balance. They typically include: checkmating the opponent’s king, promoting pawns, gaining a material advantage, and keeping one’s king safe. Organisations have no end games; therefore, the rules of play differ.
11.2 Short-Term Wins, Operational Excellence, and Infinite Games
In game theory, infinite games extend indefinitely over time, whereas closed games are finite with a specific endpoint. These two types of games differ in duration, strategies, and potential outcomes.
Running a business, especially if you aspire for Operational Excellence, must consider the following topics:
Writing down six principles and innumerable ideas, concepts, and theories on how something ought to be done is very different from putting those thoughts into practice. One cannot but feel powerless when contemplating the job’s immensity or the intimidating height of its entry barrier.
This feeling of overwhelmedness puts into question the fruitfulness of such an endeavour and whether people are not better off focusing on low-hanging, isolated, and localised objectives in the hope that a global, cumulative, and incremental improvement will become noticeable shortly. This reasoning is behind the concept of “managing in the present”, a fundamental approach to working with complex adaptive systems, as we have seen earlier.
Maybe the Toyota Production System and its version of operational excellence would not have been possible outside of Japanese culture. Maybe Schein’s organisational culture and processes model does not apply effectively outside Western cultures. This line of inquiry again pushes the issues of context and cross-industry learning to the forefront.
While the answers remain open, we have little choice but to hang on to what we believe is a consistent framework (and structure) on how software development should be carried out. Just like democracy became the norm only a few centuries ago, despite its fundamental concepts elucidated more than two thousand years back, we hope the young software industry will adopt a similar framework. Whether it settles down on the six concepts above or new ones altogether does not matter.
As far as this author goes, having a working compass and knowledge firmly rooted in theory and practice is crucial. This knowledge provides meaning to our actions and allows us to make sense of our experiences while the compass guides our future steps. We hope the reader has found similar insights into those ideas.
- The Toyota Way – 14 Management Principles From the World’s Greatest Manufacturer — Jeffrey K. Liker
- Strategic Management and Organisational Dynamics (4th edition) — Ralph Stacey
- Organisational Culture and Leadership — Edgar Schein
- Process Consultation and Organisational Development — Edgar Schein
- The 7 Habits of Highly Effective People — Stephen Covey
- Thinking Fast and Slow — Daniel Kahneman
- The Six Sigma Way — Peter S. Pande, Robert P. Neuman, Roland R. Cavanagh.
- HBR at 100 — The Most Influential and Innovative Articles from Hard Business Review’s First Century — Harvard Business Review