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:
From the vision to the starting block
For all I have written so far, you may be under the impression that Agile means you don’t write design documents, and you don’t worry about process. This common misconception is a myth. The process is lightweight, but this makes the process more potent in some ways because it is easier for the team to stay true to. You still need documentation, but you should not produce any more documentation than you need.
So, at the very start of a new project, before the development team is even formed, how much architectural work should you produce? This is a common question, and there is no single answer, but a key variable in deciding how much initial design work to do is technical complexity.
Breaking down complexity was why you used to write all those up front design documents right? Well yes, but you have to ask yourself how much of those documents lived beyond the first month of the development. In practice detailed design documents do not stand the test of time. You have to balance breaking down complexity from getting into detailed explanation. It is important that you have previous experiences that mean that you do not feel the need to dive into the detail of the problem.
Dissecting complexity should be done at the conceptual level. By this, I mean running through tasks such as extracting design goals, and concentrating on understanding the business requirements and breaking these down into manageable chunks. These chunks must remain relevant to the business, or if the task is a purely technical item, its relevance to supporting a business requirement must be explained (and understood) to the product owner.
What is meant by the vision? Firstly, you have gain a grasp of the breadth of the product backlog and the key technical design goals. As an individual who is used to providing solutions, by this point you should have hundreds of potential solutions running around your head. You must resist temptation to opt for any of these. This is part is the tactic to delay decisions until you need to make them. However, as you conclude your envisioning work, you should begin to feel that the problems are cementing in your mind and that you have some likely technology candidates that you will employ.
You should concentrate more on the items of the backlog you are most likely to tackle first. At the start of the project the product owner is likely to have so many essential business features that they may not be too concerned about which one of these you want to pick first. You should be concerned about reducing risk at the earliest point possible, so out of these items that the business most wants, pick the item(s) that you feel are most technically challenging and focus more of your effort considering these requirements.
For all I have mentioned so far about doing this initial vision work, I have not mentioned the business reality that you face. Ultimately you must do at least enough envisioning work to ensure the business trust that you have a handle on the whole solution, and that you have a commercial idea of how big the problem is. The key word here is trust, which is a very important part of any work done to start a development project. The business will need be gain confidence that you understand the problem enough to start the project, but you should not go down the road of writing down detailed design specifications or requirements gathering.