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.
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:
To fostering agile architectures, which:
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.
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:
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:
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:
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:
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.
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.
Check out our Agile 101 workshop, suitable for anyone interested in learning the basics of Scrum or Kanban.
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:
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:
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.
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:
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:
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: