Stein-Otto Svorstøl

Solving complex problems as fast as possible

As agile methods for software development has been quite widely adopted, the fact that hitting the specification on software is hard, also has been generally accepted. It has been hard, but it is now quite widely accepted that smaller iterations and getting user feedback fast, is crucial to building software that covers actual needs. This means better software, and better products. This trend means that we are starting to recognize that both product and software development are in of itself are complex problems 1, where the solution will be emerging over time. It cannot be defined up fornt. It will also be improved over time, through discovery. This means that it actually not a about the product, nor the software. It is not about business, or earning money. It is about solving complex problems, and doing it faster than anyone else. How?

What enables us to solve complex problems?

To build “business agility”, I argue that one must build an organizations capability to solve problems, more importantly complex ones. Most problems will be:

Most situations and decisions in organizations are complex because some major change—a bad quarter, a shift in management, a merger or acquisition—introduces unpredictability and flux. In this domain, we can understand why things happen only in retrospect. (Snowden and Boone, here)

Snowden and Boone writes about this type of problems to adress how a leader might apporach them. As autonomy increases, more decisions are done everywhere in the organization. I.e. more problems are solved further “down” in the hierarchy. How does not one approach such problems, and make the solution as good as it can? An example approach can be found here. It reads:

  1. Explore to learn about the problem, as they require more creativity and innovative thinking skills
  2. Develop a theory and experiment to gather more knowledge
  3. Experimentation to discover patterns and gain more knowledge
  4. Repeat as necessary, with the goal of moving your problem into another category
  5. Execute and evaluate, following the Plan, Do, Check, Act cycle

The premise here is that you ar e able to explore the problem thinking cratlively about it. You must develop theories and experiment. How might an organizatino best enable all teams to do those things?

Real Cross-Functional Teams

What is capabilities does a team need to solve a complex problem?

  1. First, be able to see all parts of the problem they are trying to solve
  2. Second, see many possible experiments that might shed light on the prolem and the solution they might find
  3. Third, be able to act upon experiemnt, and roll out new changes

Most teams, either in software development or otherwise, address one capabilitiy. A software delivery team 2 rolls out changes, while a business/strategy team is trying to see the whole of a high level problem.

To adress all three, the cross-functional cannot be cross-functional in the sense that it knows about devops, frontend/backend, infrastructure or even designing a UX. They must be capable of things like

  1. Developing the product, including building the tech and UX, and data pipelines to improve it
  2. Developing the product strategy, including selecting the next feature to build, users to build for, how to spend time and not spent time
  3. And building the market strategy
  4. .. And propably many other things that I with my background cannot even think of. And that is sort of my point.

Bring in people, iterate over the whole problem

The recipe for building business agility seems to be the same as for building software agility. One could even argue that they are the exact same thing. And, it seems clear that the path to making value faster, is through solving the complex problems faster. This is, in turn, making sure that one has knowledge in the team that can adress the whole problem.

We need to stop placing “a representative for the business” as a Product Owner in the development team. This goes for design, UX and marketing as well, and all the other areas we miss. Creating flow is making sure our problems are solved fast, and the problems are about more than software. Building organizations without silos is hard. 3 Can we come together, and try harder?


  1. As defined in the Cynefin Framework ↩︎

  2. A nickname for an organization based on feature teams ↩︎

  3. Reserach tells us that it is really hard to build cross-functionl teams. Or it tells us that doing it in just a part of the business is hard. https://hbr.org/2015/06/75-of-cross-functional-teams-are-dysfunctional ↩︎