Project Management – How We Do It

Project management is how software companies manage their various overlapping development efforts while building great software. Likewise, a project manager oversees those efforts. Taking notes, tracking progress, recording milestones, and holding meetings are just a few tasks project managers handle every day.

At Don’t Panic Labs, that’s been my role for nearly five years and it’s one that I find both challenging and fulfilling, especially when one considers the various methodologies and philosophies that exist around managing software development. There’s no “one way” to approach project management. We have many tools in our toolbox and evaluate each project to determine how best to approach it.

It’s part art, part science, and all communication.

We are light on process, but value the processes we do have in place and follow them in all projects consistently across the company.

One thing that consistently comes up in conversations with our partners is how our processes yield such speedy deployments of new products. Our results catch the attention of larger organizations that often struggle with the speed of new rollouts.

This inevitably leads people to ask us how we manage our projects. We are very upfront in saying that our methods cater to our environment/experience and may not be suitable for other companies. We’re always happy to share what we’ve learned through our experimentation with different techniques and approaches. But instead of waiting for people to ask, I thought I’d provide an overview of what we do today.

Release Planning

How we approach release planning can sometimes vary, but I’ll focus on our most common approach: Themed Release Cycles.

When we begin talking about an upcoming release, we look to the product owner since it’s typically their vision that defines the release content. Our product owner meets with a project manager and lead architect to lay out what they want included in the release based on their current priority theme(s). For each item, we make sure we have a clear understanding of what is being requested. We also discuss different implementation options/risks/benefits and make decisions on how we’ll implement items.

Items needing further clarification are tagged as “Design Needed”. The most common design item needed is UI/UX design. Our goal is to have the user experience defined and have UI mockups completed prior to scheduling a work item into an iteration. These mockups not only provide a clear picture of what the team is coding towards, but also help point out anything that could raise concerns down the road.

The project manager and lead architect then get together to do Rough Order of Magnitude (ROM) estimates on each item (I’ll talk more about ROM estimates a little later). After items are estimated we order the items, usually doing the ones with the highest risk first, then grouping into iterations based on the number of resources we have available. The work effort for the theme(s) drives the length of the release cycle (i.e., when we are done coding/testing the theme that has the most effort, we’re ready for a production release).

Having themed release cycles gives the engineering team clear goals and is an easy way to communicate the engineering team’s current focus to the rest of the company.

How We Estimate

We’ve just finished up initial release planning and have given Rough Order of Magnitude (ROM) estimates to each work item. We came up with a way of estimating that’s worked well for us. It’s a simple point system that’s easy for everyone to get their heads around.

• 0 pts (in the noise)
• .1 pts <= ½ day
• .2 pts <= 1 day
• .5 pts <= ½ week
• 1 pts<= 1 week
  • The majority of our stories are 1 week or less
• 2 pts<= 2 weeks
• 3 pts> 2 weeks (needs to be broken out into separate stories and estimated)

Using this model makes it easy to quickly determine the number of man weeks estimated for a given release cycle (i.e., sum up the ROM points and you have the number of man weeks for the release cycle).

One term we frequently use when talking about estimates is “user stories”. For those not familiar, user stories are brief descriptions of the feature or change from the perspective of the end-user. These help paint a better picture for the engineers of the purpose behind the changes.

When user stories are scheduled into an iteration, we usually ask engineers to separate the story into tasks and estimate the tasks. We have just three levels of task size:

• Large: > 12 hours
• Medium: 4-12 hours
• Small: < 4 hours

Breaking a user story down into smaller chunks forces the engineer to think critically about how they will implement it. Estimating the task size is also a cross-reference back to the original user story ROM estimate. We’ll adjust the user story estimate if needed.

Iteration Planning and Daily Standups

At this point, we have our items identified, estimated, and ordered for the release. It’s now time to schedule our iterations.

We generally use one-week iterations, which we’ve found to be long enough to get tangible work completed but short enough to allow us to quickly pivot or react to things that inevitably come up.

Weekly iteration pre-planning meetings are held one day prior to our iteration planning meetings. The product owner, project manager, lead architect and QA lead meet to discuss progress on the currently scheduled items, triage any new items that have come up over the last week, and plan for the next iteration. We determine if we can continue down the path originally planned or if we need to adjust current plans.

Our iteration planning meetings with the team are used to communicate the work items scheduled for the iteration and to make sure they understand the scope of work assigned.

If the path to implementing a work item is unclear to the engineer, the first task we’ll have them do is create a whitepaper that describes the problem, offers options to solve it, identifies the possible risks and mitigations, provides their recommendation for solution(s), and lists a task breakdown of the work required to implement the recommended solution along with estimates for the tasks.

The whitepaper is then reviewed by the lead architect (and possibly other members of the team). Once the direction is decided upon, any tasks resulting from the decision are created and assigned, and the engineer begins work. We’ve found that this exercise not only helps in finding clarity with the problem, but it’s also a great learning opportunity for the engineer to develop their critical thinking skills to solve complex problems. To keep this process manageable, we ask the engineer to time-box their work on this to one day or less.

Throughout the iterations we hold daily standup meetings. We schedule these in the mornings and keep them to 10 minutes or less. Engineers and QA leads give an update on yesterday’s progress, today’s plans, and any issues. We also ask the product owner if they have any updates for the team. This meeting gets us all on the same page for the current day’s project activities. It’s amazing to me how people who sit next to each other don’t talk. Almost daily, something comes up that leads to a clarification across the team or to a conversation after the standup. We find these meetings invaluable.

There’s a lot more I could say about the benefits of daily standups over other types of team meetings, but instead I’ll refer to a post that Doug Durham wrote about what standups are and how we use them.

After all the required tasks are completed and we’ve released the latest version of our software, it’s time to reflect.

Retrospectives and Values

The release is out the door. Now it’s time to reflect on the work that’s been accomplished in the past weeks or months. It’s time for a retrospective.

We know we’re only going to truly learn and grow from our experiences if we sit down as a team and discuss it. We talk about what worked, what didn’t, propose what could be done differently next time, and generally air any thoughts or concerns we had during this release cycle.

How do we keep our lessons learned top of mind after the retrospective meetings? We created a “Lessons Learned” spreadsheet where things the team has learned are consolidated into a single document. We send an automated email containing a link to this document twice a month to our project managers and lead architects asking them to review this doc for any lessons learned that might apply to their currently active projects. For each lesson learned, we capture additional information that allows us to easily know at a glance if this lesson applies to a project I’m working on now (e.g., if it’s a “Do or Don’t” lesson learned, when in the lifecycle this lesson learned applies, or what general category does it fall into).

We used to have retrospectives more frequently than we do today, but found that we weren’t getting a lot of value in doing them so often. Now, I think we have slipped too far to the other end of the pendulum and aren’t having them often enough. We’re still learning. Right now my best guess is that holding retrospectives once a month might be the right balance.

So what can I suggest for other project managers and teams out there? Know who you are. Identify things you value and make sure the practices you have in place support those values. If you’re doing things that don’t support those values, quit doing them.

Here are a few examples of our values and practices:

Review your values and practices once a year and update them to reflect what you’ve learned. Use what you’ve learned over the past year to make your next year even better.

Not everything we do fits all companies, but they work for us and our culture. We still learn new things every day and hopefully we have mechanisms in place that allow us to make the necessary adjustments along the way to improve our processes.