Principles of Operational Excellence in Software Development

Georges Lteif

Software Engineer

Last Updated on September 24, 2022.
Subscribe now to stay posted!
About Us
29 min read

1. Overview

Operational Excellence had its roots originally 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. It was 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 significantly 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: something that would later be known as Operational Excellence.

Toyota then moved on to perfect its production methods and management model.

While the former was subsequently known as the Toyota Production System (or TPS), the latter became The Toyota Way. Both heavily inspired many industries.

---

The Toyota Way and the Toyota Production System were so efficient that professionals from different industries started looking at incorporating its concepts and methods in their businesses.

Think of Kaizen, Kanban, and 5S. All three originated at Toyota and carried its trademark.

Although at the surface, car manufacturing bears minimal resemblance to the development of software products, there is a significant overlap in some other areas.

We believe software development is well-posed to benefit from the concepts successfully applied in the car business.

In this article, we will look at how software development and delivery can profit from the philosophy and methods of Toyota.

---

2. Table Of Contents

---

3. Challenges of Delivering Software

Let’s examine why new solutions are required for issues in industry over 70 years old.

3.1 Types of Challenges

The challenges organisations face can be broadly divided into shared and industry-specific.

Shared challenges are heavily centred around the human element and can include any of the below:

1. Organisational culture
2. Group behaviour
3. Leadership
4. Stakeholder management
5. Collaboration
6. Team motivation and morale
7. Business, team, and individual performance
8. Dealing with internal and external threats and opportunities
9. Risk management
10. Recognizing and dealing with complexity

Industry-specific challenges are mainly technical. An example can be:

1. Tools and infrastructure
2. Processes, frameworks, methodologies, and techniques
3. Technology and innovation
4. Competition and the fast-changing environment

Every industry in the technology business can have its own set of tools with which it carries about its business. Choosing a suitable technology stack, a set of tools, delivery methodologies, and production processes must follow specific rules to be efficient, and effective, and enable and increase your value proposition.

3.2 Why Software Projects Fail

Let’s examine examples to understand how these challenges translate into real-world problems.

A significant portion (around 80%) of IT projects either finish late, over budget, or with less business value than initially promised. Some projects never even make it into production.

The top reasons for IT project failures (sources: Forbes magazine, a paper published in Association for Information Systems, and this article that appeared in PMI) were given as follows:

#	Reason Why Projects Fail
1	Unclear business requirements
2	The solution design and the final application did not match business requirements
3	Substandard planning and execution
4	Lack of standardised production processes
5	Working in silos
6	Lack of agile practices
7	Friction caused by undefined roles
8	Lack of discipline
9	Inadequate testing and quality assurance
10	Focusing on technical detail instead of business value

Let’s have a look at a different but not entirely unrelated topic: the adoption of Agile as seen in 2021. Agile is a project delivery methodology that has been around for more than two decades.

Participants in the 2021 State of Agile Report survey provided the following answers regarding the slow adoption of Agile in their organisations:

#	Reason	Per cent of Participants
1	Inconsistencies in production processes and practices	46%
2	Cultural clashes	43%
3	General organisational resistance to change	42%
4	Lack of skills and experience	42%
5	Absence of leadership participation	41%
6	Inadequate management support and sponsorship	40%

The following sections will provide guiding principles that will help tackle most of these challenges.

3.3 Addressing the Challenges of Software Delivery

To address the challenges of Software Delivery, we propose the following three-step plan:

1. Find the root cause of those challenges
2. Leverage Other People’s Experiences (OPE) to find mature and proven solutions
3. Create mechanisms that can deal with novel or atypical future challenges

• Step 1: Root Cause Analysis. Rooting out the cause of an issue requires fluency in the field and persistent perseverance to get to the bottom of the problem.

We have done quite a lot of research and dedicated full articles to many of those challenges that are shared between organizations:

• Organizational culture
• Cultural transformations
• Project delivery (Agile, Waterfall, DevOps)
• Decision-making and collaboration
• Time management on the organizational and individual levels

On each occasion, we went back to the source to understand the circumstances that led to the creation of a specific idea or concept. We also looked at some retrospectives from influential opinion leaders who got their hands dirty trying out their ideas.

