Agile Waterfalls

I follow a lot of blogs related to Agile. I also follow many people on Twitter and watch a few LinkedIn groups. It all results in a lot of information available for me to digest. It also gives me a chance to watch some trends pertaining to what people are talking about. I will be the first to admit that I need to increase my net to get solid industry wide trends. (I am always looking for more blogs and people to add to my following lists.)

One trend I have seen a little of over the last few months is the idea of Agile Project Management and Traditional Project Management working more closely together.

I have stated in the past that I feel there is room for co-existence. While many “Agile Purists” push the idea that there is a black and white distinction between Traditional and Agile methods I feel it is more of a continuum. Chuck Cobb over at Managed Agile Development has really been pushing this lately. His concept is that we really need to redefine it such that there is no distinction between Traditional Project Management and Agile Project Management, and I totally agree.

Anything less than agreement here is really against what Agile development is about. Using tools and processes with the “Agile Stamp of Approval” is nice, but not as important as the individuals on a project and how they interact. If a product requires a certain amount of documentation to be considered working then an Agile Project will produce that documentation. The project is being done to produce a product for a customer. This is true regardless of what style of project management you have in place. Keep this in the front. If the customer wants releases only at certain milestones, don’t force smaller releases on them. Plan the work and work the plan, while allowing the plan to change.

I’ve held the belief that Agile and Traditional Project Management are not mutually exclusive since I started this journey. In fact I argue that forcing that mindset is actually against the Agile mindset. I feel it really boils down to the right tool for the right job. If Mini-Waterfalls is the best project structure for your situation then use it! Don’t force the organization into Kanban just because it’s “Agile.”

As long as the mindset of the project and project team is Agile then benefits of Agile will start to be realized. Keep feedback cycles as short as practical. Review the project regularly and use those reviews to change what isn’t working. Remember that value delivery to the customer is more important than getting tasks d, e, and f done by the end of the month.

Chuck is looking at what we consider a project in an effort to help bring these worlds together. This is an approach I hadn’t really thought about. I support it though. The team I am on has multiple internal software products that are under our control. Some of them are in maintenance mode. Some are being actively upgraded. One is getting ready to be re-written. We think of all of them as projects, but the organization doesn’t. It is likely that they shouldn’t all be projects. It is also likely that the re-write is not the only one that is. If you haven’t seen what he is up to you should go check it out now. You can start here and go to each newer post for a full picture.