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:
Design in the democracy
All the planning in world does not deliver software on its own; it just makes it easier to swallow the whole solution. Sooner rather than later you must start making design decisions. Making a decision at the last responsible moment is a key concept of lean software development, and I am going to assume that you understand this concept.
As an architect, you may well be approaching new ways in which you make design decisions in that you will be involving the whole team in decision making. It is this concept which promotes self management. If you are used to making all the decisions, this will undoubtedly be a concern and a drag at first, because your team have to gain the understanding of your vision. The more group design sessions you have, the less burden they will feel, and you will gain two core benefits: a collective teams brains are bigger than your own, and you make less decisions yourself, which frees you up to write code.
There are two key points that must be addressed when conducting group design sessions: how many sessions should you have, and at what times during the sprint should you have them.
At the beginning of a project, group design sessions are likely to occur naturally much more than later on in the project. This is because there far more and greater problems that need detailed architectural thought. At the beginning of my current informal group design sessions were a daily occurrence for the first two weeks of a four week sprint, enabling the team to come to a common consensus of core architectural decisions. However, you must balance this with getting the work done, and this is where the fixed sprint cycle really focuses the mind, because you must be able to demonstrate functioning software at the end of the sprint.
Generally speaking, design sessions should occur as early as possible in the sprint, and should be iterative in themselves. Someone in your team is responsible for delivering a feature, and they must gain enough group thought to progress the feature, without the team going to into actual code during the sessions. This means they may well need short iterative sessions, where they gain suggestions to problems that require individual investigation before approaching the team again.
Group design is also essential for ensuring that the team does not work in silos and that your vision for the solution is delivered in a coherent and cohesive way. Silos of knowledge will form if individuals work continually on the same set of features and do not share knowledge, which leads to dependency of individuals and insistency in architectural implementation.
There is only one point at which group design must be overruled for singular thinking; if you feel that the overall technical vision or implementation of the project is at risk by a decision being made and you cannot gain group consensus, you must impose your view on your colleagues. It is not true that all members of your team are equal; this is a democracy, not communism. But this must be used when all other methods fail, and you feel the point is so important that you cannot go down the road the rest of the team feels is correct. I can only recall doing this once or twice during the course of my current project.