I’ve been at a small software consulting company for almost 3 years. Recently, after over two years of working on what I thought of as “standard” software projects, I switched projects at my software consulting company twice in 5 months, and switched to a completely different mode of development both times. The lesson? There is no such thing as a “standard” software project, and any tools, tips, and magic cures that work on one flavor of project will not work on another.
Projects can be categorized in a few different ways: New Standalone Development, Enhancements/Maintenance, and Operations. There are more, but these are the ones I have experience in. Here are some of the challenges I faced in each type of project.
Basically, a client needs a new web application, and we’d build it. Project were divided into a number of phases:
Everything could be pinned down and scheduled. Progress was indicated by an steadily growing line of checkmarks down the left side of a Gantt chart.
The challenge was understanding what the client needed, and finding the quickest way to produce the code and make sure it was high quality. For this, we had a variety of artifacts including use cases, use case realizations (quick writeups of the technical details necessary to implement a use case), and Gantt charts. To make things high quality we created unit tests and conducted peer code reviews.
I then switched to a team responsible for making enhancements and fixing bugs to a big part of an even bigger distributed enterprise application. A lot of the best practices on the previous project were no longer necessary.
The challenge here was making sure that we had gathered enough information from other teams about how a change would impact the system (pulling information) and then communicating the design quickly to everyone involved (pushing information). For the most part, strict, well formatted use cases were tossed in favor of team design around a table. We documented and explained designs with CRC cards (http://www.extremeprogramming.org/rules/crccards.html).
Another challenge was getting a grip on the incoming requests. We settled on a first come first serve solution only to have a critical bug knock everything aside. It felt disorganized and frustrating to both us and the client until we settled on the severity rating system below.
In practice, Sev 5 items get moved into Sev 3 or Sev 4 before they get worked on, but it makes people feel good to have things in a bin somewhere. Longer Sev 3 and Sev 4 items would still have use cases and code reviews, but anything else was done with as little overhead as possible.
I then switched to a project that was a combination of new development and operations. There were hour long stretches of development interspersed with managing emails, checking running processes, exporting and importing data, copying files, etc.
The big challenge with operations was making sure that no task was forgotten. I tried keeping it all in my head for a day or two. That didn’t work. I tried GTD, but I had to act on a lot of things immediately (that took way longer than 2 minutes), so I couldn’t just throw it in a processing bin. I tried making task lists on paper or blackberry, but it quickly became a list of all current and future tasks and grew to unwieldy proportions, and in the case of paper I hated rewriting things every few hours.
I needed something that was portable, quick to update, efficient to read, traceable (for status meetings) and where nothing fell through cracks.
The solution I came up with involves a manilla folder and is described in the next post.
Content © 2006-2021 Rusty Klophaus