Agile architecture – How do you apply it in practice?

Agile architecture is one of those topics where there is still more questions than answers. There is a shortage of pragmatic advice on how to apply architecture in practice to help Agile development projects successfully deliver to business when it comes to architectural considerations. If you are working on an Agile development project you may be asking ‘Agile architecture – how do you apply it in practice?’

At Equinox IT we have spoken quite a bit about Lean and Agile as it relates to architecture recently in the following webinar and blog post articles:

• Webinar: Lean architecture – Architecting in an Agile world
• Article: Agile architecture - Where does an architect fit in a Scrum sprint?
• Article: How do you make architectural decisions on an Agile project when you have no architect?
• Article: Can model-driven architecture be used on Agile development projects?

These have been fantastic building blocks for understanding how architecture can be more effective in an Agile project. However, in this post I wanted to move the focus more on practical usage of Agile architecture, how I applied it on a recent client project, and what lessons you can learn from my practical application.

Case study – applied Agile architecture

The need to adopt Agile

My recent client engagement started off using traditional waterfall approaches on a project by project basis. As time moved on and various projects were successfully completed I became the ‘go to’ architect for every technology project. This allowed little time for the thoroughness and completeness that I generally believe is required when dealing with architectural considerations in this type of approach.

At the same time the company executive was very vocal about the urgency required for delivering new online solutions to stay ahead of the competition.

So, to alleviate myself from being a bottleneck and to help deliver faster business outcomes, I convinced the project team to adopt a more Agile or Lean approach to deliver this project.

Adopting Agile

As a project team we did not go through a formal process of Agile training and we did not assign specified Agile roles. However, using the collective knowledge and experience of myself and the team we began to embed Agile practices, including working in short sprints on prioritised backlog items and engaging executive stakeholders to help identify and prioritise what was required each sprint.

Being the Agile architect

As the architect working on this project I found myself in a world as described by my colleague Bill Ross in his webinar Lean architecture – Architecting in an Agile world.

Specifically, I was in continuous collaboration with all development domains (legacy, integration, 3rd party) to understand the architecturally significant options, make the right decisions and capture these in decisions in a manner best suited for each party.

The Agile Manifesto so clearly puts its focus on delivering working software over comprehensive document. At no point during the project did we ever discuss the need for a traditional Solution Architecture Document. Instead I produced specific artefacts with insight into how a specific piece of the solution was designed when required. Time permitting, a collection of these artefacts was put together as a repository of viewpoints to document the overall design.

At various points of time I determined that a feature expectation articulated in a user story was starting to hold up the creative effort. In these situations I facilitated a specific options analysis activity to determine the best way forward. A few of these activities resulted in pushing specific features out of scope for a particular release. These were placed in the backlog for future prioritisation by the executive stakeholders.

As the first sprint started to wind up and my architecture involvement reduced, I started the next sprint to push ideas and questions to the team-members for consideration and discussion. This accelerated the design and collaboration process significantly and we were able to collectively deliver the project. In retrospect I was lucky to work with a team of adaptive individuals to make this a success.

Various tools and techniques were used as and when required, most notably:

• iServer (Visio on steroids) for structural models
• Spark Enterprise Architect V12 for behavioural models
• Archimate 2.1 for overall design and decision representation
• Atlassian JIRA to electronically record sprint tasks and associated progress tracking.

5 lessons for applying Agile architecture in practice

From my experience in this project I learned a number of lessons that may be useful as you look to apply architecture on your Agile project:

1. Make a start

As a project team we made the decision to work in an Agile way and just started. I used the same approach while designing the particular pieces for the architecture. We didn’t wait until everything was perfect and we had all undertaken the necessary training. If we had done this we never would have started and simply further embedded ourselves in the current waterfall approach.

The business needed results now, so there is an element of a smart, cautious, yet pragmatic ‘just do it’ approach required to kick-start the journey with Agile architecture.

2. Continuously improve

Having started using an Agile approach and applying Agile architecture, there was still a great deal to learn to optimise the approach. We were all pretty green to start with. During the project we did things, some of them worked well, some not so much. Doing more of what worked and less of what did not was a pragmatic approach to continuously improving.

No doubt we still have more to learn and certainly I think I will facilitate the architectural decision making more effectively with the learning that comes from future projects. Agile and Lean approaches place a significant focus on learning and iterating work and feedback to facilitate that learning. We should harness this approach to continuously improve and perhaps when time permits invest in formal Agile or Lean training and certification.

3. Make collaborative Agile architecture decisions

Working as part of a collaborative, cross-functional Agile team means that we are dissolving the traditional silos and ‘command and control’ structures. In this context architecture becomes less about enforcing standards, dictating an architecture and creating massive solution architecture documents (SADs). It is more about collaborating with the team and stakeholders to make the best architectural decisions at the right time.

As Equinox IT’s Bill Ross covered in his article How do you make architectural decisions on an Agile project when you have no architect? you should focus on making the architectural decisions in an open and collaborative manner and in doing so make better decisions for the project and the business.

4. Be adaptable

As architects we have been indoctrinated into approaches that sometimes encourage us to have fixed views when it comes to architecture expectations and standards. Agile, however, is much more accommodating of change and requires those people with architectural responsibilities to be more adaptable and provide more of a challenger, guidance and leadership role. For example, let’s not ‘gold plate’ the architecture for a particular system, even if this is what our old standards might expect, if this adds significant time and cost for no additional value (or risk reduction) to the business.

Agile architecture requires us to be adaptable and make the best architectural decisions for the project and the business based on the information we know. In my case study, we made tough decisions all of the time and sometimes we had to defer features, often for architectural reasons, and these flexible decisions were made adaptably and pragmatically to suit the specific circumstances and needs of the business.

5. Work with the right team

Introducing an Agile way of working is going to be tough if the team is not on-board and committed. By team here I am also talking about the wider stakeholders representing the business who are involved in the project.

I was lucky on my project that even though we were collectively inexperienced when it came to the Agile approach, we were all committed to doing what it took to make the project a success and we were willing to embrace new practices and a collaborative culture. Agile is a culture change and so this lesson is probably the most important of the five.

The happy ending

In my project, this was the client’s first attempt at using an Agile approach and the wider team was continuously on top of what was going on. At the end of the project the business received the product features that they needed in a cost effective way and within an acceptable time window.

Interestingly, as the architect I was able to use the collective ‘onion peeling’ pattern to collect layers of information to a point whereby enough design was available to create the solution without going over the top, without developers waiting for direction and without feeling that I was the one making all the decisions. In the end everyone owned the successful solution to the business problem and a side effect was that the intellectual property ended up being shared around the team.

If you have practical experience applying architecture in Agile projects it would be great to hear your views in the comments below.

Herman van Krieken is a Principal Consultant specialising in architecture and is based in Equinox IT’s Wellington office.