Paul Hinks' Blog

I re-read my recent post on agile development and I think it sounded rather more negative that I intended. I don’t wish to give the impression that I am opposed to agile methodologies – quite the contrary. I don’t think I’ve ever worked in a development environment that I would not describe as agile – I think that kind of approach is the norm in Silicon Valley, where I have worked almost my entire career. I think the large corporate IT departments are the ones that embraced the waterfall, highly structured and inflexible approaches that agile methodologies (henceforward referred to as simply ‘agile’ or ‘am’) is advocated to replace, and I would never advocate that approach. Having said that, I think there are different ways to implement am and different reasons for doing so. I have seen them introduced in four companies, and only in one was it done for the right reason and in none was it a classic replacement of waterfall methods.
In the first case, the company was failing and in an attempt to find a scapegoat the development team was deemed to be “out of control” and so a project manager attempted to rein it in by imposing agile on them. This was a complete failure because the development team was in fact doing a great job, and resented being bullied by someone who turned out to be too controlling and ultimately incompetent. The company eventually failed, certainly hastened by the departure of most of the development team who refused to buckle under.
In another case a new manager was hired to run an existing team, and in order to make his mark he also tried to impose agile methodologies, again in a way that increased the reporting and meeting burden on the developers and caused resentment and dissatisfaction. That team also started to disintegrate but thankfully the new manager was replaced before any real damage was done.
In the one successful case, the development team did not really change its approach at all – they had been used to working on short-term projects, and were releasing daily updates to their product. The change really applied to the project management and executive teams who learned whole new ways to communicate. They used the story approach to better define their requirements, and were able to understand the scheduling impact of their projects and to gain insight into the development process by becoming more involved in the planning and estimating processes. And of course they got to see exactly how things were progressing by turning up at scrum meetings.
So I think the moral is that a successful agile process allows everybody space to do what they do best, without any power struggles or imposition of one group’s will onto another’s. And mostly, I think it often requires a change in mindset of the customers more than it does the developers.
Oh, and the prayer meeting thing? It’s probably just me, but when I see a bunch or people standing in a room round a table, often with heads bowed, it’s not a rugby match that comes to mind.
[ad#co-1]