Planning

I have a few difficulties with the way our team currently decides to plan what to work on for the next quarter or two. I’m not sure how to resolve this yet, but I thought I might just lay it out and see if anything interesting pops up.

Currently the managers decide what our priorities are for the next quarter by looking at all of the open bugs in Bugzilla. They take this list and present it to each of the major customers. Each customer looks at the bugs (really just the titles) and picks which ones they think are important to them and rate them as a priority. This information is collated by the managers and a list from most important to least important is generated. The top items that can be accomplished in the quarter are what we’re supposed to work on.

I have a few problems with this setup however. First of all, it requires that all possible future work be written down as a bug in Bugzilla and that the title of that bug not really reflect the technical nature of the problem, but be written in a way that’s marketed towards the users so that they might rate it higher. It also leaves all of the decisions up to the customers who can be very feature focused and does not allow us to perform important refactoring or rewrites of sections of the code. Building new features on an already unstable base can be dangerous if you don’t have the time to fix the foundation first. I do think that the customers should have a very large say in what the development team spends their time on, however the development team is never involved in this process which is unfortunate and bound for failure.

It is also difficult in that all ideas that you might want to work on or have discussed with coworkers have to be entered into Bugzilla to be considered. This isn’t too big of a problem, just an adjustment in work flow, however often managers don’t like bugs to be opened if they can’t be fixed in the shorter term. We’d have to open up very long-term bugs to have some of them worked on at all due to the selection process.

We also have no real way of addressing some of our larger issue scalability problems. Many of the problems are due to our underlying data model, however fixing the data model could break current user automations. No customer is going to vote on a bug that might make their work more difficult in the short term, even if it improves it in the long term. What most likely will result is we will scale using our current model until it breaks and can’t scale any more, then our users will be in a very uncomfortable situation having to convert to a new data model that we’ll have to create quickly and under pressure. This new data model probably won’t be as robust as something we developed out of crunch mode. The conversion process for customers will also be more painful as there will have been more time for them to create automations and other processes based on the old data model.

I don’t have a solution to this, but perhaps rereading this post after a holiday break will provide new enlightenment to me. For everyone who’s about to start their vacations (if you get one), Happy Holiday’s. For those who still have to work for a few more I’ll be making my last post of the year on Wednesday.

One Comment on “Planning”

That is an interesting approach to how your company handles their “task list” for the coming year.

If I may (take this with a grain of salt as I am not a software developer) but I would think that perhaps deciding on what to pursue next would be best served as an internal decision. Perhaps your company could create a set of goals that they want to achieve, or guidelines by how they want to operate. Things such as: Being the fastest software, hassle free, great design, and so on.

Once those are outlined you then pick what bug to smash next based on your company goals and philosophies, not each customers. It seems to me this is how companies like Apple operate, under their goals and guidance not the customers.