The research effort allows for an informed, evidence-based opinion on what works and does not. In most cases, firsthand experience was added to the mix.

• Step 2: Leveraging Other People’s Experience. This is not an easy job; it requires a lot of poking around, an open mind, and no small amount of luck. The latter helps you stumble upon those precious sources of knowledge where valuable techniques can be transferred from a different field or industry to your own.

Earlier, I divided Software Delivery challenges into two categories: shared problems mainly centred around human groups and industry-specific problems of a more technical nature.

We will lean on the Toyota management principles for inspiration on issues of a slightly technical nature, such as production processes and quality management.

Moving solutions across borders is called creative problem-solving, and we have used this technique extensively when looking at Toyota and Six Sigma practices.

As we shall see later, Toyota has developed and deployed articulate and highly-effective strategies for addressing quality and performance issues with excellent results. Six Sigma has also taken proven techniques like DMAIC to a new level.

We believe those strategies are industry-agnostic and can be put to great use in software.

• Step 3: The third and final step in the plan is process management. The latter can be defined as an overarching governance process that monitors production processes and intervenes when they degrade.

The technology world is vast and dynamic. Staying ahead of the curve is essential for the business’s survival.

Whether internal or external, every new challenge will require modifying how things are done today. 

Sometimes the changes can be small and localized. Other times, they are significant and disruptive. In the former case, they are called incremental changes, and in the latter, they are called redesign. Together, they fall under the umbrella term process management.

---

---

4. Operational Excellence in Software Development

4.1 Approach

The Toyota Way involves 14 management principles implemented in the Toyota Production System (TPS).

Some of these principles, like the Just-in-Time (JIT) system, are very specific to car manufacturing, and although they would make for a great read, their utility does not readily come across in the software space. Other principles like Genshi Genbutsu will be incredibly beneficial.

Six Sigma is also another place to look for solutions. Despite the limited utility of strategies that heavily depend on data and statistics in small to medium-sized businesses, the backbone of Six Sigma (the DMAIC problem-solving technique) is a valuable addition to our toolbox.

4.2 Objective

So why Operational Excellence? What exactly is it about, and what does it aim to achieve?

In summary, Operational Excellence describes the ability of an organisation to conduct its operations flawlessly. In the context of this website, the “operations” we are primarily interested in are the delivery of software solutions.

Origins of Operational Excellence

We have collected seven insightful quotes from leading figures in the business management and quality fields that we hope will give you a strong sense of what drives Operational Excellence.

Read More

4.3 Implementation Plan

Achieving Operational Excellence in software development requires us to follow the same three-step plan we outlined earlier (root cause analysis, finding creative solutions, and setting up governing processes).

As part of the root cause analysis, we need to figure out where the challenges originate, not just the symptoms we listed earlier.

Is it the people, the processes, the technology, or some combination of those three elements that make up the origin of delivery challenges?

The answer is a combination of all three. This statement is relatively accurate in most cases. Let’s have a closer look at each of these categories in turn.

4.3.1 People and the Organization’s Culture

At the core of every organization is a team of professionals, and this team is typically divided into management, technical, and administrative.

The team can be newly formed or might have a long-standing history. In the former’s case, the first formative months are decisive as this is when the group’s culture is created. In the latter’s case, the culture is already established, and its transformation in response to new threats can be particularly interesting to study.

---

---

In both cases, Operational Excellence cannot be attained without a relentless drive for continuous improvement by everybody, and maintaining constant momentum requires keeping the employees engaged and motivated.

Employees are usually motivated when:

1. Their ultimate goal as a group gives meaning to their efforts (such as benefiting society and not just improving shareholder profits).
2. They feel emotionally secure (as when their opinions are valued and their contributions appreciated).
3. They have the opportunity to learn and grow.

Perhaps one of the most insightful studies published on satisfaction was by the US psychologist Mihaly Csikszentmihalyi in 1961, in which he coined the term flow when discussing motivation.

The flow is experienced during:

