Skip to content
July 14, 2011 / David Bleeker

Agile Thrives When Architecture and Development Are United

Funny how the wheel turns! I have had conversations over the last few weeks that have resurfaced an old debate regarding the best approach to architecture within an Agile development team. This was a key decision point when I started working with Agile development techniques ten years ago.

Often architects are found in separate teams, organized by domain and made available on request to the application development team when appropriate. Architects organized in this fashion often perform architecture work (Big Design Up Front) before the application development starts. Agile practices suggest that architecture is something that unfolds as the application is developed, and that it is refactored often to account for lessons learned along the way. This pits Agile teams and architects against each other, which is unfortunate because the best minds in the IT team are now locked in a battle of control over the future of the application being developed. The separation between the teams, however, all too often results in core disconnects when the trade-off is made between execution and “doing it right.”

Key areas of benefit gained from architecture input include:

  • Frameworks, technology standards and high level design patterns that make it easier to create robust applications that fit well within the enterprise.
  • Guidance in terms of high level design, implementation roadmap and non-functional requirements.

When developers are confronted with the sometimes daunting task of delivering working software in small increments, the temptation is to throw out any consideration that will not directly contribute to their immediate success. Better to hack a small increment than to report back that it will take longer. Looks good with the management when the project has the appearance of moving forward. Towards the end of the project, or years later if you are lucky, the technical debt introduced by those choices raises its ugly head.

I have been in situations where the architect, development manager and lead developer were all on different pages. The implementation did not match the stated architecture, which did not in turn match the design pounded out on the conference room whiteboard. When the developer is at their keyboard, with the weight of the world on their shoulders, sometimes it makes sense to cut a few corners. It is this process of avoidance that raises the risk of a software project. It is this risk that makes traditional software development managers nervous.

So how do you avoid the disconnect. I would like to offer an approach that I have used to overcome these issues. Not exactly standard issue, but it has worked well for me in the past.

The approach I have taken is to have my software architects serve as lead developers. They are part of the development team. No separate function, no occasional touch point. Some of the key benefits of this approach include:

  • The team benefits from the architect’s experience and insight throughout the project.
  • The basic architecture can be put in place quickly and evolved reliably over time. The architect is able to see potential issues and can work with the team to refactor quickly while the investment required is still low. They can frequently stop a bad idea before it starts.
  • In keeping with Agile development’s “short feedback loops” philosophy, the architect can make decisions quickly and effectively instead of waiting for a meeting with another architecture team.

Unfortunately this approach is not without its issues.

  • The architects may not want to cooperate. Since architecture is seen by some to be a growth path within IT, it seems counter culture to go back to software development when you have already made the leap.
  • The architects may dominate the team. It is important for the architect to leverage the skills of the team and not dominate decisions and coding activity within the team.
  • Architects may be structured into a separate team within your organization, and only available on-demand. In these cases, I recommend that you arrange for a dedicated architecture representative and make them a part of the team as much as possible.

Overall, the gains from having the architect as lead developer far outweigh the issues. I have seen Agile development projects find traction quickly when an experienced architect heads the team. The entire equation is reduced to simple execution since everyone is on the same page. Most of the time.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: