I have no formal training or qualifications in Agile as a development methodology, but it’s something I’ve tried to smuggle into various bits and pieces of work I’ve taken on in the past. Why? Because on the surface it makes so much sense and is in harmony with the way web projects usually work out in practice, in my experience.
The politics of doing this within a traditional waterfall methodology have occasionally gotten mildly interesting.
But that’s OK, because the project outcomes have invariably been well received, and not only by upper management but by other team members as well.
And personally it’s a whole lot more satisfying. It beats the crap out of all that paperwork, meeting time, planning, Gantt charts, reports, rigour and overhead that seems to go with waterfall. It feels like a much better fit for the nimble environment that the web is, where you’re generally expected to go from A to B in something of a hurry.
So Tuesday gave me a whole lot more methods and techniques for – managing? no, guiding – web development projects, and containing or smoothing out some of the issues that invariably arise on the way from go to woah.
It’s given me better structures and tools to work with in the future, and a better case to put for the inclusion of Agile techniques in web projects when traditional waterfall is often the default methodology.
Scuttling back to work on a drop-dead beautiful Wellington evening, I had a chance to think about my two major takeouts from the day.
The first was the intuitive appeal of the Agile approach. It came from a slide that Jackson put up early in the day, which overlaid the natural human thought process over the rigid structure of the waterfall methodology. Here’s my scribbled notes from that slide:
The regular, waterfall shaped line is the unbending, sequential path the waterfall process takes on the way down from identifying the problem through to implementing a solution. The dotted line that jumps (seemingly haphazardly) between the problem, a knee-jerk solution, revisit the problem, other solutions, alternative design options, ways to implement them, back to the problem, and so on all the way through the project is more like how people think about things. I do, for sure.
With waterfall, it’s sooo easy to get blindsided by process that you lose your focus on the original problem. When you’re up to your arse in alligators, etc…
The Agile model accommodates the way people I think far better than the straitjacket of the waterfall methodology. Isn’t it just so much more intuitive? Won’t that result in better thinking and better outcomes? Better usability, and better ROI?
Speaking of ROI, my second takeout came from renewing an acquaintance with Sandy Mamoli who’s an Agile advocate and a certified Scrum practitioner. Here it is, and I invite you to read it. Enjoy.