Abstract
This blog covers my own experiences of architecting within an Agile project. It assumes you have knowledge of an Agile process such as Scrum and have knowledge Lean engineering practices.
The blog is split into five parts:
The epiphany
Beginning your first Agile project is a daunting prospect for any developer, but none more so that than if you are the technical lead on the project. If you are an experienced architect, the chances are you have battle scars from previous projects, with dozens of development experiences to draw on. And more often than not, you are also familiar with “formal” project approaches, either through waterfall based methodologies like Prince 2 or more iterative approaches like RUP.
If you do have experiences using these methodologies you know that these ways of working can and do work. You might be comfortable using them – in fact you might even like the processes. So why should you change your way of working? And what has changed in software engineering that makes this change possible?
These are some of the questions I had when I started my first Agile project. The overall feeling I had was one of real fear; I had an extremely complex set of design goals to meet, with new technologies to master, and the last thing I wanted to concern myself with was a new way of working. I was an old dog who didn’t really want to learn any new development process tricks.
If you are used to formal processes, then part of the fear that comes with taking an Agile approach is the thought that many processes you trust and feel necessary are not required. In formal approaches, part of the architect’s job is to produce a conceptual design up front. Taking an Agile approach means that the design documents you are used to writing are no longer required; you will work on the design iteratively and moreover not exclusively.
It takes a leap of faith to move away from the formal way of working. And in reality, you will have to take this journey yourself. Only you can convince yourself that all the design documents you cherish are in large comfort blankets that make you feel more certain that you have a grip on the problems you need to solve. And you will be convinced when you see Agile development processes working, although this epiphany may not be immediate, because ultimately, software development is a difficult art and it takes time to get things right.
Before I cover some areas of my experiences architecting in an Agile project, I think it is important to put Agile into some context of software development as a whole, and also try to answer why I believe software development started out as a waterfall persuit.
Firstly, Agile does not deliver software; teams of good developers, testers and analysts deliver software. I say this, because I feel that when a new process gets adopted by a team, it can be all too easy to lose sight of the fact that ultimately your first concern is the code and not the process. Because Agile is lightweight by nature, this is much less of an issue than it was with another process such as RUP. I have worked on projects using RUP in the past where the process began to dominate the project. This should never be the case in any development; the process is merely a tool.
Finally, there is the question of “why haven’t we always worked this way”. I believe one of the core reasons for this is the advances that have been in productivity using better software engineering processes and development tools. Processes such as continuous integration mean that the cost of producing continuous iterative builds is much reduced. This is a task that would have consumed a whole developers time for the length of a project not long ago, but my automating this task, the burden has been lifted. And productivity improvement to tools, such as Visual Studio 2005 means that the cost of quickly changing an architecture retrospectively have been greatly reduced, due to refactoring tools and class designers.
Part 2: The vision to the starting block