To be or not to be – Agile Architecture

This is an attempt to highlight how the practice of architecture is misunderstood in most of the Agile projects & the root cause behind them – so that you may avoid them at your organization/project.

Agile has always challenged people with the age old question – how much to design upfront? But is the confusion just there? Frankly, it doesn’t even start there! Anyone understands the need of an architect, but how do we position an Architect within an Agile environment? How does Enterprise Architects work in sync with a Solution Architect? How should business leverage the niche skills of an architect to ensure the scalability of the application? And how are the architects coping with the changing dynamics of development methodology? How does this practice work in an onshore-offshore environment?

We take a look in to the current challenges & answer to all the above questions. We try to ensure that Agile delivery makes the best use of architects and architects don’t shy away from Agile world.

Flaw at Onset

architecture-agile-epicsIf we look from the very inception of a project i.e. the phase where we visualize requirements & float the RFP, we always acknowledge that the backbone of development will always be its architecture. Now, let’s step back & try to visualize how we place our requirement to the market & how they get interpreted.

While floating an RFP – just like any project, we strive to get the final figures from the vendor. In general, any response from a reputed vendor is acceptable, but the lower figures will excite us more. True! Situations tend to get more complex – if it’s an Agile project (well, we all wish to be Agile, isn’t it) – we tend to add some bells & whistles by adding the sizing constraint as well. How? Well, we often put a request of providing dollar value to Story Points. How does that help? Ideally – it doesn’t help us anyways apart from giving us a very high level understanding on how each module may impact us from investment perspective.

But the larger impact created is – while doing so, we totally push back on the time & effort that is required to drive a proper Sprint Pre-Planning phase (often misleadingly named – “Sprint Zero”) – which could ideally help us in getting the architecture runway identified. In most of the RFP responses that you may come across – you will see there is a gap between the “Proposed Solution” & the “Architectural Runway”. Ironically – these two needs to be working hand-in-hand to drive the success of any project (be Agile or non-Agile).

 

Architecture Runway – What & When?

architecture-agile-epic-sprints

For any project to set up a strong foundation, we need to have the Architectural Runway identified, continuously groomed & owned by someone – who has the holistic vision of the program/project. More so often we see promises around this, but what eventually come out are a few design documents or HLD/LLDs – but that is not what the expectation is. This is the forte of an Enterprise Architect – who should be envisioning how the overall program rolls up to its enterprise portfolio & he/she should ideally own it. Yes – Agile talks about collective ownership, but that works till a project level. When we work at a program (i.e. encompassing multiple projects) – we need single person accountability & more importantly – decision making authority. So this runway should project the framework delivery plan – spanning across iterations (or release trains), it should identify the integration points, think about the upcoming changes (e.g. even take in to considerations the facts like possible merger/acquisitions). The owner/owners (if too many distributed teams) will need to survive on the continuous feedback from bottoms up i.e. from teams who are actually consuming the architectural deliverables.

So the process gets kick started along with the start of the project and continues on its path of Architectural Epics to Architectural Features & eventual stories – which are all distributed across iterations.

Solution Architects in Agile paradigm

Just as the portfolio splits in to multiple programs, which eventually consists of one or more projects – on the same lines, the role of an Enterprise Architect eventually needs support from multiple Solution Architects – who work more closer to the ground level. Simply put – a Solution Architect is required to translate nonfunctional and functional requirements into design, within enterprise context. How does this understanding change within Agile paradigm? Actually – it doesn’t! Agile never advised to do away with the best practices & we never do so in this case as well. So, when we distribute Project level work in to multiple Scrum Teams, we should always consider (especially if it’s a large scale, distributed model) – having an Architect Council formed by representation from multiple teams. Here we will have our Solution Architects participate & could well be shared resources.

Distributed Self-Organized Teams

For a Greenfield project – which is distributed across geographies, how do we ensure that Architecture is given due importance and architects are rightly placed? Let’s look at my model:

architecture-agile-teams

 solution-architect

So, largely each location hosts multiple Scrum Teams (e.g. Team 1, Team 2, Team 3…) & each location has a Solution Architect working as part of one of the local teams – who will eventually represent this location. In case of larger distribution – we can have multiple Solutions Architects – representing 3-4 teams & they will form the virtual council of Architects.  Each locational representatives remains connected with each other via regular Architect Council Meetings (ideally weekly cadence) – whereas Enterprise Architects participate at least once a month to share the larger vision.

Ongoing Journey

Great! Now we have architects in place & they are constantly talking to each other. Does that solve all problems? Unfortunately – No! We just placed the system on place. But now we need to ensure that this system works towards the success of the program. How do we ensure that? There has to be regular review on the followings:

  1. Architectural Roadmap – represented in the format of Architectural Epics
  2. Implementation of Architectural Epics (as Technical User Stories)
  3. Ensuring Technical User Stories & the parent features or the epics are all governed by the DoD (Definition of Done)
  4. Enterprise Architect should be consulted & informed on all major functional decisions
  5. Any new technical initiatives need to be substantiated by Technical Spikes & then only implemented
  6. Never allow half-baked frameworks to be released to development teams (if it does, you have a major flaw with your DoD)

Conclusion

While we roll out an RFP or analyze the response on RFPs – this should be in our mind that not enough focus on Architecture cannot be put as an excuse on how Agile works or by statements like – Architecture will be evolving in nature & is driven by team, not a single architect. It’s true – it will neither be a single architect, nor do we expect the architecture to come out in one go. But what is definitely expected is – the plan & provisioning for the evolving architecture roadmap.

Just the way Agile Teams are cross functional in nature & there remains a virtual council of “Scrum Masters” – driven by Scrum of Scrum, Architects – who play a crucial role in guiding the team towards a one voice design approach, should also be having their representative virtual council – through localized participation. This structure ensures that overall Program Level architecture is drives by an experienced Architect or a group of experienced Architects. We value the concept of having team agreement on architectural design decisions, but the presence of proven expertise ensures minimized risk.  That is, while there is value in the items on the left, we value the items on the right more.

arijit-sarbagna-agile-scout[GUEST POST – Arijit Sarbagna specializes in helping organizations and teams to realize gains by adopting Agile principles and practices such as Scrum/XP/Kanban/Lean. Arijit was a formally trained project and program manager, before adding Agile to his tool kit. Today, with several years of experience in the field of Agile rollout and delivery (and a few grey hairs) Arijit continues to develop his craft by consulting and practicing with project teams in the field of Agile. Though originally from Kolkata, Arijit is currently working out of Pune, India.]

FacebookTwitterLinkedInShare

Trackbacks/Pingbacks

  1. New PM Articles for the Week of June 2 – 8 - The Practicing IT Project Manager - June 8, 2014

    […] Arijit Sarbagna explores the role of the architect in Agile teams and projects. […]

Leave a Reply