Enterprise Architects and the Agile Project Touchpoint

At the heart of the Enterprise Architecture function is a primary objective to manage the ongoing alignment between the Business Operating Model (BOM) and the technology landscape. This objective is often built on the foundation of a well-defined and stable end-state technology target stack, where any deviations are managed and provisioned for if and where possible. 

Lean, often iterative methodologies are constructed around the adoption of a set of cycles that initially deliver a minimum viable product (MVP) that aims to provide sufficient features to satisfy base needs and also allows feedback to enable further developments and enhancements. This build, measure , learn approach provides the EA community with several challenges when considering governance of the technology estate and the underlying systems capabilities resulting in Enterprise Architects (EAs)  having to work at a lower level of detail with such projects to understand the rationale of decisions, introductions and impacts of any technology capabilities under consideration.

Without hindering the project, its objectives or it's time to market the EAs need to connect with projects during its lifecycles to understand and manage change. The diagram below depicts the areas of interaction during the various SCRUM phases where the EA may consider being engaged or at least be present. 


 

Activity

Activity Description

EA Engagement

1

Backlog Definition

The product backlog is a list of deliverables to be implemented as part of a project or product development.

 

Backlogs are prioritised taking a variety of formats, with user stories being the most common format adopted. Irrespective of the format each specification will directly or indirectly reference a set of business or systems capabilities to be delivered.

Yes

 

The EA must be ‘informed’ of any new services or products that the project will deliver and hence requires to be in a position to map these to the target architectural capability model.

 

2

Sprint Planning Meeting

During this meeting the team will develop realistic Sprint backlog and define the highest priority tasks which need to be done during the length of each Sprint.

No

This is very much delivery focused and the EA may not be required to attend such meetings

3

Daily Scrum Meeting

Daily Scrum meeting, or daily stand-ups, are short meetings daily. 

Each team member can discuss issues and allows the Scrum master to remove any bottlenecks or showstoppers

No

This is very much operational, and the EA should not attend such meetings in theory. However, I have found attending the odd meeting very useful.

4

Sprint Review Meeting

This meeting is executed at the end of each Sprint and enables the performance to be measured and assessed. 

Any potential changes are assessed and promoted

Optional

This again is operational and EAs may hinder rather than add value by attending.

5

Sprint Retrospective Meeting

Sprint retrospective enable the review of what went right and went wrong during a Sprint. 

The retrospective is a ‘lesson learned’ exercise often resulting in analysis of what should be done in future.

The retrospective is the point where the team discusses project items they would like to start, stop or continue doing.

Optional

Lessons learned are a delivery object and EAs should consider if they are required to attend these meetings.

6

Backlog Refinement Meeting

The product backlog grooming addresses the backlog items that need refinement for the next Sprint.

Yes

As there is an opportunity for the project to consider alternatives or new capabilities it would be prudent for the EA to attend these meetings if required

The above table is very subjective and obviously does not consider the project characteristics i.e. its scale, its impact, outcomes and changes to the technology ecosystem of the organisation which all contribute to the effort and scrutiny on the part of the EA community.


The above represents a simple and short illustration of the mapping between a typical agile project lifecycle to the engagement / contribution from the enterprise architects of the organisation.


Whilst EAs should not concern themselves with every minute ‘low level’ of detail for a project they should be fully aware of the project outcomes, services and capabilities the project aims to and will deliver. 


Discretion should be used when participating in any scrum meeting as the conduct of these meetings are designed for short and sharp sessions and with the EA perspectives on the macro view could alienate the project team. 

Enterprise Architects will always maintain a business outcomes / systems capabilities impact viewpoint, whilst the project and SCRUM masters will have a more constant improvement , business outcomes  and project deliverable viewpoint.

 




Location: London, UK

Comments

Post a Comment

Popular posts from this blog

Solution Design - Table of Contents

Image
  Today’s short blog, the first for 2024, derives from recent work in which I required a classic Table of Contents (TOC) for a Solution Design( SD ) Document/ Artefact. To create this TOC, I began by listing elements one would expect to see in the artefact i.e. primary section headers, which is challenging when you consider the ‘ purpose’ of the document, and  the target audience both of which impact the overall structure of the document. For most artefacts, it would be prudent to tailor the SD to meet the needs and challenges of the specific  problem. For example, a basic SD for a new in-house development may be very technical, especially when the target audience may be the Systems Community ( Developers, Testers, Service Management etc.) and resulting in an artefact with the content and focus on  Component Views(Building Module Blocks) , Deployment Views and the Runtime Operations .  So, when I considered the elements for the SD Artefact I wanted to create a generic TOC , on
Read more

Enterprise Architecture, Digital Transformation and ICT Strategy - Seminar Video Presented at the AUC Egypt

Image
Sharing the full video ,2hr 45 minutes, of my recent seminar delivered to the MBA Students of the American University in Cairo (AUC).  I recommend skipping 1.30-1-55 of the video as this was the break period, as the camera was left on. There is a lot of content with some great questions - hope you find it useful. Enterprise Systems Architecture Seminar at the AUC Egypt . https:// youtu.be/ztOYZYa4FcI Any questions please contact me direct.
Read more

Reflecting on Error Management and listing HTTP Status Codes

Image
Let me start by apologising, as todays blog can be considered, by some , as content of little value to support macro EA views and a topic where information can be sourced easily via the web or by using AI tools (fast becoming everyday tools). However I felt I would   share this reference type  material, as error codes are always required for those building information systems. FYI recently I had to examine various  http error codes used in  a Cloud based API management system in respect of the flows of  message exchanges and conduct analysis of non-typical scenarios e.g. a missing authentication token resulting in an invalid exchange between the backend and the API Gateway. Under normal operational conditions, interactions between two or more system will result in the exchange numerous codes which notify each system of task status e.g. a 200 return code will represents that all is well and allows the process continuation of further orchestration of a workflow to complete its task.
Read more