The other day I got an email from a developer asking my opinion about some software management tools. He’s in a situation I’m sure we’ve all been in at one time or another: he’s got a very small team of developers and a limited set of resources, and he’s working for an agency that has all sorts of rules and regulations they want developers to follow. He’s somewhat new to the game of software management and wanted some advice on tools to help him manage his project.
I started thinking: I am not a project manager. I am more of a “team lead” on my current project. I’m the guy other developers come to for answers in regards to topics such as architecture, coding conventions, design decisions, technology queries, etc. But I’m also an opinionated guy, and I did have thoughts on the matter. At any rate, I started typing out a response to my developer friend when it occurred to me that this might make a decent blog post. Thus, these are my thoughts on project management…
Simplicity
My feelings on Project Management are very similar to my feelings on writing good code: Keep It Simple Stupid. I believe complexity only slows us down and makes things more difficult in the long run. If one way of doing something takes less (a) time or (b) effort than another way, and provides us with the same data or feedback, then I think the faster/easier way is superior. That seems like common sense, but you’d be surprised what guides people’s decision making processes.
Above All: Information
The number one thing you need to manage a project successfully is information. And you need it to be concise, easy to find, easy to digest and accurate. You also need this information to be updated frequently, in whatever form it takes.
No single tool exists to do all of this for you. It takes more than that: it takes good developers, constant communication, and a suite of simple, reliable, accurate tools to gather metrics and data for you and present it in easy to digest ways.
- Simple. Because anything complicated takes too much effort to maintain, and when that happens people stop using it. This goes for tools or processes.
- Reliable. Because tools that don’t work just add overhead to your time. Unreliable tools create aggravation.
- Accruate. Because enough of software development is a guessing game already. Accurate metrics define from the obscure.
- Easy to digest. Because you’re already too damn busy with everything else going on.
The faster you can digest the status of your project the less time you’ll need to spend interpreting data, which means more time for something else. The less verbose documentation you have to wade through the more time you’ll have for doing important things, like writing code, tests, and meeting customer expectations. So how can you get do this concise, clean information?
Version Control with a Continuous Build Server
This is the first step, and it is a must. You have to have version control. This may sound like a no-brainer, but believe it or not there are still developers and teams writing software without version control.
Second, the Continuous Build Server is one of the best tools for determining your project’s status. It is like a doctor’s thermometer; it helps you see, in very concise terms, what the health of your project is. Without a continuous build server you might as well use a Ouija board to figure out where your software project stands. The larger your team, the more difficult it will be to determine the state of your code, as developers will be manipulating it too frequently for you to keep up on all the changes. A build server is the ultimate distillation of status: green is good, red is bad.
Of course having a build server implies something else: Unit Tests. Without Unit Tests, a build server is just an scheduled compiler. Yes, it will tell you if the build is broke, but that’s only a small portion of what a build server can do. With Unit Tests, a build server can tell a lot more about the quality of the code as a whole. You can see tests passed and code coverage reported; you can know not just if the build is good or bad, but to what extent it is good or bad. And you can digest all of that in seconds.
Story Cards
You know those stickers that college football coaches award to their players for outstanding plays? The ones players put on their helmets for making great plays? As the season gets closer to the end, helmets have more stickers, and it becomes really easy to see who the standout players are. That’s what Story Cards are. They are football helmet stickers.
Forget Gantt charts. Forget detailed requirements documents. Forget everything that requires extensive reading. Story Cards are the cat’s meow for Project Management because they’re simple, concise and maybe most importantly: visible. They hang on a wall where everyone from the development team to the customer can see them. They are physical representations of accountability. They are an incredibly easy to read metric for determining how far along the project is. When you see a wall go from empty to cluttered with story cards, you know you’re making progress, and so does everyone else.
Bug Tracking Sofware
No matter how well or completely you test, you’re still going to have bugs. Fewer bugs to be certain, but bugs nonetheless. Or little user complaints that aren’t really bugs: a detail someone forgot; a feature that needs tweaking; a user request that’s really too small for a story card. You need a place to track this stuff, otherwise it falls through the cracks. These are the things that add polish to a project. Bug & Feature tracking software can help. We use Dragnet where I work and we really like it. It’s simple, which is a key feature for anything we try and employ. It is extremely easy to use, which gives us no excuse not to use it.
Wiki
A project needs a hub. I think a Wiki is the perfect hub. You can put everything on it. You can link to any file of any importance on your system: link to your build server’s reports, link to your bug tracking software, link to web pages that developers should be familiar with, link to blog posts that are relevant, link to anything you don’t want to forget.
You can also publish release notes, release schedules, coding conventions, FAQ’s, or whatever your heart desires. It’s a great central location for all things related to your project. And it’s wiki software. Choose the right kind (simple to install, easy to use) and you’ve won most of the battle.
I would stay away from turning a Wiki into a design document however, or anything else that required extensive reading. It should be a place for links to tools and concise digests of information. If you turn it into a novel then developers and customers won’t use it. Besides, this is why you have a development team: to get the details. I don’t really want to read 100 pages of documentation about the project, I’ve got coworkers to tell me the details. Besides, they’re more fun to talk to. But as a hub – as a central way to tie all your important pieces together – I think a wiki is great.
Conclusion
Like I said, I’m not a project manager. But I’ve watched how my current boss manages our project and I’ve learned that his greatest source of frustration comes from not having enough information. He can’t make decisions without accurate, reliable, up-to-date information. No one can. And it is our responsibility as developers to get him that information in whatever forms we can, as concisely as we can, as frequently as we can. If I had to be PM tomorrow on a project these are the basic things I’d want to get started with. The rest of the information – whatever these tools don’t cover – would come from my employees.