The Agile Architecture

There are some big graphs, so I published the google doc as well (it looks better): http://docs.google.com/View?id=dhpj7455_67gkwk3bfr

When I started with my first Agile project, I just knew I liked it. I felt better working this way, I felt that we delivered better results. I was thrilled by the quality of the code, I felt good with my team mates.. But they were just feelings. I couldn't explain why. With the excuse of having to complete my MsC thesis, I decided to keep investigating and learning about Agile, . I went to my first Agile course (hey Matt, it was cold in that room!), kept working in Agile projects, read some books, blogs, forums, went to some Agile conferences, became a Certified Scrum Master (wow!) and started having Agile friends :-).


So after 4 years, what is Agile? Well, what I can tell is it is not a methodology (Haven't you read at least a post that starts with "The Agile methodology..."?). The most accurate definition I have is Agile is a set of values and principles listed in the Agile Manifesto... But probably, this manifesto has too much knowledge condensed in a few words. In this post I want to define the Agile architecture (yes, this is upfront architecture!). What I mean by architecture are what I considered the most important components in an Agile development team (I am a developer, so it is from a developer's vision).

This is what I came up with:

First, I defined what I consider the most important objective of Agile: being able to deliver value sustainably, with the required quality and in a changing environment. I did a post recently in which I list why Agile provides better value.

Then I tried to list the most important components and after having them, I tried to categorize them. I think there are 3 categories:

1) Components related to the technical field. I am a developer and so I believe these components are really important in any software development team. Inside this category, I put 3 main components.

    a. Simple Emergent Design: being able to evolve the design in every iteration is crucial to being able to deliver a continuous flow of value. This component is a consequence of doing iterative and incremental development, and relies on having automated tests and keeping the code clean via opportunistic refactoring. It also relies on having the latest code base at all times (continuous integration).

    b. Technical Excellence: this includes opportunistic refactoring, clean code and ruthless automated tests. This component is big as its importance to successful agile teams as it supports doing evolutionary design, it allows to adapt to changes and it supports having a process that relies on having a lot of information on the code itself. 

    c. Continuous Integration: This is a small component that supports other components such as technical excellence and emergent design.

2) Components related with the process in place.  

    a. Light Process: Agile needs a process that allows to "welcome change, even late...", a light process that reacts and adapts to change. The ceremony and the artifacts should be the minimum that allows to coordinate the project at hand (otherwise is hard to turn). The process should encourage introspection and optimization based on it (kaizen). To accomplish this, Agile relies on a self organized but very disciplined team and the software engineering practices included in the Technical Excellence component.

    b. Incremental and Iterative Development:  I am not sure if this component should be part of the light process (probably yes). Anyway, I wanted to stress the importance of having a process where development is performed iteratively and incrementally. 

    c. Self-organized & Self-disciplined: Agile relies on a team of committed and passionate software engineers. Maintain technical excellence relies on a lot of discipline. Self-organize successfully relies on human components: good communication among all team members and the will to collaborate.

    d. Transparency: The process should encourage transparency. Transparency improves collaboration and allows to reduce the number of needed artifacts.

3) Human components

    a. Collaboration: All team members, whether in the product or development side, collaborate with each other. Success is measured for the whole team that participates in the project, not by sub-team or individually. If there is good collaboration, there's no need for artifacts that just have the purpose of make someone responsible and the process can be lighter. 

    b. Communication: The flow of information among all members should be taken to the maximum (possible) as members with more and better information translates into improvements in the results.

These are the areas where I would map the Agile values:

And the Agile principles:

Final Thoughts

I am not sure if this makes sense or not. I know making this exercise allowed me to visualize what components an Agile development team should have. I've been following some threads where they discuss what is missing from Scrum and started wondering: Is there a methodology that follows all the Agile principles? Is it straightforward to map all what is needed to make an Agile Development team from the Manifesto? (as I said before, the Manifesto seems to contain the conclusions of many years of experience of these guys). I am also interested in Process Improvements Frameworks and so I was wondering whether it would make sense to define (as CMMi does) the Agile process areas (what I called components here) and the suggested practices in each area? I am not sure about this..When you are in the Shu level, you need to follow a methodology to start. Perhaps something like this would allow to choose the methodology or know in advance what needs to be addition to the methodology to "comply" with the Agile values and principles.