I’ve been developing an agile architecture workshop with Rebecca Wirfs-Brock. Aside from more Murphy’s Law moments than a small project deserves, we’ve encountered a number of agile architecture and program myths. Here are three for your reading pleasure. (Just in case you aren’t sure, all of these are false–they are myths.)
“We don’t need no stinkin’ architects!”
If I have a large and complex program (say more than five teams) and the product includes firmware or hardware, I like guided evolution with program architects. Why? Because the cost of having unknown architecture for too long presents too high a risk. By “guided evolution”, I mean the architects might do some initial wayfinding, prototyping and exploration (or even lead all the teams in the initial wayfinding, prototyping and exploration) so that the alternatives for the program are clearer.
I once worked with a team of all junior people–60 of them–and they knew they did not have the experience to work on the product. They knew they were missing key experience and they did not know what they were missing. They wanted an architect–not to dictate, but to help show them where to explore.
On the other hand, if you have a small program (say of fewer than five teams) and are working on a software-only product, maybe the risk of unknown architecture is sufficiently low enough that you don’t need an architect to help guide the exploration, especially if you have sufficiently senior staff on the project.
As with all guidelines, your mileage will vary. But look at the agile manifesto; see where it says, “The best architectures, requirements, and designs emerge from self-organizing teams.” That doesn’t mean there are no architects–that means that many people can play the architect role. If you have no one who can play that role on the program, the product will suffer–and that is a significant risk. As a program manager, it’s your job to expose and manage that risk.
“We don’t have superheroes, so we must do BDUF!”
One of the artifacts of having no architects is realizing that if you have access to one architect for two hours on the first day of the project or program, it’s very tempting to quickly get that person to knock out a design the very first day. Do a Big Design Up Front! Or, if you have no architects at all, the program staff all get together and say (as that junior team said to me), “JR, we can’t do this without a big design up front. We know you want us to do features first. But we don’t know where we are going. We need to design first, and we don’t want to design features. We want to spend the next three months designing the framework.”
Now, I am an experienced project and program manager. I am not an experienced architect. So I asked Rebecca, “I have never seen a BDUF work. Is it just me? Am I the unlucky one? Have you ever seen an architecture defined at the beginning work?” After she picked herself up off the floor and stopped laughing, she said, “No, some of them come close, but no one ever gets an architecture right the very first time. It’s not possible.”
As you implement features–especially in an agile program–you evolve your understanding of the system. Take advantage of that understanding to evolve the architecture, and especially to evolve the business value of the architecture. The program manager can help here by nudging the development teams and asking for pictures of the architecture and asking if it’s time for an architecture review.
As for my junior team who wanted to spend three months designing a framework, I said no. I compromised–I asked them to work in their feature teams, designing what they needed for their features and then to get together to see where their “frameworks” led them. In the meantime, I had bought myself two weeks to find a more senior person who could help our program. It was clear to me we had a significant impediment.
“Architecting work is ivory tower; architects must not let their hands get dirty in the code!”
The very first time I met an ivory tower architect, I thought I would vomit. He strutted into my office and introduced himself: “I’m John, your architect. Here’s what I do. I examine the code and tell people what they are doing wrong. I tell them where to use patterns. I tell them where to reuse code. I tell them how to use frameworks.” He said a few more things I’ve since forgotten. It was all about what my program’s developers did wrong.
“And how do you know all of this?”I asked.
“I read the code. I go to conferences.”
“Do you ever write any code? Do you ever test the code? Do you ever experiment?”
He looked horrified. “Certainly not. I don’t write code.”
I stood up. I walked out from behind my desk. I stretched out all of my five feet and looked up to his six-feet plus and poked him in the chest with my index finger. “You are not to come near my program. You are not to talk to my developers. You send them e-mail, and I will let the air out of your tires. You come near them in the cafeteria, and I will spill your drink on your pants. You come near anyone on my program and I will find a way to kick you out of this company, you understand?” I smiled as I added, “You can leave now.” I walked back to my desk and sat down.
He stood there, shocked. No one had ever talked to him like that before.
I could not understand how he was going to add value to my program–he wasn’t going to. Now, I am not advocating you vandalize someone else’s property. Maybe the air in the tires was a little extreme. (Actually, maybe the drink on the pants was a little extreme, too.) I was terrified he was actually going to insert himself on my program.
But never fall for the seduction of the dark side, where a seagull architect flies in, waves his or her hands, draws a few pictures and leaves. Or where a PowerPoint architect (thanks to Venkat Subramaniyam and Andy Hunt for that term) develops a beautiful architecture in PowerPoint and never has to live with the consequences. This architect who offered to “help” my program was the prototype of ivory towerness. I suspect he got together regularly with his ivory tower colleagues and complained about those “stupid” developers and even more stupid project and program managers who didn’t understand how hard it was to be an architect.
Especially in agile programs, the program architect and the program manager work together to provide business value to the organization. It’s difficult, intense and fun.I suspect you have encountered more myths about architecture in your agile and not-so-agile projects and programs. Please do comment; I would love to hear them.
© 2011 Johanna Rothman. This article was originally published on Gantthead.com.
Like this article? See the other articles. Or, look at my workshops, so you can see how to use advice like this where you work.