Simple, Complicated and Complex

Any problem or piece of work, including running a business and software development, can be considered in terms of its complexity. Problems range from the simple to the complicated and complex.
Through our work with many different clients in different market sectors we’ve seen significant diversity in terms of organizations, processes, cultures and software concerns. Approaching the business of doing software development holistically means we have to consider all of this variation, one-size-fits-all simply isn’t appropriate for such dramatically different work.
Complexity is one of the most significant factors. Many organizations will have work at multiple levels of complexity as part of their portfolio, Holistic Software Development, and the hybrid dynamic model in particular, accommodate this diversity.
Simple work is that which is well understood. Risk is low because we understand the problem and the solution is obvious to everyone involves. In these cases, traditional forward planning and managing to reduce variance can work well as long as there is rapid enough feedback to deal with disruptive change. Continuous flow models and/or service management are well suited to this work.
Complicated work requires analysis to understand the connection between cause and effect, or required inputs and outputs. Investigation and some creative thinking is necessary to understand a problem and then propose a solution. Iterative models are well suited to this work.
Complicated endeavors are built upon specialist knowledge and can’t be done by most people. They might take a lot of time and skill to do but are ultimately predictable processes. For example, a recursive sorting algorithm in computer programming is complicated, it involves variables, loops and recursion it’s not easy for everyone to understand but it’s very predictable. Building a car engine is complicated.
Complex work involves many interdependent integrating parts that interact in a number of ways resulting in unpredictable, emergent outcomes. The relationship between cause and effect isn’t predictable, undermining planningestimation and analysis and design practices. Organic networks, outcome orientated teams and high complexity requirements and architecture practices, discussed throughput the HSD site, are used for this kind of work.
Complex endeavors are those which have many influencing parts and events whose interactions are not predictable. Running a large software project is complex, it has people (who are complex) interacting in unpredictable ways based on events and stimuli we can’t predict. Driving a car is complex.
Complicated is easy if you can get the right skills lined up. Complex is always hard.
High Complexity Architecture
High complexity architecture involves applying architecture practices and principles to business and technical problems involving many interdependent integrating parts that interact in a number of ways resulting in unpredictable, emergent outcomes.
Complexity has been studied scientifically and one of the best applications of complexity theory to management and business, and therefore software development, is the Cynefin model. We recommend using the Cynefin model to categorize complexity and inform organizations on how to respond. We use the H-model and Hybrid Dynamic Model to integrate those different approaches within a single organization.
The Cynefin model also identifies “Chaotic” work in which there is no relationship between cause and effect. In these situations, it advises acting and observing the outcomes to determine new practices. Business and technical situations can seem Chaotic when they’re poorly understood, in which case HSD can help to make sense of the complexity, but if the situation is genuinely chaotic then structure around practices, people and technology is unlikely to help – even a flexible multi-modal model like HSD.
Failure is inherent in high complexity work, but is actually common in most software development work. This is not because the development itself is complex but because the people network, interacting with business pressures and processes is a complex system. Addressing the complexity of the People issues is something we cover in the People view, and why we recommend “pulling” towards Business Value throughout Holistic Software Development as a way of managing emergent outcomes rather than trying to control and plan every detail of interaction.
We consider software development, especially in a team-of-teams context, to be a complex problem. At an enterprise level, it can be a high complexity problem, this is why simple scaling of team practices (a “simple” and “complicated” approach) doesn’t work. The ways-of-working complexity isn’t in repeating planning practices at different organizational layers, it’s in the dynamic, changing interaction between teams and products.
Recognizing complexity is difficult. Understanding when it’s coming, and why previously successful approaches are actually damaging is often missed. We’ve seen a number of well-intentioned dysfunctional projects and programmes fail as a result. A natural, but very damaging, response we’ve seen from some business leaders, architects and managers is to try and control complexity. Trying to prevent change, to make things more stable can be an attractive option to someone feeling a little overwhelmed by complexity. Unfortunately, this approach tends to guarantee failure by preventing teams from reacting to disruption and change, unable to learn from their experiments. The only approach to dealing with high complexity is to acknowledge we don’t understand everything and be not just accepting, but welcoming of change.
Experimentation, whether failure or success, means we’re learning something.