1. Intense focus
2. On an activity that we choose
3. That is neither too far above nor below our skill levels
4. With clear objectives
5. And immediate rewards

---

When approaching the human element in organizations, it is always helpful to remember two things.

• First, hierarchies are complex systems and cannot be viewed as a simple mechanistic model. This characteristic of human groups means that making decisions, planning policies, and implementing strategies is not as easy as we would like it to be. Stong internal forces in complex systems render the predictions of the group’s behaviour, among other things, very challenging.

• Second, the organization’s mission, its ultimate goals, and the means to achieve them are questions of a fundamentally philosophical nature. So are the views on the nature of labour, careers, and employee satisfaction.

Frameworks like Six Sigma systematically ignore the human element when addressing organizational performance issues and focus more on the technical aspects.

The Toyota Production System is quite the opposite, with 14 principles spanning the whole spectrum of issues to be tackled.

4.3.2 Process Management

A production process is a set of instructions applied to raw input to produce an output with increased business value over the inputs. These processes must be managed for efficiency (maximized value over cost) and effectiveness (maximal impact).

production processes are usually set up in a specific context, and they, therefore, can become obsolete when the circumstances change. A process owner must monitor these processes and look for degeneration and lowered performance signs. She will then implement methods to improve or replace them.

There are three stages to managing production processes:

1. Design — During the process design phase, the process owner looks at the specific tools, infrastructure, and skills present in the team and designs processes fitted for this context.

1. Incremental Improvement — This is an ongoing activity that provides remedies to issues arising from a process failure. Issues of such nature occur when the process is not correctly implemented, followed, or is inherently flawed. For example, a bug in a system interface that makes it into production may result from process failure. In this situation, improved measures for quality assurance can be implemented.

1. Redesign — Process redesign is what you do when the processes become obsolete or require a significant modification to continue doing their job. For example, a systematic failure to deliver quality products signifies outdated frameworks or methodologies rather than simple processes. Moving to Agile or DevOps is one example.

The people at Toyota believe that following the right processes will always lead to the correct results. For them, it is preferable that you get incorrect results with the proper procedures over good results through flawed processes; you can only get lucky so many times.

4.3.3 Choosing the Right Technology

Going back to the Venn diagram at the top of this section, we see a tight connection between technology on the one hand and people and processes on the other.

Let’s explore these relationships through the following ideas:

• Technology as a Strategic Choice — The selection of the technology stack, tools, and infrastructure is a strategic decision for two reasons. First, changing once you acquire a few clients is extremely hard. Second, it directly influences many other strategic drivers, such as the ability to integrate your product with other technologies and keep up with innovation. Mainframe legacy applications are still running core banking applications at a considerable cost and limitation to the client.

• Technology and Processes — DevOps is a perfect example of the amalgamation of processes, technology, and tools. Choosing to offer Continuous Delivery through a DevOps model influences stack selection, solution architecture, software design, solution design, testing procedures (automation, quality assurance), technical debt management, deployment, and monitoring. A suitable choice of technology and compatible tools can make these more or less challenging.

• Technology and People — The technology you use, its maturity, ubiquity, and popularity will dictate the size of the available pool of resources from which you can choose. Needless to say that a larger pool is always preferable as it drives down the costs of resources and allows for hiring skilled and experienced talent ready to start delivering. Using legacy technology, despite its ubiquity, may not attract talent as people look for new challenges to broaden their horizons.

---

5. Core Principles of Operational Excellence in Software Development

We chose six principles to represent the core ideas of Operational Excellence in software development.

---

5.1 Principle 1: Eliminating 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? Let’s have a look at some examples.

5.1.1 Resistance to Change

Cultures are cognitive constructs deployed as defensive mechanisms that help groups cope with internal integration challenges as well as challenges posed by their environment.

Examples of internal challenges are the group’s cohesion, integration of new members or ideas, and replacing old ones.

External pressures can come from novel technologies, new customer requirements, or competitors. Any environmental change can be a threat (or opportunity) to the business. 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.

A culture that recognises and acknowledges change as a constant of nature and has the psychological safety to carry out cultural transformations is much better adapted for survival.

5.1.2 Stakeholder Management

