Implementing a Release Schedule

Question

The company I work for is trying to implement a release schedule and I want to get some constructive feedback from people that work in better structured environments than I am in.

We have one product that is finished and being used by several customers, but we have 4 additional products in the works - and actively being marketed as if they are finished. (Imagine that!)

We are a very small company working very quickly (and yes, sloppy at times) and with tight deadlines and tight budgets, so we don't have the luxury of written requirements, systematic QA process, etc. Basically the owners of the company come to the developers (3 of us) with ideas and we implement them. Then the subject matter experts test the features to make sure the app does what it is supposed to do.

I know that last paragraph opens me up to all kinds of "you can't do it this way" types of feedback, but I don't need that. I understand how wrong this approach is. At one point I was able to convice the owners to hire a project manager and a QA person, but after a short time both were laid off due to loss of revenue. We are where we are and there's no changing the culture at this point.

What I'm trying to do is manage expectations. We have a list of requested features a mile long and here's what I have proposed.

We will do quarterly releases to production of our finished products. The first release will be in October. Rather than trying to manage what will be done between now and then based on High/Medium/Low priorities, we will manage features based on what can and cannot be finished between now and September. At that point we will stop all feature development and focus on testing and fixing defects in order to get the product ready for release the following month. We'll repeat this process each quarter. Basically the steps will be like this:

1) Place all outstanding features into a future release based on how critical it is. 2) Work on these features during the quarter. 3) As new features are requested, place them into a "queue" for a particular release cycle. 4) If the feature has to go into the current release, then move other features to the next release. 5) At certain points during the cycle, evaluate which features may not get into the current release and adjust accordingly. 6) End development of features at least 30 days before scheduled push to production and focus on testing and bug fixing. 7) Push something to production on the scheduled date and then take the heat for not having everything finished that we agreed to in the beginning (hey, I'm being realistic...the people I work for aren't.)

Oh, also, if you plan to tell me to "get a new job" then don't bother answering. That's not an option at the moment.

If you have any advice regarding this proposed approach, or any links to resources that might help me better understand how to structure this process, I would greatly appreciate it.

Thanks in advance for your help.

Darvis

Answer 1

Release early and often.

I often find that users don't know what they want until we show them. In our facility, we have a light-weight QA/test system. Let users try new things. As users approve of ideas, we move them to production. This lets us always be working on new things, testing interfaces, adding database tables and columns, without breaking production code.

The only "trick" is constantly reminding the customer that the test platform is not the production platform.

Answer 2

Given the lack of project management, organization, etc - I think you're going to run into problems trying to force yourself into a quarterly (or any fixed date) release cycle. This will be especially true if you have any "large" features which will take more than the 2 months to develop that you're allowing for development time.

My suggestion would be to do a feature-based release cycle. Just make your queue of features, decide which ones you think you can reasonably do in a specific time frame. Implement those features, give yourself one month (or whatever) for testing, then release. Move to the next group of features. If it takes 2 months instead of 3, great. If it takes 4, that's fine too.

That being said, I'd focus on trying to make this shorter, not longer. Having more, smaller releases will actually help you in this case, especially since you don't have the formal procedures (and personnel) to handle QA, etc. Staying flexible will help you fix problems that will get into your releases...

Answer 3

What are you using for source control?

We use SVN and have the flexibility to if necessary create a variety of different branches depending on what's to be deployed as of the next release. If releases a1, a2, and a3 are set to be released, we can merge these changes into a branch off production. If a2 becomes less of a priority we can roll back only a2's changes or if there's overlap just create a new branch and merge only a1 and a3, leaving a2 for some later release.

How likely are the owners to rewrite a specification prior to a given release? Where I work this happens frequently, making the ability to shift gears and rollback / re-merge if necessary very helpful.

Answer 4

Quite simply, given the lack of defined process, there's not much chance of successfully implementing a solid release schedule. This isn't just pessimism, although I'l readily admit that it is.

Much like success being based largely upon hard work and a little luck, solid, repeatable release schedules are based upon process; having things such as functional specifications and design specifications are really critical to being able to release on a consistent, solid schedule. (You know there's a reason why people have such specification things, right?) And that's not to say that you can't hit your schedule and release expectations without such things; you very possibly can. But what having such process in place massively increases your chances of being able to meet expectations, at least partially because it assures that expectations don't drift into "unreasonable" territory while you're still implementing.

Again, this doesn't mean you can't achieve what you need to doing what you described above; to be honest, if you're in an environment that is actively hostile to having such process as described in place, you're probably working in the best way to achieve what you need to. And I don't mean to be completely pessimistic; it sounds like you've got a good grasp on how to attempt to get this stuff done; for what you've got to work with, it sounds like you've got a reasonable process in place. But I can virtually guarantee that you'll end up being better off if you can just get two things; 1) a functional specification from management that describes what they want the software to do, and 2) a design specification from engineering describing to management how you're going to make the software do what they want in the functional specification. I'd think you could possibly even fit this into your process; functional specifications don't need to be complicated; the key thing about them is that they are written down, which prevents bickering about what management asked for; it's right there. And design specifications don't need to take a lot of time either; a quick one-pager to let management know how (at a high level) you're going to implement what they need provides them with reassurance that you've heard them, and can help them understand the complexity involved (but don't go too deep into it, otherwise you run the risk of boring them and losing their attention).

Answer 5

My company also gets bogged down with feature requests.

What we did is go through all the features and give an estimate of the amount of time they will take to implement. Then, we leave it up to our "change committee" (our CEO, team leaders, etc.) to give us the features we will be completing during the next sprint.

This way, we aren't being given unreasonably large work-loads, and the end user has some say in what's completed.