Is there still room for architecture in an agile engineering organisation? Of course there is. There is a perception that agile teams are self-contained groups of generalists who should be left alone to self-organise and build software. This is true, but development teams still need to make architecture decisions all the time. There does come a point at which problems are too big for any one self-organising team to solve. Some design co-ordination is needed.
20 September 2016
Three-lettered acronyms can be a useful tool for providing brevity, but they can also give rise to a coded language that contributes to a cold and impersonal development culture.
22 May 2016
Technical excellence is one of those slightly nebulous phrases with many different interpretations. In an agile context this means removing constraints and it is more than just a team responsibility.
5 May 2016
How do you organise code ownership for services that do not align conveniently with team or organisational boundaries?
12 March 2014
Agile principals encourage self-organising teams to take ownership of solutions. This doesn’t leave architects out in the cold, but it does require a more engaged role based on influence rather than governance.
21 February 2014
Deferring decisions to the “last responsible moment” can help you to adapt to the inevitable uncertainty that comes with agile development. The risk is that it can become an excuse for uncertainty that undermines development velocity.
12 August 2013
Agile does not necessarily lend itself to management reporting. The few metrics it exposes are designed to support internal planning rather than external measurement. It can be tempting to re-purpose velocity as a measure of productivity, though this will only distort team planning without saying anything meaningful.