Stakeholders are influential people in the organisation who can influence its progress or regression. Any business strategy is bound to fail if it does not adequately analyse and manage its Stakeholders.

It is also essential to recognise that organisational hierarchies are complex systems, making them difficult to control and predict.

Power distribution among the Stakeholders and their desire and ability to support/undermine your plans must be determined before the project kicks off and closely monitored during execution.

Implementing long-term strategic improvement plans (such as Agile or DevOps) will require patience as the results will not be immediately evident. Therefore, continuous support from the leadership over the plan’s lifecycle is vital.

5.1.3 Organizational Culture

Organisational culture determines how groups perceive time and space, dictates the reward and punishment system, and imposes group inclusion or exclusion rules.

For example, a culture that encourages hierarchical boundaries punishes failures and constantly seeks stability and equilibrium does not necessarily facilitate innovation or the adoption of new ideas.

The perception of time is another example of how Organisational culture governs the evolution of a group. A culture that focuses on the present may discourage spending time on experimentation and improvement if the results are not immediate.

Time management (beyond the to-do list) manifests in the dominant culture.

5.1.4 Continuous Learning and Self-Improvement

Engineers generally have a particular way of looking at things from their formal training. The world, in their views, can be modelled as a machine with inputs, outputs, and rules that govern its dynamics.

The natural world’s complexity, especially in organisational hierarchies, fades away due to the reductionist methods applied in the mechanistic model.

One way of combatting such tendencies is through studying philosophy, cultural anthropology, and organisational theory. This knowledge will inevitably lead to a radically different perception of the world, for example, using an informational paradigm instead of a mechanistic one.

A never-ending learning journey increases one’s awareness of their cognitive limitations, skewed perception of the world, and biased judgements.

This awareness is humbling and empowering, allowing them to make better decisions.

5.2 Principle 2: Process Management and Governance

The traditional discussions on productions processes typically revolve around the following questions:

• What defines an efficient production process?
• How can we measure, track, monitor, and improve the efficiency and effectiveness of production processes?
• Do we need to consider Organisational culture when setting up processes?
• What is the optimal breadth and depth that processes should cover?

Here are some suggestions to tackle these questions:

1. Industry best practices — Follow industry best practices when setting up your processes. Despite every project and organisation being unique in some aspect of their operations, some ground rules are robust and universal enough to remain efficient despite the variations. Standardise processes across all your teams, customers, and projects. It is easier to gauge the impact of any improvements you make and validate the results with standardisation. It’s also easier to switch your staff between teams and projects and onboard new members.

1. Accountability — Appoint a process owner who oversees process performance and improvement. Their job would be to investigate failures and decide whether they are systemic (because the process is inadequate or flawed) or user error (because someone failed to follow the guidelines).

1. Improvement — Great tools for process design, improvement, and redesign are available today (DMAIC, Six Sigma, Kaizen, Hansei). Attempt to solve issues with technical tools and evidence-based arguments instead of opinions and thoughts. This approach helps keep the discussion productive and non-personal.

1. Cultural blockers and resistance to change — Expect to face at least two types of blockers. Cultural blockers result from applying incompatible processes with the group’s culture. On the other hand, resistance to change is like a complex system, and hierarchical human groups are an example of such systems.

1. Coverage — The situations where an employee would be equipped with a written and well-defined process for handling them will always be limited. This limitation is due to the novelty and complexity of today’s software solutions and projects. Under these circumstances, employees must use common sense, expertise, and personal initiative to determine the best course of action.

5.3 Principle 3: Draw a Line Below Which Quality Does Not Go

When you have aggressive deadlines or your project is running out of time, there are only four things you can do:

1. Reduce the scope
2. Extend the deadline
3. Commit additional resources
4. Sacrifice quality

While the first two options are your best bets, and the third option is not always feasible, the fourth option (sacrificing software and testing quality) is what most people consider an easy way out.

There is a good explanation for why this can be appealing, and that’s because the results of sacrificing quality today will only be evident in the future. They will end up being someone else’s responsibility.

