Qcon San Francisco is less about coding and more about architecture and the development of larger systems. There is also a track on agile development, since how software is developed matters.
Pre-conference Tutorial: David Anderson’s ‘Zen of Agile Management’
About the presenter: Mr Anderson has been closely involved with FDD and MSF and leading a number of teams at big companies before, no surprise, set up his consulting practice. He also maintains the Agile Management blog. His PR photo shows him as outgoing, wide-smiling, yet he’s more laid-back, low key and wry-smiling. Think British not American.
The theme of the day-long class is straightforward: bad management breaks software development more than anything else. That it does is practically a truism: making decisions without enough discrimination and knowledge breaks anything, not only software development.
The emphasis is on ‘more than anything else’. Albeit not perfect, the agile approach, practiced sensibly, performs well enough so that the hot potato is no longer with the developers themselves. It is time to fix the act of managing development and yes, given the human nature, dealing with the programming methodology was the easy part.
Most of the morning session was an introduction of agile management, of most value to those new to it. I will skip the details since they are part of the daily routine at Intelliware. Some tidbits recorded while repeatedly trying to get a photo with the very word ‘management’ projected across Mr Anderson’s forehead:
- When tracking defects and functionality against time, the sweet spot for the iteration length is about 2 weeks (before defects start to increase more than the functionality)
- Introducing change, especially change in management, is met with resistance and a top-down approach, even from the very top of the pyramid, doesn’t work. A better approach is to not brand the change as such, but try to find the problems and fix them. Do this for a number of them and, if you look back 6 months later, what you did was … change.
- The caveat of knowing you’ve improved things: when metrics are available, there is a risk they will be misused (the risk increases if the current management practices are dysfunctional). Track the number of bugs fixed in a week and they may end up as reports broken down by developer.
The afternoon was consumed primarily with risk management, iteration planning and why prioritization does not work well in the real world (too many stakeholders with different personal priorities lead to too many must-haves. A more detailed discussion is at his blog, it is of interest mainly for product teams in highly competitive markets). The final part of the class focused on how a team at Microsoft was turned around and became productive again – once more, relevant more to product teams.
- The slides. Perhaps Mr Anderson’s time spent at Corbis played a role, but plastering the text content over a stock photo for almost every single slide and using fluorescent and fully-saturated colours for the others is distracting and would send Tufte into a cringe. Type some white text over pure green (R=0, G=255, B=0) to get a sense. It is not just a matter of visual taste, but of relevant information transfer.
- The title. “The Zen Of …” has become very clichéd. Pirsig’s book book is fantastic and quite relevant to software craftmanship in fact, but clichés are not and nor do they go well with agile.
I think the class is useful overall. A day is too short, though, for anything but getting an idea. Try his book to learn more (did he mention a second edition being in the works? I am not sure).
The hardest part, also the topic of a brief chit-chat with Martin Fowler after the opening keynote, is whether today’s organizations can change without waiting the fabled generation. There is no answer.