Note: this is one in a series of posts under the category of “agile architecture”.
In the last post, (Six Principles of Agile Architecture) we identified six principles that can help us reason about the challenge of architecting systems of scale in an agile enterprise.
In this post, I’ll describe the first principle of agile architecture: the team that codes the system designs the system. This principle is driven both by the manifesto itself, (ie: The best architectures, requirements, and designs emerge from self-organizing teams) as well as another of the primary philosophies of agile development, which is that the teams themselves are both empowered to achieve, and accountable for, their delivered software.
From a management perspective, in order for teams to be held accountable, it naturally follows that we must allow them to make the decisions necessary to support that accountability – otherwise they are essentially being held accountable for decisions by others and that is neither an effective or motivating model for team performance! While this seems axiomatic, the reality of our behavior in earlier practice was somewhat different as the figure below shows.
This paradigm was further compounded by our time-sequenced waterfall activities; I.e. there was typically a single, up-front planning phase intended to accommodate the inherent risk of the project, perform all the necessary design and predict sequenced task dependencies running as far out as a year into the future. This phase was decoupled in time from the lessons learned in actual implementation and, once the lessons were learned, it was too late to do anything to the schedule (other than to apologize for the fact that we couldn’t meet it.)
Further, from a technical perspective, these architectural decisions are most optimally made by the coders, tech leads, team architects, etc, as they are closest to the implementation and therefore often (but perhaps not always as we’ll discuss Principle #6 – System architecture is a collaboration) have the best data available to make such a decision.
The combination of these two factors:
1) they will likely make a more optimum decision, and
2) once made, since they are accountable for the results, they will likely work a lot harder to make their decision work in the implementation
delivers a big part of the power of agile and more than warrants our first principle: the team that codes the system designs the system.
I’ll describe the second principle: Build the simplest architecture that can possible work, in my next post.