Our New Project Management Process

At the end of last year, our team outlined our goals for 2014 and reviewed our internal processes. We devised a new plan for managing our site development, and it has proven quite successful. Before I get into the details, I want to note that we've made a big departure from typical project management processes. Our new approach does not require a dedicated project manager or hard deadlines, both of which are possible here at Drupalize.Me because we're a product team. For the most part, we're our own "client" with regards to our site and we set our own deadlines. We're also a small team―eight people total―with a high degree of trust between team members and management. Nevertheless we still want to share our new processes with the hope they spur some good ideas, and we're always curious to hear your feedback!

Aside from our primary goals, we always have a lot of additional priorities. It wasn't always clear to the team what tasks were a high priority relative to others. Often tasks were just sorted every few weeks as we went about loading a sprint with tickets. The team wanted a better big picture view of what tasks were important. Here is how we decided to handle task priorities, ticket assignment, and site releases going forward:

The Roadmap

We now have a site roadmap for clarity. Our roadmap outlines and defines our top ten priorities. They are listed in order, with number one being the most urgent. Many of the items in the list have links to other documents where we brainstorm and capture relevant notes. As we develop actionable tasks for each priority, we create tickets in Unfuddle*, our ticket management system. Everyone on the team can propose priorities in the 'Ideas' section of our roadmap, but as Product Manager, I ultimately make the final selection. I do solicit feedback, review, and update this roadmap on a monthly basis or whenever we complete one of our top ten priorities.

Project Management

We've created "milestones" in Unfuddle for each priority on our roadmap, including everything listed in the 'Ideas' section. ( Just because something is not a priority doesn't mean you can't work on it.) The milestones do not have deadlines. This means we are grouping tickets by related tasks―not time intervals—and our top ten priorities are numbered, so they appear in order on our main ticket screen. Other milestones are just listed alphabetically below. We have two important ticket reports that are automatically generated based on ticket type: Bugs and Maintenance Tasks. We also have a "Hot Fixes" milestone for tickets that need to be pushed as soon as possible, and a "QA Fixes" milestone for bugs found while performing quality assurance (QA). We now have a good picture of tickets that needs to be completed, and their relative priority. Next we restructured our project management process to reduce overhead, facilitate more autonomy, and increase the speed at which we iterate.

Image

Sprint and Release Cycle

We no longer have sprint cycles because our new milestones do not have deadlines. We now push a release every Wednesday with anything we've finished. We have three sites for this release process: dev, QA, and live. Here's how it works:

1. Throughout the week, we do peer review of resolved tickets prior to merging anything into our dev site.
2. On Monday mornings, we merge anything in our dev branch into our QA branch. Work can then continue in our dev branch.
3. We create a weekly QA checklist by copying QA user stories directly from the tickets that were merged. (Every ticket needs a QA user story before it can be added to a milestone in Unfuddle.)
4. Everyone on the team performs QA on the closed tickets, in addition to a general spot check of the QA site to identify bugs and/or regressions. We run a suite of tests and manually complete a list of important QA tasks. We open a ticket in our "QA Fixes" milestone for any QA fails or regression bugs we identify. We then fix or revert these tickets prior to release.
5. On Wednesday mornings, we merge our QA branch into our master branch, tag it, and pull the tag onto our live site.

This workflow facilitates constant improvements to the site. We can now respond faster to support issues that involve bugs or site features. We don't have to wait weeks for a new release, which is great for morale and momentum, and the QA process is relatively short and manageable. One week's worth of development is only 10-20 tickets. We have at least four people performing QA, so one or two hours for each covers our QA needs, and it doesn't concentrate QA all on one person.

Ticket Assignment

We've removed the overhead of loading sprints and assigning tickets almost entirely because tickets can now be self-assigned. You can work on things that are personally interesting or bugging the hell out of you, in addition to stuff that isn't fun but needs to be completed. This requires trust that we're on the same page regarding our priorities. But we're a small team, all focused on the same goals, and the roadmap makes our priorities clear.

The main project management responsibility that remains is making sure new tickets are reviewed and assigned to the correct milestones. Instead of "Project Manager", we call this person the "Gatekeeper". The Gatekeeper reviews new tickets daily (often only two or three), verifies that there is a good QA user story and then assigns them a priority and milestone. The process is very lightweight.

Overall our new processes have made our site-building efforts much more flexible, which is really important. If someone doesn't have time to work on tickets due to other responsibilities, they just don't assign themselves any. On the other hand, if someone is blowing through tickets, they can simply grab more from the pile and keep moving.

Now, granted, we've only been working this way for two months. So far it has been working very well, but it remains to be seen how we handle those tickets that no one ever wants or what other fun scenarios present themselves. The clear, prioritized roadmap is key to everyone feeling like they know what is going on and making intelligent decisions about what to work on. We also know managing projects this way will not work for every team or situation, but it seems to be working for Drupalize.Me.

* We use Unfuddle for ticket management, but the concepts here are lightweight and should work in other systems.