Sacrificing quality increases technical debt, creating a drag on your delivery capabilities. If left uncontrolled, it will transform your product from a lucrative asset to a liability.

In the long term, sacrificing quality will have detrimental and irreversible effects on your business. This organizational behavioural pattern of Eroding Goals was documented in Peter M. Senge’s book (1990) The Fifth Discipline.

But what if postponing the delivery, reducing the scope, or adding resources is impossible, and the only open option is to lower your quality standards?

The answer is: draw a line below which you don’t go. This threshold is where the risks will start to outweigh the benefits.

Here are some examples that help illustrate the point.

1. Postpone or decline non-strategic and non-profitable projects. Focusing on lucrative or strategic customers is vital, especially during a fast-growing period.

1. Reduce or eliminate non-essential activities, such as internal documentation, refactoring of old code, or daily meetings for smaller projects. Create different Project delivery guidelines depending on project size.

1. Carry over non-critical bugs into future releases. Manage your technical debt efficiently.

1. Make software drops frequently so the customer can start testing and uncovering issues as early as possible.

Ideally, it is best to avoid these situations altogether. You can do that with better planning, efficient processes and resource allocation, and being open and honest with your clients.

5.4 Principle 4: Implement Agile Processes Where Applicable

Once you separate the hype accumulated around Agile and DevOps, you will find that their adoption offers immediate and substantial gains.

Granted, Agile is not for every project. Still, we can safely assume that of the 12 principles it advocates and the various practices that have flourished around it, there is a universal and generic set that can be applied everywhere.

Let’s look at the most powerful of these principles and practices.

1. User Stories — User stories have brought the customer back to the forefront of the stage. Technical staff can easily get distracted from what is essential and valuable for the customer to what is purely a technical matter the customer is oblivious to.

1. Face-to-face interactions over documentation — In this day and age, where teams are operating across different continents and time zones, it is easy to get sucked into excessive dependency on online collaboration tools such as emails and instant messaging. In these virtual worlds, misunderstandings proliferate, and progress is unnecessarily slow.

1. Frequent iterations — In the pre-Agile world, customers would have to wait months before setting their eyes on the new software. It was often the case that what they got was substantially different from what they had. Agile tries to resolve this problem with frequent software drops that allow valuable Information to find its way back to the developers to adjust their requirements and design. The gains achieved are not small when we consider that unclear requirement is one of the top reasons for IT project failures.

1. Automation — Automation tools were not mature enough at Agile’s conception, but that has changed. Automation is a necessary tool for Agile to succeed, and it is impossible to release frequently and reliably without automating repetitive work, especially around building and testing.

1. Agile Architecture — Architecture is “what is important and hard to change”. So how does that work with Agile, where change is always welcome? Agile architecture is about shifting the question from What is the best design I can come up with? How can I design my architecture to make future changes feasible and easy to introduce?

5.5 Principle 5: Focus on Business Value

It can be deceptively easy to lose sight of what the customer genuinely needs and act upon what your product managers or technical staff think they need.

This diversion can happen when, for example, you measure your success based on how many new features you release instead of how many new customers you acquire.

It can also happen when you hand over the reins to your technical staff. They might, for example, decide to switch to new technology (at an immense cost and risk) without giving two hoots of whether the customer will notice any benefits.

Numerous other examples follow the same trend. Overengineering a feature hoping future customers would be easier to integrate is another common mistake.

It’s impossible to predict new customer trends and preferences, and you invest time extensively parametrizing a feature that will not work differently than today.

Here are some things you can do to stay focused on what customers need:

1. Create prototypes based on Minimum Viable Product (or MVPs) models when testing new ideas
2. Take the customer along the journey from project inception to end
3. Create a minimalistic feature for your first customer. Parametrize it for the next one.
4. Always subordinate the technology to the business
5. Separate and limit the research and Development (R&D) you would like to do.

5.6 Principle 6: Use Mature and Proven Technology to Serve Your Customers

Unless you work in high-tech mega-corporations like Google or Tesla or in Research and Development projects, you are much safer using mature and proven technology.

The benefits of such an approach are easy to spot:

