Sam’s post, Being an Agile Architect, cracks open some fundamental differences between contemporary agile methods and traditional methods.
Dave Rooney comments, “I have talked for years about how the Agile thought leaders are able to already think intuitively of a system’s architecture, but we mere mortals have to really work at it. We need Agile Architects! Having an Architect doesn’t mean BDUF, but rather it means that there is someone with an overall vision of what a system should be.”
Everyone is a Designer – and if they’re not, they better become one
Dave’s comment points to a bit of essential understanding that is often lost on folks who only know agile through second-hand-smoke – that is, through hearsay, some disinformation, and occasionally through FUD.
There is a basic assumption on agile teams that the programmers involved know more about software design than do programmers on traditional teams. Though as Dave rightly points out, as agile is immersed further into the mainstream, it’s going to encounter teams of programmers whose design skills we’re never really required to flourish as a basic requirement of their jobs. Agile will inevitably come into contact with teams whose skill levels will progressively be lower than the skills of teams of earlier adopters. I think agile practices will still meet the challenge.
Software design skills risks are mitigated over time as an agile team engages in design-focused practices as part of their moment-by-moment work in implementing solutions under the guise of agile methods. Test-Driven Development and continuous design and code review through Pair Programming will naturally cause programmers’ design skills to deepen. On-going guidance from an experienced designer/architect/coach will fill in many of the rest of the cracks.
Design skills on an agile team deepen by necessity. The bar for software design is higher on agile teams as clean design is a primary enabler of productivity and sustainability. Without good design skills, the most a programming team can hope for is to lean on anti-pattern ridden crutches like Visual Studio’s flavor of voluntary complexity and tight coupling through its naive RAD tools and practices.
What’s an Architect to do on an Agile Team?
The question always seems to pop up: “What’s an architect to do on an agile team?” It’s not even an honest question. There is an inherent prejudice embedded in the very language used in this question. A more precise wording would be something like, “What’s a traditional architect to do on an agile team.” The answer should be obvious – the role of the traditional architect has little place on an agile team. Most senior programmers on an experienced agile team can do much of the work that a traditional architect is typically tasked with.
The bulk of the balance of a traditional architect’s responsibilities are distributed to other roles on an agile team. Some of these roles aren’t even a part of a traditional team’s organization, or even a traditional team’s verbiage. However, not all of a traditional architect’s responsibilities are accounted for on an agile team, and as Sam pointed out, there’s still a need for someone in a technical leadership roll on an agile team no matter how much higher we perceive our programmers’ design skills as compared to programmers on traditional teams.
On an agile team, programmers are more akin to a traditional team’s designers. If they’re not at the outset of agile adoption, they’ll be driven there sooner or later over a period that can last anywhere from a couple of months to a couple of years (depending on the predispositions of the programmer). Most of the traditional responsibilities of a traditional architect are taken on as a collaborative effort by an agile team’s senior technologists. The role of interfacing with the business is done by someone with technical and business knowledge who can in fact straddle the business/technology line. Even on traditional teams this isn’t always done by the architect. Even when it’s the architect’s stated responsibility to be the organizational interface point, he may not in fact be the right person for the job.
An Agile Architect
The traditional architect also has the responsibility of navigating the road forward – of scouting and plotting the course. Or as it was said in the dialog spurred by Sam’s post, to have an “overall vision of what a system should be.” Although on an agile team, an architect should also have a fine-grained vision for what the details of the implementation should be – putting in place expectations for patterns and tools supporting those patterns, and backing these up with a guiding value system for implementation, coding, and micro-design practices.
This means getting out in front of the pack in terms of technologies and timing the strike of new product and feature releases with the general availability of leading technologies that the team and the work product benefits from. In Sam’s case it means, among other things, to have been deeply knowledgeable of .NET before .NET even went to beta, to grok interop with legacy technologies to a greater depth than most, and to do the same thing all over again at the advent of advantageous technologies coming in the WinFX wave and beyond.
On an agile team, it’s the architect’s responsibilities to guide the team to new technologies and new approaches – and it means unequivocally doing this from right there in the common workspace, shoulder-to-shoulder with the rest of the team. Even if it means working side-by-side with coders. On an agile team, an architect is in fact a coder. The only people on an agile team who might not regularly code are the customer and the ScrumMaster. Everyone else gets an IDE – and not just the fancy Visual Architect version that may or may not ship with an actual compiler.
Building Frameworks During Agile Projects
An agile architect also provides technical frameworks that keep the team in the intended groove – and yes, this can even mean building frameworks in the course of an agile project – as long as there’s a customer-approved card for it, and as long as it’s built micro-incrementally.
The frameworks should find their justification in the system’s code and in best scenarios should be extracted from existing code. An agile architect is a gifted abstractionist who can sense abstractions through intuition and who can craft frameworks to extend the usefulness of these abstractions to the team.
He should be forward-thinking when implementing frameworks, and should be able to temper his forward thinking with agile development values like DTSTTCPW and to an extent, YAGNI.
Abstraction is a sixth sense. Not everyone has it, not everyone is good at at, and not everyone is interested or aware of it. An agile architect caries the concretions of abstractions into the team and into the code by doing the actual coding work himself.
Many frameworks growing out of traditional projects die on the vine while frameworks emerging from agile projects are typically already potentials living in a system’s codebase waiting to be surfaced. An agile architect senses the abstractions, refines them with his own hands, and re-integrates them into an application’s codebase again with his own hands, shoulder-to-shoulder with his team mates.
Participation isn’t Optional
On an agile team, the architect has a duty to participate as coder. He must be up to his elbows in the code that will make use of any frameworks that he builds, and the code that implements any technical plan that he has crafted or approved. He must be in the code to keep watch for divergences from the plan that signal either degradations in design or new design opportunities.
This can’t be done from behind a closed door. An agile architect is right there in the thick of things. He’s as capable of ivory tower thinking as he is down-to-the-metal application coding. His skills are lost if they aren’t constantly tested by, mixed with, and even augmented by the programmers that he serves. And therein lies the essential difference between what I’ve seen as architects on agile teams and traditional architects:
An agile architect serves his team. That’s one heck of a hard position to hold down consistently. The balance of power on an agile team isn’t the same as it is on traditional teams, otherwise it would likely detrimentally impact the extent of collaboration needed to achieve agile’s lauded successes. When things get hot and heavy in the war room, there’s no mahogany door to hide behind, and there’s not much of an eminent domain to invoke.
Playing the Command and Control Trump Card
Even though agile teams are self-organizing, deep democracies, it’s the agile architect’s role to break dead-locks on contentious design and process issues. This very rarely needs to be done with an iron first. If the team doesn’t already recognize the architect’s authority and responsibility over final design decisions, then it’s going to be hard to stick to a plan that might be predicated on subtleties that are beyond even the most senior programmers’ understandings.
Sometimes the command and control trump card has to be played. Most agile teams will almost never run into situations like this, but it’s gotta be done when it’s gotta be done. Even though agile teams are organizationally flat, it’s easier for someone to make final-call decisions when he has a mandate to do so.
The absence of the recognized tie-breaker and deal-maker on an agile team can ultimately lead to detrimental effects on the quality of the design. Agile’s particular flavor of design-by-committee is usually sufficient for a skilled team, but traditional management practices are still in play, and sometimes they’re even used.
Code reviews are good, and so we do them all the time. This is what XP is after with pair programming. That said, an agile architect should also be taking the time to sample a system’s code as it progresses through the project and nip in the bud anything that is tending to fall outside of the architectural value system.
This could seem to be like a bit of a Big Brother role, and it is, in effect. It’s not the George Orwell kind of Big Brother though, but more of a Irvin Ferdinand Westheimer kind of Big brother.
Microsofticus Architectimonius Disgustus – Hopefully a Species in Decline
Having experienced the stark difference of the practices and attitudes of architects on traditional teams versus those on agile teams, I’m biased toward the (sometimes difficult) investment in reality made by agile architects.
Part of the reason is the deep disgust I have for the retired-in-place and attitudes that many traditional architects hold as sacred and sovereign to the practice of architecture and the society of traditional architects. And although Microsoft culture is finally starting to show some signs of catching up with the Java world in regards to process and practices, it remains a great bastion for decadence and decay that is at the core of some of the most detrimental forces acting on the Microsoft developer community in regards to progression toward practice maturity. If I were a traditional architect in the Microsoft space, I might be a bit nervous too, considering that an average senior developer on an average agile team could likely fulfill 90% of a traditional architect’s responsibilities without the requirement of such a high-falutin’ title. An architect on an agile team isn’t merely a senior developer who has wallowed in enough professional lethargy to have gained enough seniority at a single company to have slept his way to the architectural golden handcuffs.
One of the most disgusting displays of decadent deterioration in the Microsoft architecture profession that I’ve seen took place at a Microsoft MVP Global Summit in Redmond. One night during the week, MVP’s and their product teams get together for a social mixer. These events are usually segmented along product divisions at Microsoft, and the developer division MVP’s were invited to a joint event hosted by the developer division product groups.
You might think that this event would also include the Solution Architect MVP’s, but they were elsewhere – at a wine tasting if I remember correctly. Off they scuttled in their leather-elbow-patch reinforced architecture blazers trailing behind them the stink of cliquishness that believes deeply in its own sovereign right to not have to mix with the great unwashed developer masses. God forbid such an architect allow his Stone Cutters ring to be kissed by such mere lips.
In the world of software architecture, these are the Peter Keatings of the profession.
Even though I’ve been “doing” acts of architecture for some years, I’m reticent to put on the blazer and go to the wine tasting – at least not while I’m at work. The closest that I’ve come to taking on the title was when I went to work for a Microsoft RD who taught “enterprise” ASP .NET courses that used static methods at the data access component boundaries. I chose to have “Abstractionist” printed on my card instead. Today, I would probably choose the title, “Pathfinder”.
Because so much design work and trust is shifted into the center of an agile team, an architect’s role on an agile team is often more one of path-finding than wine tasting.
A pathfinder is a leader and a scout. He’s a teacher and a participant. He’s a professional learner. He pursues mastery of the process and the tools as well as the practices and patterns. He’s in constant pursuit of self-betterment and knowledge. He hasn’t retired to a closed office with drag and drop architecture tools.
To me, a pathfinder is part architect and part bhodisatva. To an extent, I’ve been averse to being professionally reborn as an architect – at least not until the stigma of architecture stemming from the decadence of traditional software methodologies has faded into history. Till then, I’m comfortable being a pathfinder, and continuing to fulfill an architect’s role on projects staffed with a team of agile programmers who themselves are pursuing ever deeper skills and understanding of the software world.