by: Joanne Wortman
I like to cook, but I’m not exactly a purist. By that I mean that I almost never follow a recipe exactly. Instead I treat a recipe as more of a guide. Sometimes I omit ingredients that my family doesn’t like; other times I add in ingredients to see what the affect will be. I often combine a couple of recipes together, mixing and blending ideas from several sources. Sometimes the result is a wonderful creation that suits the tastes of my family. Other times, we take a bite and reach for the pile of take-out menus.
I find myself taking the same approach to development methodologies. Like most of you, I find traditional, waterfall methodologies to be too rigid, too slow, and too removed from reality. Their assumption that everything about a project can be known and documented up front has always struck me as laughable.
But when I look at pure agile methodologies, I find them too rigid and idealistic as well. Successful projects need a framework around them; they can’t be driven simply by empowering a team to prioritize a backlog and deliver chunks of code. Project components need to be fit into a larger vision and architecture; organizations need to have a sense of scope, plan, and budget. Large, complex systems can’t always be nicely packaged in 2 or 3 week sprints.
So I find myself mixing and blending. Take a few waterfall concepts like a defined project scope, written business requirements, defined technical architecture, and a project plan. Blend with an agile development window where the project team can work through detailed requirements, development, and testing together; shifting priorities as business needs change. Garnish with some user testing, training, and release planning.
Maybe this is agile book-ended by just enough waterfall to frame the work that the agile teams will take-on and integrate their work with the organization’s larger planning processes. Maybe this is diluting agile precepts by subjugating them to overreaching controls. Some call these approaches “waterscrumfall”; some call them an abomination.
My experience (and the experience of at least one of my colleagues) has been that a pragmatic blending better suits the needs of most projects and most organizations. It creates just enough structure to tame the chaos while recognizing that projects can’t be and shouldn’t be totally defined up-front. It ensures that project deliverables fit into the larger enterprise architecture and meet strategic objectives. Yet it takes advantage of the agile team’s strengths, allowing them to drive the project’s pace and details.
What has your experience been? Have you tried more blended approaches? Have they been successful? Or have they resulted in the equivalent of a culinary disaster?
About the Author
Joanne Wortman has been leading complex technology projects, MA integration programs, business process reengineering efforts and change management initiatives for more than a decade. Her work has been published in Buyouts Magazine and at www.vcexperts.com. Ms. Wortman holds Bachelor’s and Master’s degrees from Rensselaer Polytechnic Institute.
Powered by Facebook Comments