8 Rules of Agile Architecture

Wow, the title sounds quite bombastic, doesn’t it? And I sound quite full of myself, don’t I? Well…perhaps I am. Nevertheless, I want to go on record with some simple and pragmatic advice for agile organizations and teams when they’re trying to sort out how architecture fits in agile contexts.

• 1. Allow Architecture to Emerge
• 2. A Picture is Worth…
• 3. Treat it Like a Product
• 4. Everyone is an Architect and Everyone Owns the Architecture
• 5. Keep it Simple and Connect to the Customer
• 6. Prototype for Learning & Discovery
• 7. Demo your Architecture
• 8. Change is Constant; Refactoring Everything

In no particular order, here are my guidelines:

I know you’ve heard this before, but it’s really, really important. The difference is moving from traditional architecture, which:

• Performs Big Design Up Front (BDUF), aka Big Bang;
• Develops a complete architectural concept before coding begins;
• Approaches construction horizontally, with delayed layer integration.

To fostering agile architectures, which: 

• Emerge, delivering a bit of design, then proving/learning/coding and redesign;
• Define some architectural aspects (runway) and then code it to learn if it “works”;
• Constructing the application in vertical slices that are integrated together immediately.

There is a caution here around the balance between architectural look-ahead and rework. If you don’t do any look-ahead, you’ll constantly rework everything, which will slow you down (or stop you entirely). But, if you look-ahead completely without experimenting and implementing your ideas, you’ll get stuck making it work. Again, slowing down to stopping.

So, there is a trick to balancing between the two that is usually relative to the technical and business context you’re in. If you’re focusing on it, you’ll find the right look-ahead balance for your context and teams.

Maybe it’s just me, but most of the agile teams I encounter develop little to no diagrams or high-level views of the architecture they’re developing. Instead, they allude to being agile, where architectural documentation is unnecessary. Implying that, you simply collaborate on the code and magic (emergent architecture) occurs.

One factor influencing this is a fundamental misunderstanding of the Agile Manifesto point – Working Software over Comprehensive Documentation. Another factor is that these teams have historically written large-scale documents that have not served them well. So, they’re scarred by those wasted efforts.

Now I am clearly an old school developer who doesn’t feel that documentation is inherently bad. Particularly high-level, big picture elements that show teams where they’re going from an architectural perspective.

A roadmap if you will.

I often bring this mindset into my agile coaching. I feel that agile teams need to document their designs and their architectures, including:

• Having a Big Picture of your architectural intentions on a whiteboard (virtual if you can). And keep it simple.
•  
• Keeping design snippets on a wiki or within your user story definitions.
• Having the mindset that whatever you document, work hard to keep it simple, up-to-date, and relevant to your teams. The final arbiter of the completeness of your documentation is the team.
• Understanding the KEY to architecture is the same key as the user story. It’s whether the team is communicating, collaborating, and interacting with the documentation. The conversations are the most important thing.

 

I’ve always liked it when an organization develops a backlog of architecture stories they wish to integrate into their product. The stories are usually different than functional or feature-driven work, in that they might be below the surface or infrastructurally based. But, they are important to articulate so that they gain visibility.

And by putting them in a backlog, you start to do things Product Owners typically do:

• You groom or refine these stories with the team.
• You define acceptance criteria that capture the essence of what “done” is for each story.
• You discuss the level of effort (points) associated with each story, including testing.
• You slice the stories (decomposing them) along execution boundaries.
• You discuss the strategy of how individual stories are implemented to meet an overarching release or architectural goal.
• You have value-based discussions, talking about the customer/business value of each story. Including the why behind each and the customer impact.

One important aspect of this is the experimentation or exploration part. For example, if you had a feature idea you thought a customer would value, you might:

• Define a quick MVP;
• Whip up a quick/cheap prototype;
• Show it to some customer for feedback;
• Make adjustments;
• Analyze product-ready feature level of effort and costs,

Before making a final implementation decision. If the feedback wasn’t positive, you’d potentially pivot in another direction.

I want that same level of thoughtful planning to occur for architecture as it does for features. And as with features, everyone becomes a stakeholder in the architecture (as well as the features). That means they understand the motivation, agree with the business case/investment, understand the impact/value and sign-off when it’s done.

This is the no Glass House rule. I want everyone thinking of:

• Design
• Testability
• Performance
• Security
• UX
• Simplicity
• Maintainability

