One thing I left out of m y post – I’m also stressing that the development teams walk through the stories together with the architect to agree on the best way to implement, rather than designing something and handing it off to the architect for approval. So, to your point, Zach – that *is* helping somewhat, when it happens.

* Reduce waste from rework
* Increased changeability of code by avoiding writing frozen code

Both of these are incredibly important in an enterprise with hundreds of developers working on interoperable systems.

Traditional enterprise architecture tried to accomplish this with architects as gate keepers. They would somehow be responsible for the design of the entire architecture of an organizations software system, but be so involved in meetings that they wouldn’t get much opportunity to see how the code is actually interacting. Decisions which make perfectly rational sense at the architects abstraction layer could cost a lot of money and not provide any additional business value.

Agile architecture requires architects to act as empowerers instead of gatekeepers. Their responsibility isn’t to prevent poor design choices, but to use their experience and skills to create communities of shared information.

how does this happen?

First, they must focus on making important information big and visible.
* Code health (however you measure it)
* I prefer to measure cyclomatic complexity and unit test coverage, and monitor for improvement over time as opposed to some absolute mandated metric.
* Public API Specification
* I prefer to use a tool like cucumber to create human readable examples exercising the public API.

This is more difficult than it sounds. Making this information big and visible is *TOUGH*. The best way’s I’ve seen have involved using tools like github corporate accounts so that the wiki, build instructions, issue tracker, and source control are all tied into a single streamlined (yet highly adaptable) system

Second, they must focus on providing the right education
* The 4 rules of simple design are pretty crucial
* So are code smells and refactorings
* What are the common values you share as a dev organization (Small parts loosely joined? Boy Scout?)

Flipping architects from gatekeepers to empowerers is by no means an easy task. It requires a hig level of respect and empathy from all involved parties, and a willingness to trust that everyone involved is doing their best to help the organization succeed.

We’re making progress on it …

Dealing with all of that – a project with enterprise scope, the culture, the coordination across teams in a large IT department – is extremely challenging to apply agile to thoroughly, no doubt. You’re right in trying to find the most flexible compromise. Agile is a set of principles as you know well – and to me it sounds like some of your coworkers might not be embracing the implied flexibility and cooperation that is part of agile culture to ‘just get things done’. That isn’t a developer-centric mantra, it’s an organizational one and compromises must be made on both sides. The architecture team should build both short term roadmaps and a backlog to suit the next sprint or two as well as their longterm goals. And the scrum teams building apps need to be mindful of their own future needs. It’s crazy to think they won’t know where they’re going to be… you’re planning before, during and after a sprint – there’s plenty enough of an idea of what you’re going to need out of the infrastructure. What questions do you need to answer? How many servers? Networking access? Replicated databases? Integration between systems? Those big chunky questions should be easy enough to answer. You may not know if you need 2, 3 or 5 web servers to accommodate your global expansion, but who are you rolling out to first? You understand all this, I’m sure. My only advice is to see how well you can cross-pollinate. In the same way I always add one QA guy to each scrum team, I’d find your best architecture advocates and have them infiltrate and co-mingle with your scrum teams as well. If they’re right on the team, they can best hear and understand and foresee the immediate architecture requirements. Might even just be one guy that attends each scrum meeting and perhaps some weekly product-focused meeting or a scrum of scrums. But so long as the architecture and scrum teams are completely separate they won’t feel like they have common goals I guess.

Good luck, do post back to let us know how it goes,
Brian

The Agile Gap to me is a given risk whenever you have an enterprise wide project because not one team can do that work on their own and working with other teams exposes how not all teams work the same way, even when they are both using Agile.

I don’t know, “Scrum,” but I love your analogy, and it’s quite effective in helping me ‘get,’ the true value of ‘Agile.’ (Ummm, it’s about getting from here to there, right)?

-Mark

“I just finished a large collection of essays by Joseph Mitchell, who wrote profiles of New Yorkers and their environs during the ’30s, ’40s, and ’50s, many as pieces for The New Yorker. His portraits of people and the various subcultures (gypsies, blacks, homeless, circus freaks, fishermen and fishmongers, pub denizens, bohemians, etc.) were rich with detail and there is a great emphasis on the “old days” and what were the modern days at the time of his writing. But the pieces aren’t maudlin or directly trying to say, “Sigh, life was better then.” Anyway, I was particularly struck by one essay that profiled a black community outside of NYC that had been originally populated by free Negro oystermen in the mid-1800s. An elderly man that Mitchell meets tells him what the community was like when he was a youngster and the town was thriving: very social, heavy church attendance, regular community gatherings and roasts, porch-visiting, and everyone working together in the oyster business. Then when the business declined due to the polluting of the Hudson River oyster beds, the townspeople were forced to look elsewhere for work, usually with long solo commutes and low pay. People lost touch with one other, let the town become neglected, no time or energy for church or parties, and TV replaced porch visits.

I’d say that is pretty much the American story for the second half of the 20th century. Not much out there brings people together as a community and provides a space for shared experience–at least not in comparison to the days before we could so freely and widely roam away from our village. I believe that social networking sites are an attempt to recreate that essential need for humans, but it is still a crude prototype. Facebook is trying to be our new front porch. We must decide whether we want to sit on it and deal with whomever wanders up to chat (even if it is inane), to sit inside but leave the drapes open and peer out (which will invite only the most intimate, curious, or persistent), or shut the blinds completely. Because the concept is so new, I am wondering if by participating in it, I can help shape its evolution to something that is more satisfying and representative of what people like you and I are looking for (rather than what 21st century teens are doing).”

(She’s a writer, if you couldn’t tell.

.. man, she’s cool.

http://www.coqaa.org/cgi-bin/tags.cgi