For many years everyone strived for the “perfect design”. Frameworks, such as TOGAF, do allow you to do this. However, unless you are on a multi-million pound budget per quarter, no project has time for this. This drive for perfection, has led to organisational structures that:  involve many teams reviewing your design; lots of quality gates; and lots of delays waiting for full approvals.

Sometimes the governance structures required a select panel of architects to do a detailed review of each design. I worked in one place that they told you all the problems with your design (in their view). You had to go away and guess what the answer they really wanted was. To add insult to injury, the organisation attitudes meant you could not talk to any technical subject matter experts to help find out what was needed. You had to then keep on re-submitting until you got it “right”. Not a productive use of anyone’s times…   

For me, this feels like the “bad old days”, where an organisation has that slow / heavy weight approach to design. This not only delayed the start of the programme,  but you had no mechanism to investigate before committing, often starting the build with only a rough understanding of the technology. This often meant that delays were inevitable when build teams:

• Come across the harsh reality that the technology didn’t quite work that way…
• Find that a premise that under pinned x% of the design wasn’t true…

To vaguely keep to the intended timelines you add in manual work arounds, or add complex processes to avoid scrapping that entire part of the solution.

Bringing agility to the squad

Obviously I am now going to talk about how Agile saves the day….

Agile works well when teams are empowered to make their own decisions and self-serve their tech requirements. However, where does this leave architecture, which is about the bigger picture? How do you get squads to complement each other? How do you help the organisation change direction quickly if each squad isn’t connected to the bigger picture? How do you re-enforce the squads independence?

Some practical ideas to help the architect keep the bigger picture embedded in the mind of a squad:

• Keep yourself in the loop of the organisational architecture (e.g. tech radars) so you can disseminate the latest
• Be at daily standups to nudge and steer tickets
• Define concept target architectures to help shape short term decisions
• Get feedback from the wider architecture community and turn that it into acceptance criteria or KPIs
• Work jointly with product owners and tech leads to shape decisions

Make yourself available

If you want to help your organisation move faster, you also need to be available for other teams to ask questions and brainstorm! 

How can you do that? The shift to Agile has to extend into your diary, it can no longer be full of meetings months in advance. As long as you are only working with one or two squads, it isn’t too hard to orientate your diary around your primary team’s current sprint and the next sprint.

It does require a new mind set that accepts that teams often won’t be able to know they need to ask a question until they are in the sprint. I used to get frustrated when teams randomly dropped in a question and wanted an instant answer otherwise they were delayed… Couldn’t they think beyond a few sprints to give me time to work through options and come up with a decent, well tested answer? As it turns out, no!

As your diary changes, then there is a side benefit that going into sprints, you should have more space to be able to respond quickly. If you can’t fit in all the meetings, prioritise the ones the squad needs to deliver. This should mean the meetings you run out of time to attend are generally not on the critical path.

My rule of thumb is that when meetings hit over 50% of the day, I won’t have time to support the squad(s), nor to write down the knowledge and decisions that help future decisions. When the diary fills up, you need to start pushing out the new meetings or looking to get the scope of your work/ role changed.

The slight wrinkle with this approach is that it only works if a good portion of your organisation is agile and interested in collaborating and sharing knowledge…