Agile a double-edged sword for Developers | January 7th, 2008
Scott Sehlhorst, as always, has some interesting insights into the software development process. He argues this week that Agile is sometimes used by developers to hide or absolve themselves of responsibility, but that the opposite is true. Agile actually increases accountability by preventing a ‘throw it over the wall to QA’ culture and by promoting developer ‘ownership’ over features and quality.
Read the full post here.
I’ll admit that I’m not an Agile expert and I don’t understand a lot of it yet, but in a recent project I saw this responsibility-dodging behavior on an Agile team, and I think the culture of supremacy of developers over project coordinators preventing anyone from calling them out. The scrum-model is a short rapid-fire way of tracking team progress, but the flip-side is you get the perception of transparency but in fact only get a surface-level view of what the developer is actually doing. When things are not going right in a project, developers are able to cut features and push timelines, unfairly shifting the burden onto project coordinators who then have to deal with the client. The failure of the project coordinator in this case was that they didn’t notice or seem to mind that the developers had the same goals day after day and didn’t make progress. What’s funny is these people would rephrase their goals each day but say exactly the same thing. That’s a fault of the coordinator, not the model, but even if they did notice, what could they really do about it. In a room full of many people who is going to step forward and say ‘hey! you’re full of crap!’ 
January 7th, 2008 at 8:36 pm
Great article. For one, I would stand up in front of the room. Although I have found it to be more effective to work with development managers and individual developers. The backlog for a sprint (or release, if not scrum) is defined as a function of prioritization and estimation. If the development team is consistently missing their estimates, you have a problem.
If you choose not to address it, that is certainly not an issue with the methodology. A waterfall method only provides the opportunity to obscure the problem (I’ll run over on X and make it up on Y). At the end of the waterfall, the project is proportionally delayed – which is a much bigger problem, with little or no means to address the issue.
Think about it from a project management perspective, ignoring the development methodology (or even the fact that it is a development schedule). The earlier that you know that your schedule is slipping, the more you can do about it.
You’re exactly right to blame the coordinator for sticking his head in the sand when a team behaves as you describe. But that doesn’t absolve the people who are failing to meet their obligations – and that is a cultural problem. Developers need to be expected to be held accountable for their estimates.
Scott “standing up in front of the room” Sehlhorst
January 10th, 2008 at 7:37 pm
Thanks Scott, I agree that at the very least the coordinator should be able to detect slippage and see where it’s happening. Sounds like the blame can be evenly spread in a situation like this.