Stealthy Agile Project Management
One question that project managers often ask each other when our nerdy little community gets together is what method we use to manage our projects. One option is to follow a traditional, or waterfall, approach. Another possibility is to subscribe to an agile project management methodology. When I’m inevitably asked which method I prefer, the answer I give is that always frustrating retort of “it depends.” I don’t believe that any project can or should be 100% of either method; therefore, most of my projects are a combination of agile and waterfall. The reason for this is that many of my clients would like to pursue an agile approach but either don’t know what it means to be agile or else recognize that their organization isn’t mature enough to run an agile project successfully. Even if the organization isn’t ready to be 100% agile, it doesn’t mean that you can’t (stealthily) introduce your clients to agile project management. Here are some ways to introduce agile concepts to your stakeholders without them even knowing it:
Eliminate unnecessary documentation. Your clients will probably be happy knowing that they don’t need to pay you to develop a bunch of paperwork that will likely end up sitting on a shelf. But, in case they aren’t as enthusiastic as I can assure you my clients would be, work with them to understand the business purpose for each document they are being asked to produce. If the stated purpose is “it’s a requirement” and the document can’t be eliminated, see if you can simplify the document framework or reduce the amount of content to help your clients meet the letter, if not the spirit, of the law.
Progressively elaborate. Imagine you’ve slaved over creating a ginormous Microsoft Project schedule that carefully delineates activities and dependencies associated with the next 12 months of your project. Barely three weeks in, your project sponsor has rethought the approach for how he wants to execute the work. Or, a critical resource is no longer available. Or, you initiate the effort and learn that your proposed way of doing things is not going to work in reality. The point is that it is almost inevitable that your project approach or activity sequence will change midstream as you acquire additional project information. Instead of trying in vain to set a comprehensive schedule at the beginning of the effort, build out the details of the schedule for the next three months and then only list the milestones for the remaining nine. As you come up on the end of each quarter, progressively elaborate the upcoming activities for the next quarter based on information you glean through the course of the project. This way, you’ll still have the big picture handy for reporting and communication purposes, but you avoid wasting time when you inevitably have to rework the details of your endeavor.
Keep meetings focused on collaboration. Introducing a daily standup doesn’t make you agile. But, making sure your meetings support collaboration—rather than acting as a conduit for status updates—will help your team to focus on people over processes. Just because you’ve had a standing meeting forever at 10am on Mondays doesn’t mean that you need to keep having that meeting. If it doesn’t serve you, delete it.
Practice building consensus. Hierarchical organizations often struggle to adopt agile because they are so used to executive sponsors wanting to proclaim that it’s either their way or the highway. Agile can thrive in cultures that are already experienced in collective decision making. Repurpose the indecisiveness your clients tend to manifest in a waterfall environment and cultivate their love to debate and dissect through iterative planning workshops. As long as these meetings are getting your clients to collaborate, then they continue to serve a valuable purpose.
