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.