We hear a lot about the speed of Agile development and the teamwork between the developers, testers and product owner. But what about the architect? In this two-part interview with Johanna Rothman, SSQ contributor Matt Heusser asks about the role of the software architect and sneaks a peak into the tutorial that Rothman will be co-teaching this year at Agile Development Practices West titled, “Agile Architecture.” Read part two.
SSQ: One of the things that fascinated me about your tutorial is that you are organizing it as an experiential workshop. When I hear those terms, I think of games, simulations, and exercises. Can you tell us how you plan to teach "architecture" through exercises? I mean, what will the students be doing all day?
Johanna Rothman: They'll be creating products, as Agile architects do. Part of the day, they'll be doing the other part of the architecture activities: the wayfinding (scouting), prototyping, landing zone definition and refinement, experimentation, and dealing with the inevitable changes as the customers change their minds about what they want. When customers change their minds, often the architecture changes.
SSQ: Do you have a particular favorite exercise you can tell us about?
Rothman: Well, not yet. Let us run it first, and then Rebecca and I can pick our favorite. (This is kind of like us asking us to pick our favorite child!) Here's a teaser, though. We are going to have people build baskets and flowers. You might think, "Oh no, how is that about architecture?" But think about it a minute. What kind of baskets? What kind of flowers? How many? What if the baskets change during the program? Handle or no handle during the program? What if you need to hook two baskets together? What if you need to separate two?
You can see that the simulation does its job -- it simulates a real life project program, without having to write code. So, in a two-day workshop, we can experiment with the kinds of activities that Agile architects and teams will perform, or should not perform on a project or a program. And, because we are using a simulation, it's a safe way to experiment. Really, if you experiment in the workshop, and it's not such a great outcome, is it the end of the world? No, because it's a workshop and a simulation. You get feedback really fast. And you learn how it's like your world and how it's different.
SSQ: Speaking of the basics, can you tell us what Agile architecture is? What does it mean, and what should we do about that?
Rothman: So the architecture is the business value of the framework. Rebecca and I saw too many products suffer from "feature-itis," where Agile teams create feature after feature after feature because their POs told them to, which was good. And, because their POs didn't understand the value of looking just a little bit ahead to create and build the business value of the architecture, the features created technical debt in the product.
We also saw plenty of teams who pretended to be Agile after many months of framework development by seagull architects, or worse, “Big Design Up Front” (BDUF) by PowerPoint architects who then left the project or program and never got their hands dirty in the code. Those architects left the teams high and dry to manage the product without them.
In a relatively small project, the PO, the architect, and the team all work together as a unit. You can't tell the architect is any different from anyone else on the team. You might not treat anything differently, except to say, "Oh, we should do some wayfinding before we commit to this story on the backlog." Instead of committing to stories, you commit to exploration, where that exploration is warranted. You really bring the ideas of Agile in, and ask for feedback more often, not less often. You educate your PO and talk about the business value of the product, the architecture, and make the tradeoffs of technical debt, especially architectural debt much more transparent.
But the place Agile architecture really comes into play is on a large program. You cannot finesse architecture on a large program. I've been trying to write my program management book for a year now, and I realized that how people manage their architecture issues is a big piece of it. What works for SaaS may not work for other kinds of products--the kind of product you have is a huge piece of your context on a program. But the piece that is the same is that the architecture is all about the ongoing business value of the product. Can we add more features easily? That's the business value of the architecture.
In part two of this two-part interview, we’ll talk about how Agile architecture manifests, what an "Agile architect" role might be, how to manage architectural debt, and more.
A former programmer, manager and software executive, Johanna Rothman has spent the past sixteen years as an independent consultant and coach on software development. During that time she's managed to accumulate a collection of kudos -- from a string of keynote speaking engagements, to acting as general conference chair for the Agile 2009 conference, to writing four books, and, perhaps most importantly, leaving a slew of successful clients in her wake.