Lean Thinking

In my last post on architecture, I touched on the need for design simplicity. Simplicity is one of the 12 agile principles:

Simplicity – the art of maximising the amount of work not done – is essential.

So it must be important. But how do we get there? Why, when simplicity is so essential, do we keep developing complexity? Antoine de Saint-Exupére gives us a clue -

Perfection in design is achieved not when there is nothing more to add, but when there is nothing more to take away.

When we do design, we tend to take an additive approach. We look at a problem and add features until we consider the problem solved. The problem is that we tend to get carried away and add way more features than we need. We look at the initial problem and in solving that one, we lump together a bunch of related problems and solve those as well. We also have a habit of solving a whole bunch of problems that aren't actually problems yet but might be one day, just in case.

Good design, great design, is the art of looking at a solution and paring it down the the base essentials - the minimum we need to solve the problem. Let's look at a few examples of great design. The first one has been around for a very, very long time.

I have written about agile architecture before, but since I have been working with a group of architects recently (the kind that build software, not the kind that build buildings), I figured it's time to revisit the topic. The question that kept on coming up was "how do you do proper architecture in agile?". It's a good question. Agile is all about just in time rather than up front planning and traditional architecture looks a heck of a lot like a type of upfront planning. We even have a special term for what we want in agile environments - emergent architecture. Architecture that emerges just in time from the team. The problem is that while emergent architecture works fine in some problem domains, there are others where emergent architecture just isn't enough. If you're designing banking systems, or safety critical healthcare systems, or even just regular old big complex systems, relying on emergent architecture simply doesn't cut it. You need some level of upfront thinking (or at least longer term than a sprint or two ahead) to make sure your product doesn't fall in a heap.

Some of the scaled frameworks recognise this and introduce the concept of "intentional architecture" for the upfront stuff. The amount of intentional vs emergent architecture you do is a function of the type of system you are building. That's great but it still doesn't tell us much about how to do architecture (emergent, intentional or otherwise) in an agile environment. Before we look at how to do architecture, we should start by understanding what architecture is, and more specifically, what it isn't. Let me start by saying something really important. Remember this, there will be a test later - architecture is not the same as design. Many organisations, actually all organisations that I have worked for so far, have been getting architecture wrong. In these organisations, the architects didn't actually do any architecture. They produced detailed design documents. That's design. Not architecture. Detailed design absolutely should not be done up front.

We have now covered six principles -They are built around small, self-organising teams

The team has a clear vision of what they are doing and where they fit into the bigger picture

The team has a well defined backlog of work

There is a content authority responsible for making sure decisions are made quickly

There is a clear bidirectional service agreement between the team and the rest of the organisation

There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.

At this point we have everything we need to enable a team to operate in a really agile way. The team doesn't need anything else. So why are there seven principles?

The seventh principle isn't a team principle. It's a scaling principle. Very few organisations are able to deliver real value with a single team so the last principle kicks in when you don't have just one team but a team of teams, or a hierachy of teams all working together to deliver value. The first 6 principles define how you should set up your teams, the seventh principle defines how you should link them together -

The organisation should be self similar at scale

There are two ways an organisation can handle scale. They can do what most organisations do and add extra complexity to their processes to handle the extra complexity of scale or they can develop a simple pattern (like teams operating under the first 6 principles) that works and iterate that in a self similar way to operate at scale. Add complexity through extra processes or iterate simplicity through self similarity.

So, where are we now? Over the last few weeks we have looked at the first 5 of my agile principles -

They are built around small, self organising teams

The team has a clear vision of what they are doing and where they fit into the bigger picture

The team has a well defined backlog of work

There is a content authority responsible for making sure decisions are made quickly

There is a clear bidirectional service agreement between the team and the rest of the organisation

We have a pretty good setup going now - we have an efficient delivery engine (the team), a destination (the vision), a route (the backlog), a navigator (the content authority) and last time we added a clear service agreement, so the team and organisation know what's expected of each other. With this sort of structure they can really start to get things done. But there is still one more thing to add to make the team really high performing - the ability to improve.

This is where my sixth principle comes in -

There is a fast feedback loop that allows the team and organisation to optimise both the process and the product.