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:

#1) Allow Architecture to Emerge

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, then you’ll be constantly reworking everything, which will slow you down (or stop you entirely). BUT, if you look-ahead completely without experimenting and implementing your ideas, then 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, then you’ll find the right look-ahead balance for your context and your teams.

#2) Treat it Like a Product

I’ve always liked it when an organization develops a backlog of architecture stories that 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 that 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 that 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, then 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.

#3) A Picture is Worth…

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.

And I 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. It’s the conversations that are the most important thing.

#4) Everyone IS an Architect and Everyone OWNS the Architecture

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 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 that our speed and more features would have been top of their minds.

And it was. 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.

Wrapping Up

That’s the first four rules. I didn’t want to overload you in this installment, so I’ll save the next four for part-2 of this article.

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

You see, I firmly believe that architecture is not something that someone occasionally does. I instead think of it much more broadly than that. 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

But it was also inspired by a Meta-cast discussion that 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.

Comment