7 Simple Agile Project Management Tools that Work


Photo courtesy of contrapositively

Image by contrapositively via Flickr

In a previous post I described my approach to project management tools. To summarize, I prefer simple tools that I can string together into an effective process for each project.

I should note that the Software Studio at Obtiva generally takes on 2-to-6 person projects. Studio clients are by definition off-site. We usually meet face-to-face with them at least once per iteration for planning. Otherwise we act like a virtual team using on-line tools so that the client can participate in the iteration as it progresses.

The following are 7 simple agile project management tools that we use for Studio projects:

Drawing – Whiteboard & Digicam – There is really no substitute for standing in front of a whiteboard drawing, pointing, discussing, etc. This is high bandwidth communication generally reserved for planning meetings and or developer design sessions. When we need to record for later we usually just pull out a digital camera and snap a photo to later upload to one of our online tools.

Modeling & Planning – Index Cards & Sharpies – Along with a whiteboard another tool that is indispensable during planning sessions is the humble index card and sharpie. Collaborative card modeling is a high bandwidth activity and nothing really works better than physical cards for getting the team up walking around gesturing moving cards, ripping them up, etc. There is no substitute.

Lists – Google Docs Spreadsheets – While index cards work great for face-to-face modeling and planning the downside is that they aren’t digital. When the client leaves our Studio we need a way to share that planning information with them so they can think about things while we work on the current iteration. This usually requires us to transfer some or all of the information on the index cards to a digital form, a list. We’ve tried a bunch of different tools for this, including agile specific applications and ticket systems, but we always seem to come back to simple spreadsheets. Online spreadsheets like the one in Google Docs work great. They are always available from anywhere. You always know that everyone is working from the most up-to-date version. And, within the constraints, the tool is flexible enough and rich enough to manage user story lists and provide some decision support very transparently to the team.

File Storage – Google Sites File Cabinet – As with any project we often produce various file based documents such as screen captures, mockups, written docs, etc., and we need a place to keep them. Google Sites File Cabinets are a good option for this because they are secured but always available to everyone on the team.

Presence – Campfire – We know for a fact that collocated teams and clients provide the best, highest-bandwidth communication (a huge factor for project success). One reason for this is because team members that  work in close proximity can overhear conversations and interject or help the team get to answers quicker even if they weren’t originally included in the conversation (see Alistair Cockburn for more on this). We replicate this type of overheard conversation virtually using a group chat tool. Currently Campfire is our tool of choice for group chat because it is web-based and easy for clients to learn and use. It even goes one better than face-to-face communication in one aspect; all the conversations are archived and searchable later. Campfire has become an indispensable tool for our Studio projects. (http://www.campfirenow.com/)

Discussion – Google Sites Blogs – For non-real-time discussion of issues or ideas it’s nice to have a threaded discussion somewhere that the team can go back and review. Any sort of forum software will work for this. We tend to use Google Sites Blog pages because it’s one less login to manage. We don’t use this tool extensively but it does serve a niche need sometimes.

Ticket Tracking – Lighthouse – In software development projects there always comes a time when major feature development is done and the team focuses on lots of little nits. At this point user stories just don’t fit the tracking need and we’ve found that ticket tracking fits the workflow better. Because I am a fan of lightweight easy tools we’ve been using Lighthouse for ticket tracking lately. I’ve seen some new competitors in this “easy ticket tracking” space lately so I would encourage you to survey the competition. (http://lighthouseapp.com/)

Email – JUST SAY NO! – Finally, when it comes to project communication we try to avoid email. Why? Well for a lot of the reasons noted above. Email often excludes a part of the team that might have the answer. Email isn’t easily searchable by the whole team, including clients. Even individuals can lose track of an important project related email amongst all the other information that comes through their inbox. So my advice to project leaders is to discourage or ban the use of email for daily project work communication and encourage the team to use centralized online communication tools with searchable archives like the ones listed above. And don’t forget, nothing can replace the high-bandwidth communication that happens in front of a whiteboard or a table full of index cards and sharpies.


Be the Pipe – Simple Tools for Agile Project Management


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.

Contribute to Sprint

Sprint-2.jpgAfter receiving a few requests to add features to my Google App Engine project, Sprint, I decided to put the source up on Github. If you are interested in contributing improvements now you can fork the project, add your changes, test them, and send me a pull request. If I agree that everything looks good, I’ll push the changes up to GAE for all to enjoy.

You can find the project here: http://github.com/twebb/sprint/tree/master

Sprint – a minimalist scrum management tool

Sprint - Dashboard.jpg

Today I released my Google App Engine project called Sprint. It is a minimalist scrum management tool. My goals for writing it were to learn python, get a feel for Google App Engine, build a tool that I would like to use, and to see how fast I could complete a working release. It is admittedly still very rough around the edges. The initial release is missing some CRUD (specifically some UD) and some field validation on dates and other stuff.

The dashboard is aimed at the developer/user to make it really easy to see the sprint backlog items they have been assigned, their current estimate, and the date of that estimate.

The project page is more for the scrum master to see the bigger picture and to review a burndown chart for each sprint.

The backlog page is for product owners to record their product backlog items and assign each to a sprint.

Items, projects, backlogs are all ordered by title. I considered adding some sort of ordering mechanism but decided to let that wait in the interest of speed. Items can be reordered by naming them with an appropriate number on the front.

You can give it a try here: http://sprinthq.appspot.com/

Feedback is welcome (you can provide feedback here).

Tools and Statistics

I wrote Sprint using Textmate. I used blueprint.css as a framework for the layout and styling, and JQuery for the javascript effects and form validation. It is version controlled via git using the Textmate git bundle. It took me about a week and a half of work to complete the first release.