The importance of Software Architecture in Agile projects

Last week I gave a presentation on agile project management. One of the talk's main points is, that software architecture and documentation are very important even in agile projects. That’s contrary to popular belief since many people seem to follow Dilbert’s paradigm “no planning and no documentation – just start hacking and complaining”.

My argument refers to the accumulation of technical and business related knowledge in the project. The project begins with a minimum of knowledge, and while the teams works, develops and releases it also gains new insights and new wisdom about their technical and their business domain. At the end of the project’s duration they end up with a maximum of knowledge. Conversely, the risk of making wrong decisions (based on false or deceivingly true knowledge) decreases with time (s. figure 1). That is the case with nearly every non-trivial software project.  

Unfortunately, in traditional software projects mostly all of the decisions are made in the early phases of the project, when knowledge still is insufficiently low (s. figure 1). That's why early decisions run a high risk of being wrong. Consequently, most of these projects are doomed to run into trouble. 

In agile projects on the other hand, decisions are distributed more evenly over the projects timeline. As the saying goes, they are deferred to the “latest responsibly possible moment”. Thus, we have decisions in all stages of the projects (s. figure 2). Early decisions need anticipation, since they always involve some guesswork about what e.g. the customer might expect or what the future market might look like. Later decisions need adaptation, because they can alter earlier decisions or even involve some remaking of the software.

Therefore, both methods – anticipation as well as adaptation – are needed to manage projects, and especially in agile projects. Both have to be in some balance (s. figure 3). But – and this is my main point – in order to enable the team to anticipate and to adapt, the project needs a solid base, which can be established only by correct documentation, sound software architecture and low technical debt.

E.g. software architecture is needed for both: anticipation and adaptation. If you anticipate some future demand (let’s say, lots of data) you may decide to include a bigger and more scalable database. This is a anticipating architecture decision. Likewise, if you have to adapt and must change something in the software, you’d desperately need a stable architecture, because if it’s not, your software might break through the change, or the change might not be possible at all. Thus, we can see that software architecture is at least as important in agile projects as in traditional, if not even more important.