Are Enterprise Architects in conflict with Agile?

Someone recently asked me an interesting question, “Rafferty, doesn’t your role as an architect conflict with your role as an agile coach?” “Tell me more,” I asked. “In agile, the architecture changes throughout the sprints. This makes it hard for architects to design things at the beginning as it won’t be followed in the end.”

Excellent point.

Evolving Architectures

Let’s be honest, no matter how detailed your architecture design is at the beginning, that architecture won’t be 100% the same when the next major product version is released – regardless of the methodology that you are using. Therefore, A good architect needs to find the right balance between the critical decisions that must be made at the beginning of the project and which areas simply need a loose structure for now. Overdesign a waste of time and leads to delivery delays and confusion for the rest of the engineering team. The key to a good design is identifying which areas need to be clear and concrete and which areas need to be loosely structured until more is learned.

One of the key software principles here is YAGNI (You Ain’t Gonna Need It!), only design for things you know you need, not on things you THINK you will need. We do not need a perfect architecture in the beginning (it’s also impossible to do so.) In a way, good early architecture is a “good enough” architecture for the team to proceed with minimal risk of rework.

Finding the Right Balance: Engineering Velocity

The public cloud has blurred the lines between infra, app, data and security architectures. Because of this, an enterprise architect should consider individual team capabilities and how the different teams collaborate. This leads me to engineering velocity.

Engineering Velocity (EV) is the organization’s ability to drive digital transformation through systems and software engineering.¹ It is the collective velocity of the entire engineering team (developers, infra engineers, data scientists, operations, etc.) to deliver engineering outcomes that lead to business results. Regarding architecture design, EV is the team’s ability to make the necessary architectural changes as more is learned.

Here are some of the questions I ask while working on an architecture design:

1. Is the development team following agile or waterfall practices?
2. When we say agile… what does it mean? Do we still have full-time project managers and testers? Can the developers easily approach the product owners to clarify things and show work-in-progress items?
3. Do we need “special sprints” dedicated to testing activities (UAT, regression testing, etc.), which will affect sprint planning and the release branching strategy?
4. Is the infrastructure team skilled in infrastructure-as-code (IaC)? How are they with Git Repos?
5. Can the data engineers work with a code-first approach (and also use Git), or do they primarily modify things directly (through SQL Server Management Studio, Azure portal, etc.)? Better yet, can they use ORM frameworks like Entity Framework or Hibernate?
6. Can the operations team write playbooks to handle alerts automatically?
7. What is the culture when it comes to ownership of production issues? Do the development and operations teams work together, or do they blame each other?
8. What is our current DevOps toolkit, and what else do we need?
9. If the team is not co-located, do we have the collaboration tools and security measures necessary so that the team can work remotely and asynchronously?
10. Are there contracted partners in the team, or is it entirely in-house? What is the delivery impact when there are changes in the design? Do we need to file contractual change requests with the partner?

Accelerating the Team’s Engineering Velocity through Retrospectives

One of my favourite things about Agile Scrum is the culture and mindset it creates amongst the developers through the regular sprint retrospectives. My Scrum trainer, Bas Vodde from Odd-e, taught that as the development team retrospects on what worked and what can be improved during the sprints, the team’s Definition of Done (DoD) scope should expand over time and increase the sprint velocity.

Definition of Done Scopes²

What a transformative practice! Wouldn’t it be great to apply this to the entire engineering team? As enterprise architects, also think about how you can influence the team/organization to do regular retrospectives. This way, infra engineers who do not know IaC and data engineers who can’t work with Git can start with their current capabilities but have the growth mindset of learning and being capable over time. Creating this culture of growth is key to accelerating the organization’s engineering velocity.

References

1. my definition, inspired by McKinsey’s Developer Velocity and my experience in agile delivery and support operations ↩

2. This image is from the 2008 Scrum Master training that I got from Odd-e ↩