Agile Development equals No Architecture

Agile Development equals No Architecture

Agile development methodology has found a large following in the past years, and rightfully so. But it frightens me to discover that in many organisations agile development is seen as the opposite of having an architecture.

Where does this interpretation originate from?

Let’s first consider what agile development is. You can find many definitions, and a quick search on the internet reveals well over 2 million webpages on that subject.
Essentially, agile development is nothing more and nothing less than incremental delivery in a time-boxed manner with minimum waste. Now what does that mean?
Incremental refers to the way a product is developed, namely in small steps. Each of these steps (or increments) handles a limited number of objectives (or requirements). Nothing more is considered at any increment than the objectives of that increment.
Time-boxed means that each increment is done in a limited amount of time. As a consequence: no more “one month project” that remains 95% done during the coming 12 months. The time-box is usually anything between 3 and 6 weeks, and one time-box follows the other time-box in a sequential way. The time-boxes do not have to be equally large, but most prefer them to be the same time period. If you ever are in a discussion about how many weeks a time-box should be, then I advise you to: halt that meeting, take out your dice, and accept the first number that you roll and is at least 3 and at most 6, then go have a beer.
Delivery refers to the way increments are handled: each increment should produce a potentially usable product. But make no mistake: the potential installation in production of that increment isn’t included in your time-box, but can only result from a decision after the one increment is closed and accepted. This is one of the most important aspect of agile development, and should not be forgotten.
Minimal waste refers to the way agile team members are supposed to document, because in the agile credo it is stated to produce only the minimal documentation and design as the team can get away with in order to produce the intended product.

Aha, minimal waste, which is often incorrectly interpreted as “no documentation” and “no activities that can slow down development”, and “no plan”.  Remember the saying “No (battle) plan survives (first) contact with the enemy (General von Moltke)”. But without a plan, you will surely not survive contact with the enemy.

This brings us to architecture and the role of an architect. There are many architect types (enterprise, information, data, application, software, infrastructure, …), and many architects combine several of these types. The architect is the one who takes a holistic approach, the one who thinks about systems and subsystems and their relations to each other and to the world outside the current project.
And this is where the architect will indeed create the perception of a “slow down” of the project, because the architect wants to make certain that the results of the project (or the current increment of the project) will fit in within the context of the project (the other increments as well as the external world that has to interact with the results from the project).

This brings us to think about equilibrium and optimal outcome for each project (local optimum) as well as for the organisation as a whole (global optimum). If we would consider multiple projects, would using the quickest road to a product in each project, independently of external considerations, lead to the best results for the organisation? In my opinion, approaching each project as independent of all the others with only the quickest road to succes (local optimum, current project is the only focus) in mind, leads in an ICT organisation to complete chaos in the end, because each project could choose its own favorite development tools, database, technology etc… Maintenance will be a nightmare (minimalistic documentation, not necessarily up-to-date), integration will become ad hoc and complete spaghetti, security will become unmanageable, scalability might be impossible, and disaster recovery scenarios will heavily depend on all the (hardly documented) choices in each individual project.

And that total chaos, with local optimisation for each project, is as well an architecture… which seems to be a contradiction in terms.

So does agile development really means no architecture? I do believe that I can say “absolutely not”. It was never the intention of agile development to become chaotic development. The role of the architect within an agile development context is to develop the architecture for the current increment, with respect to the world external to the current project (standards within the organisation, architecture of similar projects, enterprise architecture, …) as well as internal to the current project (previous increments, as well as – when known – potential next increments).
It will slow down the enthousiastic developer who just wants to deliver some code, but the holistic approach taken by the architect is the safeguard for the organisation as a whole to prevent total and complete chaos. And that safeguards is worth some small loss in time during product development, because it results in a massive gain of time during the lifetime of the product once it is in use with the business.

 

About these ads

~ by gvanhoutte on December 19, 2010.

3 Responses to “Agile Development equals No Architecture”

  1. Dear Guy,
    Good post.
    Everything has architecture, but not everyone sees the need to formalise it. The thing is that quite often the architecture practise on itself is not agile enough. Too many architecture “endeavours” are characterized by an ivory tower mentality, far from reality, and based upon big bang, top down approaches.
    This leads to failure. EA should be incremental, bottom up, step by step (or should I say “sprint by sprint”). That is what we evangelize at http://www.BVGITServices.eu
    The good architect lives in the projects and assists projects in delivering the right outputs.
    Best regards,
    Bart Van Geel

  2. Architecture doesn’t need to be exposed, everything has it own unique architecture

  3. Agree with you here. Agile doesn’t mean “NO” architecture. It’s taking a whole approach to it. Building with architecture in mind.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 42 other followers

%d bloggers like this: