To paraphrase Doug McIlroy on the Unix Philosophy:
Do one thing and do it well
When it comes to managing agile software developement projects, I prefer simple tools. Sure, I’ve tried numerous monolithic project management applications over the past 16 years. They do it all. But I keep coming back to a set of simple tools that do just a few things well. In fact I prefer tools that aren’t project management specific at all.
First, project management applications are often heavily focused on management decision support. This seems dead wrong to me. Projects are delivered by project teams, not management. I’m not saying that management reporting is bad, just that enabling project team process is so much more important that everything else should fade into the background. For example, decision support features, if they exist at all in a project management application, should ideally be entirely hidden from the project team. In other words, all features that the project team uses should directly connect to the work of delivery and any decision support features should be completely invisible to the team. Most project management applications don’t follow this principle and I just can’t get past that.
Second, to offer a rich monolithic project management application that people will pay for one must add a significant number of features and cover a significant number of project processes. This inevitably leads to an application that reflects a particular methodology. I’m not saying that methodology is bad, just that consistently implemented techniques are so much more important for project success. In other words, smaller tools that enable techniques allow me to tailor the methodology to the project. With most project management applications I can’t do that.
Third, project management applications often include too much structure. A few years ago I had the displeasure of working with a ticket system that had a crazy state machine built in. We had a spaghetti graph showing how it was configured and it was just scary to look at. Of course the “flexible” and “configurable” controlled workflow was a selling point to management (and SOX auditors), but in essence the system just got in the way. I’m not saying that structure like workflow is bad, just that staying out of the project team’s way is so much more important. I would rather manage structure the good old fashioned way. If a project management application requires lots of structured process I would rather not use it.
So, what do I use?
Currently I use a set of simple tools that I can string together in a way that works best for the team: web-based spreadsheets and documents, group chat, threaded discussions, a simple ticketing system, and web-based document repositories. And lately I have focused my attention on learning techniques to more effectively use physical tools like whiteboards and index cards. All these tools do very little, but they do it well, and I stand in between and integrate them into a useful process.
So generally I would say I follow a sort of Unix Philosophy of project management tools. For you Unix geeks out there, I’m the pipe (|). I use simple tools that do a few things well and string them together into a process that works. Obviously, integrating the tools by hand is time consuming, and APIs and automation in between could free me up to do more for the business. However, given the size of our company and our projects I think the tradeoff is worth the benefit, for now. The approach has been tremendously successful for the agile software development projects that we deliver and it can work for you too. So don’t be seduced by big monolithic project management applications. Just be the pipe.