Add to Google
Agile Architecture Principle #1 – The team that codes the system designs the system
Posted on April 3, 2008 by Dean Leffingwell in Agile ArchitectureNote: 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.
Great thoughts and definitely agree with your perspective! That said, I want to provide some thoughts from a perspective where culture may not enable the solution you provide in any easy fashion.
We tore down a very structural waterfall process and organization. Now, we are reliant on teams that in theory are viewed as very capable but in reality, lack the experience to truly develop the intentional architecture we need. We are running into two general problems
1. Individuals are solid in coding fundamentals but not experienced enough to develop the complex infrastructure we need. In addition, these individuals are generally regarded as junior and/or less knowledgeable
2. Individuals are solid in “planning” and “design” (previous architecture group) but have been away from coding long enough to lack the experience to code in an agile manner that enables refactoring, etc. These individuals are generally regarded as the best of the best
We, the agile enbablers, see the disconnect but convincing everyone else that will help influence a true change is a different story. This puts us in an interesting “burden of proof” situation that unfortunately slows down the agile embracement and most importantly, the true “proof” that agile can work at scale.