Wow, has it been more than a month since my last post? Time is surely zipping by for me these days. Got the planning and requirements stage sets out the door, but that's for another entry.
This one is about the difference between custom software development and packaged software development. Both Joel Spolsky and Eric Sink have recently written on the subject of upgrades and deciding what features go into what release. Eric and Joel are coming from the third-party software development world, and what they've written makes a lot of sense. Those of us that are satisfying customers one-on-one can take a lot of good points from these articles. Their overall theme appears to be: 1) Store up a bunch of issues, periodically decide what you're gonna do, then do it, 2) in between upgrades, don't promise anything, and 3) don't sell your product to inappropriate customers. I agree with all of this, but there’s more to the story for custom software developers.
Once upon a time, I was brought in to document a system that was almost ready to go into production. The developers were engaged in the typical endless loop of last-minute, absolutely critical (according to the requestors) change requests that were coming in the door via meetings, training sessions, email, phone calls, and I think I once saw a carrier pigeon. So, the first thing I did was get the sponsor to appoint a Primary End-user Representative (PER) that I had identified as a natural leader in a couple of meetings. Once she was in place and briefed on her role, I briefed the sponsor about their role as leader of the Change Control Board (CCB) and how the issue management process was going to go (standard Shell Method approach). The sponsor and PER were enthusiastic about this formality because this was one of those high-risk, high visibility, career-limiting, enterprise-wide applications. Meanwhile, the change requests continued to pour in.
The hardest part of bringing a currently uncontrolled project under control is finding a stopping point. When the developer is in the mode of responding to an endless flow of requests, a lot of other things (like testing, builds, and code promotion) don't happen, or don't happen properly. In this sense, a custom project should take the advice of Joel and Eric and "batch process" their changes, just like the packaged software providers do. In the case of custom software, one can't wait a long time between upgrades. As soon as one version is out the door, work begins on the next version. To keep the customer happy, one must be responsive. In order to be responsive, one has to address issues in a timely manner. This means short iterations, small versions, and rapid release cycles. The user community, sponsor, and developer should be constantly validating, analyzing, verifying, and assigning issues to various planned iterations while the developer works on executing the current (short!) iteration.
Fortunately, when one is brought in to document something, one can always throw up one's hands and exclaim "I can't document a moving target. Pick a set of features and lock the system. Push all other changes into future releases." At this point, you will usually be ignored. My solution to this is to stop work and wait for them to panic that the docs won't get done, which means they won't get a test plan or a deployment plan, which means nothing gets released. There are an awful lot of things you can be doing in the background while giving the appearance you've stopped work.
If you’re a developer in this situation, I recommend a similar approach. After all, your survival is at stake; your survival depends on your reputation, and failed projects are not good for the reputation. So stop responding to issues. Pick a “last” issue and address that, and start working on the build and promotion cycle. There are a lot of things you can be doing in the background when not working on issues.
Eventually, the user community figures out that everything they want is not going to happen in the first release. One trick a smart PER came up with was to create a “Wish List,” which really was the catch-all for every new enhancement request that came up. The developer focused on entering real defects into the real issues list. A real defect is something that is technically difficult, generally requires a design change, and needs to be approved by the CCB before it is corrected. After all, when a defect is only apparent during certain artificially contrived conditions (like in a training class), it’s not all that big a priority. The key is to push all of these decisions onto the CCB so that they 1) see responsiveness, 2) are involved in the decision making process, and 3) have a sense of control over the project.
Three critical success factors brought the project under control. First, the establishment of the wish list and the issues list created a focal point for the user community. Suddenly all the discussions were about what’s on the list, how well they’re defined, what their priorities are, and when they should be implemented. A collaboration area or discussion board is massively helpful here. Second, the CCB began considering issues, but only those issues that had passed through the analysis phase of the change control workflow. A few last issues were promoted to the 1.0 release, but the vast majority of issues were properly reserved for future iterations. Third, the sponsor, developer, and users became comfortable with the fact that there would be future iterations, and in short order. When a team acknowledges that they’re on a long journey, the sprint mentality melts away.
So, yes, both Eric and Joel are right; you need to control what’s going into your next release. For custom software developers, that next release (and the next two or three) need to be visible on or just over the horizon of the user community. Once you have that vision in place, with issues constantly being evaluated and assigned to future iterations, you will have a user community with an “in it for the long haul” mentality. For most customers, this becomes a never-ending story of tuning and improvement. This never-ending story is why custom software can be so enjoyable and so profitable for everyone involved. When you are a developer with a stable of “long haul” projects in place, you don’t need to do any marketing anymore. The bulk of your work comes from current projects, and happy customers generate referral business for you.