Agile architect - 7 lessons for becoming a damn good one

Once upon a time I was content in my role in the software development world. As a solution architect I would lead the design of IT solutions for clients, listening to their concerns and producing designs by way of Software Architecture Documents (SADs) that development teams would happily (okay maybe “happy” is an exaggeration, probably “begrudging acceptance” would be more accurate) go off and implement.

I thought I had it all figured out, but then Agile software development came along and I found myself dealing with highly independent Agile development teams that just got on with delivering software without any formal modelling and designs and who shunned the wonderful SADs that I had been producing.

Over time I came to understand and accept Agile practices and I learned that solution architecture planning and design is still a required and necessary part of the development process, regardless of the methodology being employed. But, like many other architects I have had to adapt to new ways of working in order to get along with and be effective with Agile teams.

In this article I share my top 7 lessons for applying solution architecture to Agile development projects, to help you too make the transition to Agile architecture.

Lesson 1: Solution architecture is important on Agile projects

Let's get a very important point out of the way right now – solution architecture is just as important on Agile projects as it has always been.

Non-functional concerns around performance, scalability, security and availability need to be addressed and designed for. Decisions have to be made with regard to the technology to be used, the nature of the application architecture, the design patterns to be followed, and the infrastructure and network arrangements required. Agile does not do away with solution architecture or software design. What it does is change the manner in which architecture and design decisions are made, communicated and executed.

Lesson 2: Be part of the Agile development team

On Agile projects I found that architecture is most effective when it occurs inside the development team. It is difficult to be effective as an architect if you are not involved in the day to day activities of the team. Agile teams are self-organising and cross functional. Everyone with the skills required to deliver the solution works together. As a solution architect you need to be engaged and adding value to the development process. Architects can bring a wealth of knowledge and a breadth of experience to development teams. They are in a prime position to use their technology expertise to turn a client’s requirements into a working reality.

Note, many Agile teams in New Zealand are not large and there may not always be scope for a full-time architect on the team. In addition, the cross-functional nature of Agile teams and the need at times to swarm problems, means that you may need to be more flexible and willing to turn your hand to other functions on the project than just pure architecture. This is the pragmatic reality of working on New Zealand-sized projects.

Lesson 3: Manage the architectural runway

So how can you contribute and be engaged in the Agile project team? Well the best way is to help guide the development and delivery of the solution, addressing design and implementation issues along the way. This is known as managing the architectural runway – a term the Scaled Agile Framework (SAFe) uses to refer to the foundation pieces of the solution upon which the customer facing features are implemented.

To organise the architectural runaway you should plan ahead, look at what is required to develop the solution and identify the necessary building blocks of the solution architecture. These are then fed into the backlog as architectural epics or stories and incrementally delivered during sprints as they are needed.

In many of my projects, I tend to work one step ahead of the developers. I see what user stories were coming up, determine if there are any architecturally significant decisions or features required to support the stories and I organise the necessary architectural features to be developed. Along the way I also keep the team focused on working towards the architectural strategy and design principles that we have agreed upon.

Lesson 4: Deliver architectural decisions

While working on Agile projects I came to the realisation that the most important contribution I was making to the success of the solution was not reams of documents, but instead quality architectural decisions. Agile development taught me that architecture is about discussion and the deliverables are the decisions arising from those discussions.

Traditionally I had been focused on producing documentation, sometimes with unnecessary verbiage. Indeed many of my client engagements were measured against the documents I would produce. But in practice, it has always been the decisions embodied in those documents that were important. These decisions arose from many design workshops and water cooler conversations with the developers and project stakeholders.

Lesson 5: Produce lightweight documentation

So heavyweight documentation is out, and now, when I capture designs, I simply use a wiki to record key decisions or express a design pattern. This is done in a much less formal manner than the SADs I had been writing previously, and today I usually use free-form sketches and or whiteboards photos. Scott Ambler describes some great lightweight Agile Modelling techniques on his Agile Modelling website.

Lesson 6: Embrace iterative architecture

Working on Agile projects has highlighted that the traditional solution design approaches can lead to some dangerous thinking and poor designs. Trying to address all the design considerations early on and focusing on documentation as a key deliverable encourages practices that are based on making a lot of assumptions or guesses on what may be required before any real development work has taken place. I don't believe I have ever had any of my designs go through to implementation without requiring some kind of change, sometimes quite significant change. Good architecture is an evolutionary process. The right designs are created over time, implemented and adjusted as required.

Lesson 7: Prove the architecture through working software

I remember when I was starting out as a developer we had a term for architects who had limited practical knowledge and whose solutions were limited to paper designs - we called them “Brochure Architects”. When working as part of an Agile development team, you want your designs to have real value - to guide the development team to deliver a quality solution for the client.

The best way to do this is to prove your architecture through working software. Designs on paper don’t mean anything unless the ideas behind them can be implemented and validated using working software (another reason to avoid big upfront design).

When faced with uncertainty or choices to make, use development Spikes to assess options and pick the one that works for your situation. This way your decisions are based on concrete results.

Becoming damn good…

In this article I have set out 7 lessons that I have learned from working as an Agile architect on development projects. You should apply these lessons but also learn your own lessons by getting involved and finding out what works on your projects. This continuous improvement mindset is core to Agile and Lean approaches.

As a damn good Agile architect you need to be engaged as part of the team, working collaboratively to define the solution architecture, putting your ideas to the test in real software, and iterating to continuously make the solution better.

If you found this article to be valuable you may also want to see some of our related posts:

• Agile architecture – How do you apply it in practice?
• Agile architecture – Where does an architect fit in a Scrum sprint?
• How do you make architectural decisions on an Agile project when you have no architect?

Also see Bill Ross's recorded webinar Lean architecture – Architecting in an Agile world.

Kosta Hahladakis is a Senior Consultant specialising in architecture and is based in Equinox IT’s Wellington office in New Zealand.