• First, you can easily find resources with knowledge and expertise when the skillset you want is not residing in a small niche. The same applies to online help, support and documentation, which will be abundant for ubiquitous and mature technologies.

• Second, you can integrate easily with third-party systems and protocols when implementing industry-standard interfaces.

• Third, your products will be more stable and reliable as most of the bugs would have already been addressed.

• Finally, communication with customers and peers is smoother and less prone to misunderstandings when using a common dictionary of terms and definitions.

While the above might seem boring and perhaps not so cool, it is safe, dependable, and profitable. These properties are especially critical when your products are running critical business operations.

---

6. Practical Considerations for Operational Excellence

6.1 Introduction

Now that we have looked in sufficient depth at the core principles of Operational Excellence for software development, we will discuss some practical methods to get there.

But before we proceed, some words of caution are in order.

The enormous variety of tools and techniques available on the market can make a swift agreement and smooth adoption quite daunting.

However, the six principles of Operational Excellent can be used in the deliberation process to determine the most suitable toolset for your team, product, and operation mode.

Your team will need to understand why these specific tools have been deployed and how to use them to achieve a common objective.

6.2 The Software Development Lifecycle

The Software Development Lifecycle is the cornerstone of any discussion on Software Delivery.

In its most elaborate form, it consists of the seven following stages:

1. Planning — This stage is, historically, not part of the standard representation of the SDLC. However, we have decided to include it because, in our view, activities such as resource planning and Risk management, which naturally belong to this stage, directly impact the success or failure of your project. Resource planning, Time management, task prioritization, management of multiple workstreams (such as new projects and BAU), and resource allocation constitute the core activities of this stage.

1. Analysis — In this stage, architects and project managers collaborate to produce a high-level design, effort estimates, and project plan from stable business requirements. A Statement of Work (SoW) is then worked on and signed off by the relevant Stakeholders and project sponsors before any implementation work commences.

1. Design — During the design stage, a detailed solution design is generated and, in some cases, signed off by the customer. In a previous article, we have explained in great detail the importance of having a solution design. The low-level design might necessitate a round of requirement gathering and technical Decision-making.

1. Development — Developers, testers, and DevOps engineers add business value to your product in the development stage by coding new features, adding functional test cases, and keeping your CI/CD infrastructures on par with the delivery requirements.

1. Verification and Validation — This stage is more commonly referred to as software testing or quality assurance. Different forms of software testing are applied to ensure the product stands up to the customer’s expectations. Verification ensures that the specifications are met, while validation ensures that the requirements of the concept of operations are satisfied. Ideally, you want as much automation as possible for maximum efficiency.

1. Deployment — Deployment used to be a short and rare event, but this has significantly changed with requirements for Continuous Delivery. Megacorporations can deploy thousands of small changes every year, whereas the traditional way was just a few big ones.

1. Support — Excellent customer support is the next thing clients desire after a stable and working solution. Meeting SLAs through exceptional Time management, resource allocation, and ticket prioritization are the cornerstones of an efficient help desk.

The table below summarises the techniques available today as part of the standard toolkit for businesses in the software development space.

	Stage	Techniques to Achieve the Best Results
1	Planning	While planning and allocating resources, delivery managers ideally aim for the below targets: A) To create self-sufficient teams as these can perform better if they do not need to go outside their group for approval or advice. B) The second target is to keep the group together during future projects (as much as possible) to leverage their shared experiences and mature relationships. C) Balance the load on your resources so that projects can be delivered without sacrificing quality when trying to meet deadlines and avoid idling when work is scarce. D) Manage technical risks throughout the implementation.
2	Analysis	You need to satisfy two criteria for this stage to be successful. A) First, clarify and document all business requirements. Remember, unclear requirements is one of the top reasons for IT project failures. B) Second, get the estimations right so that the project remains profitable and customer expectations remain well managed.
3	Solution Design	solution design is completed at multiple levels for different purposes. Architecture determines the solution concept and fixes some of its key parameters. A high-level design (HLD) gives a bird’s eye view of the solution for major Stakeholders, while a low-level solution design (LLD) is a great place to document all the implementation details.
4	Development	Successful developers follow a unique coding style guide, look after the system’s architecture, and use Test-Driven Development (TDD) as the backbone of their development processes. Development should also investigate the way it uses Unit Tests to understand the benefits and pitfalls.
5	Testing	software testing is always a great place to start when looking for ways to optimize your delivery. Two significant factors immediately come to mind. The first is automation, and the second is Test-Driven Development. Test automation significantly improves your delivery capabilities and boots the quality of your testing. Without automation, Agile and DevOps are very difficult, if not impossible, to implement. Automating repetitive testing activities also gives your QA staff more opportunities for growth. Test-Driven Development or TDD is an excellent tool for streamlining your activities and allowing developers and testers to work in parallel when implemented with automation and a modified version of unit testing.
6	Deployment	Deployment to production has moved to a new level with Continuous Delivery, automated deployment, and frequent releases. The infrastructure that supports automated and advanced deployment methods (both tools and processes) falls under DevOps. DevOps practices allow the fusion of development and operations in a single, streamlined process.
7	Support	Triage, Time management, SLA requirements, and customer satisfaction are the hallmark of customer support.

6.3 Standardizing Processes

Employees sometimes view standardization as a means for curbing creativity, stifling innovation, limiting personal initiatives, and imposing an alien Organizational culture.

While that statement may not be entirely untrue, it is still essential to standardize your production processes across the organization to guarantee minimum variations in outcomes and ensure improvements are applied across the board.

What is essential in the context of standardization is that you pick one method and use it consistently. You can subject it later on to continuous improvement for optimal results.

If you choose to create unique methods for your organization, there will probably be significant implications. While this may work better for you in the long run, its initial cost can be pretty high.

Generally speaking, and unless you have the size and influence of Google or Tesla, it is recommended that you communicate via a language that everybody can understand.

6.4 Reducing Rework and Non-Value Adding Tasks

Taiichi Ohno implemented the following technique for eliminating waste on the shop floor of the Toyota production plants to an astounding degree of perfection.

The process is as follows:

	Stage	Tasks
1	Observation	Spend as much time as possible observing the production process, preferably with experienced staff.
2	Make a List	List all the repetitive steps required to complete a particular task.
3	Mapping	Find out which ones produce value and which ones don’t.
4	Identify Non-Value-Adding Activities	Work with the team members to identify non-value-adding steps such as overhead, rework, or enabling activities.
5	Eliminate Non-Value-Adding Activities	Enhance internal processes in collaboration with team members to eliminate all forms of waste

This five-step process should not be confused with scientific management (a.k.a. Taylorism). Scientific management, proposed by Frederick Taylor in the 1880s, was archaic and counter-productive.

This method is a radical deviation from statistical analysis of data collected remotely and analysed behind a comfortable desk. Its advantages include gathering firsthand Information as seen through experienced eyes. This method is known in Toyota as Genchi Genbutsu.

6.5 Structuring Your Team for Performance

Although it would not make much sense to have a prescription for team size and fixed profiles for its members, some rules-of-thumb might work in most situations.

Martin Fowler, one of the 17 founders of Agile, describes the most performant team as follows:

---

---

Eric Schmidt and Jonathan Rosenberg published a book in 2014 called How Google Works. In this book, they state that the maximum number of people that a single person can efficiently manage is around seven.

---

---

In the same book How Google Works, Google focuses on getting teams to work in smaller spaces, without physical barriers, and encourages relationship building. They also have a specific recruitment process that ensures only the right people get on board.

---

---

Let’s now turn to the Agile manifesto for more inspiration.

---

---

---

Team Building Exercises

It is undeniable that kayaking with the team always positively impacts the mood. However, I am convinced that team-building exercises alone are never sufficient (or even remotely relevant) to improve the team’s performance.

Emotionally charged traumatic experiences dwarf the positive ones; unfortunately, that’s how our brains operate.

Vital as it may be, such team-building exercises should only be an addendum to the real ones:

1. Valuing employees’ contributions
2. Maintaining a safe work environment
3. Keeping morale high
4. Offering them the opportunity to grow

6.6 Tracking Progress and Performance

