Agile Architecture Revisited

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.

AgilityDave Martin18 October 2016architectureComment

Principles Part 5 - Self Similarity

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?

AgilityDave Martin4 October 2016principlesComment

Principles Part 4 - Feedback Loops

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.

AgilityDave Martin20 September 2016principles, feedbackComment

Principles Part 3 - Service Agreement

When we left our hypothetical team last post, they had the first 4 of my principles applied -

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

They have their powerful delivery engine (the team), they have their destination in mind (the vision), they have their route planned (the backlog) and they have someone looking head and changing the route (and even the destination) if things change (the content authority). Is that all they need?

AgilityDave Martin6 September 2016principlesComment

Principles Part 2 - Content Authority

Last post we looked at the first three 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 delivers a regular flow of value via a well-defined backlog of work

This gives us an effective delivery engine (the team) with a clear destination in mind (the vision) and a clear route to get there (the backlog). All good? Not quite. If nothing was ever going to change, this would be all we need, but we know this isn't the case. When doing development work, and no matter what it is we are developing, we generally aren't travelling on well marked highways. Most development is, at best, navigating though a confusing maze of back streets and at worst, blazing our own trail through virgin country of varying degrees of ruggedness.

AgilityDave Martin16 August 2016principlesComment

Principles Part 1 - Teams, Visions and Values

Last post I put forward 7 principles that I think every agile methodology should have. In this post, I'll be explaining (hopefully) what each of those principles means and why I think it is important. To recap, the six principles for a successful methodology are -

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 delivers a regular flow of value via 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.
The methodology is self-similar at scale.

So, let's start looking at these in more detail.

AgilityDave Martin2 August 2016principles, vision, purposeComment

Agile First Principles

Recently I put out a post calling for the agile community to stop focusing so much on executing methodologies and return to a principles based approach. To stop doing scrum, or SAFe or Less or whatever and start being agile. That has generated a small amount of comment, mostly people asking me what I mean by a principles based approach and what I think those principles are. Here is my attempt to explain both.

To illustrate what I mean by a principles based approach, I will continue with the analogy of cooking because it's my other favourite activity and because it seemed to strike a chord with those that read my last post on this. There are, as I said before (and to massively generalise), two types of cook, those that follow recipes and those that don't. Recipe following cooks can be great cooks but if they want their chocolate cake to be a little more chocolatey, they need to look for a new recipe. They can't adjust it themselves. Cooks that don't use recipes tend to work from a set of fundamental principles - this flavour goes well with that flavour, adding extra dry ingredients means you need to add extra wet ingredients, bacon makes everything taste better, and so on. So when they want a more chocolatey chocolate cake, they can adjust (add more cocoa and some extra milk to balance). When the cake collapses coming out of the oven, they can diagnose why and adjust so it works next time. When they have a recipe for chocolate cake but don't have any chocolate they can improvise a vanilla cake from the same recipe.

AgilityDave Martin19 July 2016principlesComment

Inspect And Block, Or Consult And Enable?

Often in large organisations we have to deal with groups with names like "legal" or "compliance" or to use an example from my days in the healthcare software industry "patient safety". To a project manager, the function of these groups seems to be to throw up obstacles and prevent getting things done. These groups tend to appear out of the woodwork near the end of a project, inspect everything that has been produced, identify a bunch of problems and then block release until they are all fixed. The problem of course is that at the end of a project, everything has already been built so changing things is hard and expensive. There is also a very good chance that the money is starting to run out so these changes would push the project well over budget. Throw in a rapidly approaching release date and a team already stressed with defects and last minute changes, and it's no wonder project managers view these groups with dread.

Of course, these teams are not just a bureaucratic hurdle to be jumped. They do an important job. The organisation could be in serious trouble if they release anything that is illegal or is not in line with whatever regulations they are under. Groups like legal and compliance have the skills and knowledge to make sure that doesn't happen. In the healthcare company I worked for, patient safety was responsible for exactly that - the safety of the patients whose treatment was administered through the software we wrote. They were trained medical professionals, with years of hospital experience, who assessed what we produced and made sure that in the stressful, overworked environment of a typical hospital, that the software could be used without the risk of accidentally administering the wrong drug or the wrong dose or operating on the wrong leg (or even wrong patient) or anything like that. That's a pretty important thing to do. We knew how valuable it was. We still hated dealing with them though. Product managers would jump through hoops to get their product classified "non-therapeutic" so they could avoid a safety review. The downside of course is that there was no safety review. If only there was a way that we could get the value that these groups provide without all the downsides.

AgilityDave Martin5 July 2016organisational change, patternsComment

Changing culture is easy - just change what you measure

As an agile coach I am always pushing for cultural change. That's what agile is really - it's not a delivery mechanism, it's a fundamental change in the culture of an organisation. What do we mean by organisational culture? There are many definitions but the one that I like is that culture is a shared understanding of values. It's the understanding everyone has of what the organisation thinks is important. Culture drives behaviour - people will seek to maximise what is considered important in the culture and will behave in ways that do that.

The problem of course is that, as anyone will tell you, cultural change is hard. CEOs are tasked with changing culture and spend years failing to do it. People say that the only way to change culture is to change all the people. Or that cultural change only happens when a generation of employees retire. I don't agree. Cultural change is really easy. You just need to let people know what the organisation values. "Hang on", I hear you say, "Just wait a minute. Organisations have been putting out statements for years about what they want in their new culture. People can often quote chapter and verse from the CEO's latest values statement. Millions are spent on flashy communications. And nothing changes."

Leadership, AgilityDave Martin21 June 2016culture, organisational changeComment