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 business driven backlog to software features
Sprint one, day one and the whole development will undoubtedly feel pretty scared at this point, particularly if they have not worked on an Agile project before (which is likely). As the technical lead, you must shepherd the team into being self managing and enable them to work off items from the backlog as soon as possible.
The ultimate goal of an Agile team is that the team is self managing and functioning. You must get the team to this position, but do not expect it do happen over night. In reality, you will start the project with at least an element of command and control, and you should slowly relinquish this control over the team as they gain an understanding of the requirements and the vision that you communicate to them and get used to the Agile way of working.
Once you have effectively communicated enough of your vision and the requirements for the sprint you are on, your first practical problem is breaking down the product backlog items into sprint backlog features. This dovetails into the concepts of feature driven development, where the team delivers a sprint backlog of product features.
If this is your first Agile encounter, the chances are both you are everyone in your team will not effectively break the backlog down to the appropriate level of detail. You must learn the correct level to find here; too little detail will make the backlog meaningless from solution perspective, but too much detail will mean you spend far too long working out the items on your sprint backlog rather than delivering code.
One very common mistake when breaking down a backlog is to break it down into technical tasks, rather than business features. This commonly referred to as “breaking the tasks into horizontal pieces rather than vertical slices”, meaning that the developers will be thinking about the individual development tasks which make up the horizontal slices of an architectural pattern, rather than the vertical slices of functionality. Working with horizontal tasks means that the team will find it hard to descope, because when time gets tight in the sprint, there will be no features you can descope because no features will have been fully completed.
Working in a feature driven way will in itself bring discomfort to a new team who is not familiar with the requirements or the vision. Practically, the beginning of a development, you are at the foot of a mountain which you must climb, and no matter which way you approach it, the problem is daunting and hard. What the team will learn over time however is that working on incremental features within a scope of a clear vision helps break this problem down into manageable steps. This will be part of the whole team’s epiphany to adopting an Agile working practice.
One final point to make about breaking down the sprint backlog is that teams often feel at first that committing estimates and tasks to a board (and those tasks may well be vague) is itself a one off job done only during sprint planning. Team members may feel uncomfortable committing to estimates, because in a waterfall approach, this means that the estimates do not change once they have been written down and people are responsible for what these numbers say. You must communicate to your team that these tasks and estimates can and do change on a daily basis. Do not get hung up on having undefined tasks or accurate estimates; clarity will be gained as the sprint progresses and as estimates change you may have to descope (or introduce new items to) the backlog. In my experience, overall fluctuations in estimates seem to balance themselves out into roughly the same estimates as the higher level ones given for the product backlog.
Part 4: Conceptual design and decision making