Sure, some have much more experience in these areas than others. But everyone can put on the hat of architecture and focus on this thinking throughout their work.

Another part of this is holding the team (each other) accountable for building wonderfully architected products. Products that will stand the test of time and wow the customer with their intuitiveness, robustness, and reliability.

I worked at a company called iContact from 2012 – 2015. One of the things we did was canvas our customers to determine what stood out in their minds since we’d moved to agile. Since we were doing quarterly releases (release train model) and had more than tripled our feature productivity, you would have thought our speed and more features would have been top of their minds.

It was up there. But, the number one thing that stood out to them was the overall quality improvement of our products and how we were better connecting with their needs (UX focus).

In other words, architecture (quality, robustness, simplicity) mattered to our customers the most. And it’s what grabbed their attention as we continued to evolve and deploy our products.

5. Keep it Simple and Connect to the Customer

This rule is near and dear to my heart. Why might you ask? Because I really like complexity. I like engineering complex solutions to simple… complex customer problems. And it’s also comfortable for me to fall into that over-engineering, gold-plating, doing-more-than-is-required mindset.

 

Why? Because I can. And I’m an engineer. The more complex and elegant the solution, the better I feel about my capabilities. It makes me smile.

I think lots of engineers are like me. But it’s the wrong approach. And it’s often easier than thinking really deeply about the problem or challenge and then finding the simplest possible thing that could satisfy your customer. One way to combat this is to focus on MVP-like language. Words like minimum and viable can more narrowly focus our efforts. That, and including your customer in these discussions.

Another important activity is sitting down with your customer(s) to understand the WHY behind requests. People often describe this as a challenge, in that they (the customers) are too busy to explain their needs. I’d argue that if they’re not too busy to spend corporate funds on solutions, then they shouldn’t be too busy to ensure that those solutions meet their needs. Whether they’re internal customers, external customers, or both, it’s often more of an excuse than a reality.

If appropriate, including UX activity is an important part of the discovery and design process. Through many years of experience working to fit UX into agile teams, far too often, I see groups doing either too little or too much UX. That is, they either skip it and dive into solutioning far too soon, or they go into an analysis-paralysis state and do UX for months without truly engaging teams and customers directly.

There is also one important part of customer connection. Can you guess it?

Yes, that’s right. It’s ensuing that they get into the demo’s and verify/sign-off on the solutions the teams are providing. This notion of demonstration, feedback, discovery, and ultimate acceptance is crucial for closing the delivery loop. That and the customers sticking to their word when it comes to sign-off.

One of the first things I’d like everyone to acknowledge in software architecture is we often (most of the time) haven’t done what we’re being asked to do before. That is:

• We’re clueless about what the design approach should look like
• We’re clueless about the tools and techniques we’ll use
• We’re clueless about the environmental considerations
• We don’t understand the UX implications, and what the customer truly needs
• We’re clueless about the performance implications
• We’re clueless about how to test our solutions
• And, we’re clueless about how long it will take to complete our work

I think the most important acknowledgment or statement we should all agree to, early on, in ANY architectural discussion is…

we don’t know

Out of this level of openness and honesty, comes the need for prototyping, discovery, and learning. It’s hard to do that if we don’t all look each other in the eyes and say – we don’t know, let’s find out. Once we do, the focus needs to turn to learning, which is actually something we all can do. Here are some techniques for approaching this learning:

1. Working code is the great leveler. So, as much as possible, we should be pulling prototype code together to learn. The prototypes should be cheap and fast. They’re not production code. Instead, they’re learning code. Experimentation code. This includes paper prototypes and such from a UX perspective.
2. User Story spikes are the way to capture these activities. Write a spike for each and every (major) learning activity. And take the time to clarify the acceptance criteria for each. In other words, what key things will we deliver in order to fully understand this aspect of the architecture?
3. SAFe has the notion of architectural runway or architectural look-ahead. So, not only do we need to capture spikes and write code, we need to forecast it enough in advance so that we’re ahead of our product development needs.

Consider working code your ultimate picture of your architecture. Aspire to code over studying, documenting, and yakking about the architecture. Instead, build prototypes as soon as possible.

If you listen to the Meta-cast where Josh and I established these rules, you’ll hear us disagree on this point. I feel like it’s really important to (try) and demo everything we build – including architecture. However, Josh’s experience (and feelings) are inherently the opposite.

