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.

Basecamp: A Two Year Retrospective

About two years ago I joined a small internet company as a project manager for product development. The company had begun using Basecamp as a tool to get a handle on numerous client and internal projects. During those two years I’ve been able to guide our use of the tool as we added some rigor to our project and development processes and, due to the acquisition of our company, I have observed some of the difficulties of using Basecamp in a rapidly scaled organization.

Simplicity Is Good

Because my development team (and in fact the entire company) was totally virtual, Basecamp filled an important need to compartmentalize project information in an online location. However, because we were also collaborating with sales, client services, and product managers it was important to have a tool that they could understand and adopt quickly. For this reason I have always appreciated the simplicity of the Basecamp product. While some may complain about the lack of features in Basecamp, I believe that our success in achieving complete adoption by the company (50+ people including employees and contract, with dozens of projects already in-process) in a matter of weeks is due mainly to the ease with which we could define processes and guidelines and communicate them to our colleagues.

Tool Simplicity Proposition: When implementing a new tool in an organization, more features lead to unnecessary processes, confusion, and wasteful debates on non-core issues. It is usually better to introduce the fewest features possible (and in fact hide unused features if possible) and slowly introduce new features and processes as the organization demands it and only after careful thought about the implications. (I may post something more on this idea later)

Scalability Will Be an Issue

So for a year or so we continued refining our use of Basecamp and exploiting more and more features as we gained experience. However, when the company was acquired last winter some of the shortcomings of Basecamp began coming to light. One of which is scalability. I’m not talking about scalability in the technical sense but in the usability sense. When you get past having a few dozen projects, a few dozen active client projects, and a few dozen employees managing the whole system becomes more and more tedious and wasteful.

One frequently requested feature that becomes more essential as the organization scales up is project templates. Because our company maintained a keen focus on efficiency of implementations and operations we quickly recognized some strain on resources to set up new projects. Being a resourceful shop from an operations standpoint we put some effort into scripting the Basecamp API to load up standard project setups based on a text configuration file. If you find your organization spending lots of time doing repetitive setup of projects in Basecamp, you may consider a similar approach because there is no template feature in the tool and no indication that 37signals plans to expand the limited To-Do template features.

Another issue you will likely run across when your organization scales is project access authorization and basic user management. While Basecamp is easy to use when you have a few dozen users it becomes more difficult to manage when you have a couple hundred internal users and a couple hundred client users in the system. As with any company we’ve seen the departure of a number of people over the past year and their accounts have remained in the system because no one thought to remove them. It can create a particularly large security hole if the person has been flagged to receive access to all future projects. Unfortunately, at this writing, I am not certain that the basecamp API allows any method to link up the user list with internal LDAP even if you did a lot of programming. It’s a major drawback to adoption in a large company.

Another issue is group authorization management. I believe some people use the Company concept to organize and authorize internal groups to access particular projects but that is not as elegant a solution as the Groups feature that 37signals has included in their Highrise product.


Overall I would say that Basecamp served us well as a small virtual company. It was easy to adopt for the non-technical folks on the team. It wasn’t distracting. Clients loved having one place to go to see everything related to their implementation. I would use it again if starting a new company myself. However, it will not serve your needs forever if your organization and client list scales significantly.

I don’t think 37signals has ever claimed that it would scale like that and would probably argue that they aren’t interested in serving that market anyway. That’s fair I suppose. As a result, it is worth paying attention and identifying a point at which your organization has outgrown the tool.

Does anyone out there have recommendations for identifying when you’ve reached that point? And if you have, what tools might be a good option to use for the next phase of growth while still adhering to the principles of simplicity and ease of use?