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
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).