7 Simple Agile Project Management Tools that Work

Featured

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.

Do You *Really* Want a Rock Star Programmer?

Dear Interweb Entrepreneur,

I’m writing to express interest in your ad for a “Rock Star” Programmer. I am interested in knowing whether you really want employees who think they are rock stars. And, if you do really want someone who thinks they are a rock star, isn’t it bad form to come straight out and tell them? Seems uncool to me.

I suggest that you really want a Master Craftsman, an artisan, a virtuoso. Perhaps you really want someone who has a commanding presence but is still approachable, someone with quiet confidence whom people respect, a teacher, and a wizard with code.

If that’s who you really want, don’t come right out and say so. Try a different approach. Present them with the opportunity to solve a fantastically intriguing and unique problem that they just can’t resist, and let them know that you will make it worth their while.

If you don’t have such a problem to solve maybe you just need a solid journeyman programmer, someone who has solved problems like yours many times in the past and does so consistently and confidently.

Or, maybe you really do need a rock star to add a little glow to your otherwise completely unremarkable product. I’m just saying maybe it’s a good strategy for you…really.

Sincerely,
Todd

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.

Conclusion

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?