Don't Get So Agile That You Trip Yourself Up
By Jason Tee
Don’t Get So Agile You Trip Yourself Up
Projects in the world of software development don’t typically lend themselves to months of careful planning and strategizing. In many cases, that kind of effort would be wasted, because what you start out with doesn’t look anything like the end product. As a project gets underway, opportunities for design improvement leading to greater functionality may suddenly appear leading to the evolution of a much better outcome than expected. Or, a client’s whims may change, necessitating a quick alteration in project trajectory. Then, there are the inevitable obstacles that seem to come out of nowhere to radically alter even the best laid plans. The uncertainty inherent in the development, testing, and implementation of new technology makes agile project management popular in the IT industry in general and the software field in particular.
Agile PM Keeps Projects Limber
Proponents of agile methodology tout the following benefits of this approach:
Flexibility and Adaptability – Suppose a new tool came on the market tomorrow that would make it 30% easier to reach your project objectives. You could easily incorporate it into an agile project. With a rigid “waterfall” approach that determines in advance exactly how each schedule activity will be accomplished, you might miss out. Also, if outside pressures or internal objectives change, you can mold an agile project to achieve a different outcome without losing too much momentum.
Better Visibility – With agile project management, you are constantly reviewing and adjusting your plans. Because there’s an expectation that the project will evolve, good change management practices are given top priority. Accountability stays high when you have the opportunity to test outcomes on a step-by-step basis. You can identify screw ups right after they happen instead of months down the road when finger point does no one any good.
Risk Mitigation – The end goal or product is chopped up into smaller segments for delivery. This means unworkable pieces can be scrapped as needed without scuttling the entire project and losing all the resources invested. At the same time, if a project is cancelled for some reason, you could still end up with completed, usable pieces instead of a partially developed product that is useless.
Hold Your Metaphoric Horses
If you think that Agile is totally AWESOME and you can immediately switch over to this methodology with no fear of failure, think again. For real life horror stories about what can go wrong with agile project management, check out the reader comments over at Sebastien Lambla’s blog. Here are some lowlights:
- When stakeholders think that flexibility means “We can have as many changes as we want and it’s FREEEEEE”, this spells disaster. Scope is certainly negotiable, but changes do have a cost attached.
- If the client doesn’t understand agile methodology or just doesn’t like it, you can lose business by insisting on doing it your way.
- Breaking up a waterfall into little tiny pieces and referring to it as agile just means you end up with a broken project. Real agile projects incorporate a feedback loop to actually improve the process as it goes along.
- Requirements and documentation are not optional – even with the most agile project. Participants have to understand the underlying business objectives are or they will be playing Pin the Tail on the Donkey when it comes to actually delivering a usable product. Without documentation, it’s possible to end up troubleshooting the same issues over and over because no one knows what anyone else is doing.
- Agile isn’t sustainable with micro-managers or with managers who are content to sit back and let everyone else do all the creative work. Of course, any project will have issues if leaders don’t do their job right.
- Sprinting turns into a marathon when you don’t leave time to step back and evaluate after each iteration. Your team can’t do everything at once.
- All that is required for an agile project to fail is one product tester with his head up his butt. Same goes for developers who don’t take the testability of a product into consideration when they are creating it.
Stay Out of Trouble by Taking Agile Baby Steps
If you’ve never done an agile project before, you don’t want your first attempt to be a catastrophe. This could set you back years in being able to harness the benefits of agile methods because everyone in your organization will be gun shy.
Start with a project that is similar to one you’ve completed successfully in the past using traditional project management techniques. That way, the number of unknown variables will be smaller. Plus, you will be able to directly compare results achieved through agile methods with your previous approach. This will put stakeholders at ease about transitioning further into the agile mode and increase the amount of support you receive on future projects.
Be sure to let your team know that this approach doesn’t mean LESS WORK. It’s just designed to deliver BETTER RESULTS. If your team is worth its salt, they will find professional pride is a better motivator than laziness in the long run.
27 Jul 2011