Running Agile

I often find teams having a hard time with the idea of emergent architecture, even so called long time agile teams.
The question of emerging vs up front architecture has some roots in the philosophy teams follow to manage their planning.

How is that? Many agile teams have switched from waterfall project management to some flavor of iteration based project management. The important word here is that those teams are still working in a project management environment as opposite to a product development environment.

The difference? Projects are remnants of a time when decades ago companies were developing their applications through consulting companies as one off solutions. Projects have a start date and an end date, and stop when finished. In product development, we have a start date and hopefully never have an end date. Great products or their variation can stay on the market for dozens of years (I’m not saying by any means that product management doesn’t drive to dates – release dates are here for that).

How is that pertinent to emerging architecture? Teams that still have a project mentality (with an end date) tend to want to define architecture in advance. Teams that have really embraced product development (i.e. the continuous improvement of a product to serve their customers) tend to use emerging architecture. In project thinking, up front architecture can work well. Project over, next project. But how does this apply to product development thinking? What happens the first day of the 2nd release cycle? Will the team re-architect the whole thing from scratch? What about after 10 years? I believe building successful products with longevity requires mastering emerging architecture. This can only be achieved by frequent practice (constant refactoring). And the better time to start this? From the very beginning, when complexity is null.

As Allan Shalloway puts it, “The purpose of architecture is to minimize the effect of changes. Creating an architecture too soon has the following risks: 1. Over-building the architecture which leads to complexity 2. The temptation to trust the architecture instead of code quality (which always needs to be maintained)“

A third risk I want to add to this list is that early architecture assumes a range of possible changes. With time, the chance for a need not covered by the core architecture grows. It’s a matter of when; not if. With the need for large refactoring and absence of practice is often the death of the product; even the greatest.

The philosophy of deferring commitment for dealing with the unknown has successfully enabled the most difficult journeys. Alan Hubert, planning the longest ever crossing of the arctic basin by foot and kite would not disagree:
“Much of the [Arctic] traverse will be on sea ice, which is always moving. It’s impossible to know what will happen in the coming hours. But as soon as we get to the ice cap on Greenland we expect to sail
[across the ice] quite a lot. You quite often get bad weather, but it’s good because then you get the wind.”