In a nutshell, Josh’s experience is that most stakeholders (executives, customers, managers/leaders) don’t really care about your architectural, infrastructural, automation, and other plumbing-oriented types of work. They care about customer-facing features (MVP’s) and things they can see, understand, and charge for.

They view demonstrations of this sort of stuff as:

• Too technical and hard to understand
• A self-serving exercise that only benefits the teams
• Boring and a waste of their time

I understand that position and I’ve experienced it first-hand in nearly every organization I’ve been a part of. And that attitude is what’s convinced Josh to not bother.

But I like to confront this and try to influence stakeholders to (try) understand and engage with more technical demonstrations.

Why? Because they should care. They’re paying for architecture and they should try and understand the complexity and infrastructural demands of their products. Surely not the way the teams do. But from a business perspective, value/impact perspective, competitive perspective and investment perspective, they need to… care!

Demonstrating this is a wonderful way to provide them training and guidance towards this improved understanding. Over time, they’ll start to get a feeling for:

• Architectural investment percentages
• Costs associated with their demands/decisions
• Trade-off decisions
• Risks associated with architecture (implementation AND delaying updates)
• The drivers behind refactoring
• The investment mix of features vs. architecture that is inherent to each product

All toward improved understanding, empathy, and respect of ALL ASPECTS of their products. I’ve found that stakeholders who engage in all aspects of their products, make far better decisions.

So, at the risk of aggravating my friend Josh. He’s wrong.

I want that same level of thoughtful planning to occur for architecture as it does for features. And as with features, everyone becomes a stakeholder in the architecture (as well as the features). That means they understand the motivation, agree with the business case/investment, understand the impact/value and sign-off when it’s done.

I’ll start explaining this guideline with an analogy.

I’m a homeowner in North Carolina. Our climate causes specific types of degradation in my home. And then there is simple aging to contend with. So, I find myself annually investing in the upkeep of my home and its systems. I view it as a pay me now vs. a pay me later decision, and I like to keep my home nice, so I tend toward paying me now.

Some of my neighbors have the reverse philosophy. For example, in house painting. I’ve been painting on a regular, every 5-year schedule. But some of my neighbors only paint when things are obviously falling apart. For example, exposed wood, wood rot, and severely peeling paint.

My strategy is more of a preventative approach and the costs are frequent but low. My neighbors, on the other hand, have less frequent payments, but when they do pay, it’s quite costly. For example, replacing all of their siding because they haven’t painted in 10+ years.

The other point is that I try and update to new technologies as well. For example, a few years ago I updated my HVAC systems to much more efficient units. Not only are they more reliable, but I’m saving money based on the new efficiency.

Switching back to software and architecture, I always recommend the same strategies for software development products and applications.

We need to acknowledge that software ages AND our approaches and tools evolve so that we want to be continuously investing in the care and feeding of our products. That investment needs to be part of our business case and factored into the ROI. And this isn’t just at a feature level. I’d argue, it’s even more important to keep the plumbing (infrastructure, tooling, automation, architecture, design, integrity, performance, maintenance, etc.) up-to-date as well.

Sure, your customers may not always seethis investment. But they will experience whether you are, or are not, making it.

Finally, I’m a proponent of asking my teams about technology evolution and trends and determining whether we want to invest along evolutionary curves as well. This includes new technology, new tools, and new approaches. And it’s important to LISTEN to your team and TRUST your team in these recommendations.

They’ll know far better than you what the relevant trends are and the value that it can bring to your business and customers. Point-being, don’t wait until your house crumbles and you have to rebuild from the ground up.

I hope you think deeply about the rules. Not as harsh laws, but as thinking patterns you’ll get into your organizations DNA.

It may seem that architecture is a simple by-product of executing in an agile way. Quite a few organizations seem to take that approach. I hope this article series has helped you think of agile architecture in a new light.

Not in a traditional software architectural view. And not with a hand-waving view. Instead, I think success is somewhere in between. And that we have to take agile architecture somewhat seriously. I firmly believe that architecture is not something that someone occasionally does. I instead think of it much more broadly. And I hope to influence you to do the same thing.

This article series was inspired by this InfoQ article that compliments this one –https://www.infoq.com/articles/architecture-five-things

It was also inspired by a Meta-cast discussion I had with Josh Anderson. We exposed these eight rules, principles or thinking points really, in that podcast. You can find it here, and I believe it will complement this article as well.

Stay agile my friends,

Bob.

 

Up Next:

• How should UX work in Agile? >> Read
• Addendum – An Agile UX Story >> Read