The concepts and ideas that will be the subject of this section are probably not the most popular as they go against some of the more modern management styles that have been trending for a while.

Have a look at the below table to compare and contrast.

Traditional Method	Proposed Method
Heavily dependent on lengthy reports and second-hand Information to understand the situation on the ground.	Go and see for yourself. Use your long experience and trained eyes to understand the processes and spot anomalies.
Uses complex statistics and KPIs such as Six Sigma, Taylor’s Scientific management methods to monitor and improve performance.	Robust, measurable, relevant, and simple KPIs focus more on outcomes than results.
Unfounded optimism and positive attitude. Ignore negative indicators.	Use visual aids to signal quality problems. Stop and fix the problem before it snowballs.
Treat the symptoms as opposed to the root cause. Has a “not my problem” attitude.	Ask “Why” five times until you get to the root cause of the problem. Openly discuss any issue and fix it.

6.7 Continuous Improvement

As the organization grows and pressure for faster and better deliveries increases, people will find less time for improving what they do. In his timeless classic The 7 Habits of Highly Effective People, Stephen Covey describes this phenomenon as “sharpening the saw”.

---

---

Even if individual initiatives were made here and there, these would continue to be local, spurious improvements and cease to suffice.

To maintain Software Delivery in top shape, continuous improvement methods need to be ingrained in the DNA of the system. In addition to that, they also need to be amalgamated into a single, system-wide activity.

Scrum uses retrospectives after each sprint. The double activity of Kaizen and Hansei is slightly different, but the objective is the same.

Such exercises are important for morale; they carry a positive message to the staff that the company is committed to continuous improvement of its people and processes, and it’s not just about the present but also the future.

6.8 Responding to Environmental Changes

6.8.1 Technology Lifetimes

The pace at which software or any other technology-based industry changes is breathtaking. Sometimes, that leaves us with a feeling of helplessness that’s difficult to ignore.

The question then becomes, how do we, as professionals in the software industry, keep producing premium-quality products despite the ever-changing nature of technology, tools, techniques, and methods that come with it?

It might help to look at the software industry’s evolution not as a homogenous, monolithic entity but as four major sub-fields, each characterised by a predetermined lifetime.

Subfield	Description	Lifetime
Tools	Programming languages, frameworks, database engines.	< 10 years
Delivery Methods, Customer Preferences	Project management techniques, Project delivery methodologies (Agile, Waterfall, DevOps), business needs (eCommerce, payment methods, IoT, smartwatches, cloud technology…)	10-20 years
Tech Concepts	Personal computers, quantum computing, digitization, internet, smartphones, AI…)	20-30 years
business management	Taylorism, The Toyota Way, Lean Manufacturing, Six Sigma, Operational Excellence	30+ years

The lifetime in this context does not represent an expiration but the average duration before a newer concept arises and challenges the status quo.

Like any other field in science or technology, historical progress seems to happen in jumps, followed by plateaus, rather than monotonic, incremental improvement.

6.8.2 Responding to Disruptions

What would be an adequate response from your organization for the above four disruption levels? Below are some thoughts.

Because Level 4 fields, such as Operational Excellence, sit at the top of the hierarchy as one of the most stable concepts, ideas, and mental constructs of the lot, it makes sense to thoroughly consider it and invest time in applying and mastering it.

---

7. Final Words

software development is a field where technologies, disciplines, practices, and methodologies abound, and discussions on which to adopt can quickly turn into a religious war.

This article proposes a few principles that could help you make the right choices and firmly anchor your decisions on solid ground. We hope that, in that sense, it has achieved its objective.

I believe that doing something great is always gratifying and provides a deep self-satisfaction. That’s why sculptures, composers, artisans, and maybe software developers do what they do.

Success also demands technical expertise and extensive know-how, and both come within reach if the principles articulated earlier are closely followed.

Passion, mastery of skills, and in-depth knowledge of human nature are all you need to succeed.

---

8. References

• The Toyota Way — Jeffrey K. Liker
• Strategic Management and Organisational Dynamics (4th edition) — Ralph Stacey
• Organizational Culture and Leadership — 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.

---

9. Featured Articles