I went to a couple of great presentations on the "Software Craftsman" track at the QCon London 2011 conference last week that, together, provide a really easy way to explain how software architecture fits into modern software development teams.

Everybody is an architect

The first session, entitled Craft and Software Engineering by Glenn Vanderburg, explored the relationship and conflict between the craft and engineering of physical construction and software development. Really interesting session and I recommend downloading the slides or watching it if you get the opportunity. For me, one of the eureka moments was when he presented this picture from his Extreme Programming Annealed essay. Basically, it shows the scale at which the XP practices work.

I've highlighted collective ownership. Yes, it is about the code but collective ownership implies that everybody on the team needs at least some basic understanding of the "big picture". Think about your current project; could you jump into any part of the codebase and understand what was going on?

Imagine if you did have a team of experienced software developers that were all able to switch in and out of the big picture. A team of genuinely hands-on architects. That team would be amazing and all of the concerns you usually associate with software architecture (non-functionals, constraints, etc) would all get dealt with and nothing would slip through the gaps. From a technical perspective, this is a self-organising team. Think of them as a solid concrete dam blocking a fast flowing river, through which nothing can escape.

Except when they're not

My big problem with the whole self-organising team idea is that I rarely see it in practice. This could be a side-effect of working in a consulting environment in that my team always changes from project to project and I don't tend to spend more than a few months with any particular customer team. Or, I suspect that true self-organising teams are very few and far between. Striving to be self-organising is admirable, but most teams have bigger problems and the sort of scenario played out in my recent Software Project SOS session is indicative of the problems that I see.

And that brings me on to the second session, Team Leadership in the Age of Agile by the guitar playing Roy Osherove. Again, the slides are available to download. The session was about what you need to do in order to lead a software team, highlighting the fact that not all teams are equal. Roy categorises teams using a simple maturity model, which you can see described in more detail at The 3 maturity stages of a software team and how scrum fails to identify them. The three stages are: chaotic, learning/maturing and self-organising/matured. In essence, each maturity level requires a different approach to leadership.

As I said above, a team where everybody was an experienced software developer/architect would be amazing but this isn't something I've seen happen. Most projects don't have *anybody* on the team with experience of this "big picture" stuff and this is evidenced by codebases that don't make sense (big balls of mud), designs that are unclear, systems that are slow and so on. This type of situation is the one I see the most and, from a technical perspective, I recommend that *one* person on the team takes responsibility for the software architecture role. Roy also suggests that most teams are in the chaotic stage and, similarly, need more of direct leadership approach early on.

Whether you're talking about team leadership or technical leadership, the principle is the same. The chaotic team is like damming a fast flowing river with a bunch of twigs. It'll slow the water down for a very short amount of time but it soon becomes ineffective and you'll struggle just to keep stationary. A more direct leadership approach in these early stages will show you what you can't see and allow for some solid advice on which holes should be filled immediately.

Agile projects still need software architecture

Unfortunately, many teams view the "big picture" technical skills as an unnecessary evil rather than an essential complement, probably because they've been burnt by big design up front (BDUF) in the past. Some are also so focussed on the desire to be "agile" that other aspects of the software development process get neglected. Chaos rather than self-organisation ensues yet such teams challenge the need for a more direct leadership approach. After all, they're striving to be agile and having a single point of responsibility for the technical aspects of the project conflicts with their view of what an agile team should look like. This conflict tends to cause people to think that agile and architecture are opposing forces and that you can have one or the other but not both. It's not architecture that's the opposing force though, it's BDUF.

First things first then. Agile software projects still need architecture because all those tricky concerns around complex non-functionals and constraints don't go away. It's just the execution of the architecture role that differs.

As Roy said in his talk, a self-organising team doesn't need a dedicated ScrumMaster. Likewise, it doesn't need a dedicated software architect either. With collective code ownership, everybody needs to be able to work at the architecture level and so everybody *is* an architect. Teams that aren't at the self-organising stage will struggle, though, if they try to run too fast. Despite people's aspirations to be agile, collective code ownership and a distribution of the architecture role is likely to hinder chaotic teams rather than help them. Chaotic teams need a more direct leadership approach and they will benefit from a single point of responsibility for the technical aspects of the software project. In other words, they will benefit from a single person looking after the software architecture role. Ideally this person will coach others so that they too can help with this role.

One software architect or many? Single point of responsibility or shared amongst the team? Agile or not, the software architecture role exists. Only the context will tell you the right answer.

Responses[8]

Posted by Simon Brown on 14 March 2011 12:49:44 GMT #