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]

Every company I have worked at for the last 5 years has tried to implement some kind of Agile development process. It seems to be the new mantra, the silver bullet of software development, similar to the way Object-Oriented Programming was ten, no wait fifteen years ago. Of course OOP was a development methodology and Agile is more of a management process, but that in many ways makes it more appealing to managers since they can understand it better. Each company I have seen seems to have taken different parts of the process and incorporated them in different ways into their existing process. All have had some kind of meeting which they called a scrum, usually an existing meeting with a new name. Most have instigated “sprints”, usually of 2 weeks, to implement suitably small pieces of functionality. Usually the enthusiasm wears off fairly quickly, often when a major re-write is required or something else that doesn’t fit the model and daily meetings are reduced to people repeating the same thing every day for weeks on end. Which is fine by me. I’m sure the whole Agile thing is perfectly appropriate for some sub-set of environments and projects, but for those that it isn’t it’s really painful to try to make it work. And I really dislike doing something because somebody thinks I ought to be doing it. Plus it makes me feel like a Toyota factory worker singing the company song in the morning. I don’t think the development process at any of these places was broken before they were “agile”, and I don’t think any of them were significantly better while it was. If a project is well managed and the lines of communication between different stakeholders are open (which they should be) then a project is generally successful. If it isn’t and they aren’t then it generally won’t be, and it will take more than a few buzzwords to fix it. Keeping a team lean and focused is important, if you have to focus on that then go ahead and implement Agile. If you’re already lean and focused, and delivering, then it ain’t broke – don’t fix it.
[ad]