Lean Thinking

Don't Panic I.T. Solutions - Items filtered by date: October 2016
Published in Agile

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.

Published in Agile

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.


« October 2016 »
Mon Tue Wed Thu Fri Sat Sun
          1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30