Years ago as a developer working mostly solo, I got interested in automated testing and unit testing, which in turn lead me to extreme programming (XP) and agile software methodologies. I've had the wonderful good fortune of working for Pivotal Labs a number of times in recent years and been a part of a number of successful agile projects. I know that an agile approach to project management can work well in many situations and I think I have a good understanding of how and why. But I'm not an agile zealot -- agile isn't appropriate for every type of project or organization and a good team can usually succeed using any process. Still, I think working on an XP project is more fun and rewarding for everyone involved.
I've talked with many developers who range from agile skeptic to agile detractor. They often react negatively to a particular XP or agile practice, with pair programming and unit testing being the two most common ones. Some developers are drawn to programming because they get great satisfaction from grappling with interesting intellectual challenges in solitude; agile doesn't have much to offer an individual developer when this is their top priority. If you're this kind of developer and you've found a place that gives you the freedom to work solo on cool stuff, more power to you!
More often, I talk to developers who recoil from the dogmatic pronouncements of agile proponents.
Software developers are a funny bunch. We are prone to seeing the world in very black or white, zero or one terms, and we generally have finely tuned bullshit filters. We prefer a world that is rational, measurable and repeatable to one where truth is determined by politics, personality and political correctness. When confronted with admonishments to pair program, write unit tests, use Pivotal Tracker or pat your head while rubbing your belly, we ask, "Why?" All too often, agilistas respond by implying that you can't possibly succeed in software development without doing all these things, and more: this is just padawan stuff, just wait 'till you become a full-fledged Jedi! At this point, the bullshit filter is engaged and anything that smacks of "agile" is permanently tagged with bozo, to be called up later when a target for ridicule is needed.
That's a shame, because agile methodologies like XP and Scrum really aren't about writing software, but about managing complex projects where the goal is to build something unique and novel. And it's a rare software project that doesn't have uncertain requirements, technical risk, deadlines and limited budget. Software project planning and management is far too often dominated by the politics, personality and political correctness that software developers eschew. The core idea of agile methodologies is to turn project planning and management into something more rational, measurable and repeatable. Blanket prescriptions that you must write code a certain way, use a particular tool or hold certain kinds of meetings aren't helpful; in fact, they can be actively harmful to a functioning development team.
Mike Cohn (the author of one of my favorite books, Agile Estimating and Planning) made a New Year's resolution to "Make recommendations not rules". Mike lays out his view of the core rules that make a software development team "agile" in his eyes. It's a short list, just five points, but it gets at the heart of good project management, whether you call it agile or not. "Beyond that, it’s much more about recommendations," Mike states, and I agree.
If you're an agile proponent, try to keep in mind that each team's pain is unique, and there are many different paths to success. User stories or planning poker may be the shiny new candy to you, but most people just want to get their work done. Pushing strange new techniques on people and organizations that are unready or unreceptive is ineffective at best and counterproductive at worst. Making sure the right people are having the right conversations at the right time is at the heart of any successful project. Agile methodologies like XP and Scrum are frameworks for making this happen, but they're not the only way. Avoid agile purity tests, adapt to local circumstances and prefer recommendations over rules.
Posts
No comments:
Post a Comment