Project management

As a leader, you can help make sure that units of work are as small as possible. Tiny units of work increase predictability. Everyone likes predictability. What comes handy in a "just-in-time to do, doing, done" workflow is some project management skills.

For someone leading a team of developers, project management means designing and executing good rollout plans. We ship features and sometimes they are so big that we need to plan for shipping them. For example, you may find yourself discussing the order in which things need to go live during a code review. That's way too late. The best moment to discuss a rollout plan is before any of the work starts. I like to remind people of this with a catchy quote:

Weeks of coding can save you a few hours of planning.

People do underestimate the value of a little planning versus total improvisation. I'm obsessed with tiny units of work not only because they can bring predictability, but also because they help a great deal with basic project management techniques. In order to manage a project efficiently, ask yourself a few questions:

• What can be done in parallel?

  If you can't leverage the power of your team, then working in a team becomes frustrating.

• What's in the critical path and what isn't?

  Flag units of work that are critical to your goal. A unit of work can have only two states: critical or not. This point is crucial because it helps everyone: from external parties interested in the success of the release to the team members who want to know what's needed for a successful release. My favourite side-effect of flagging units of work as relevant to the critical path is that it minimises the risk of breaking a release for some silly reason. A good example, which I've seen in the real world more times that I can count, is failing to release an application on time because we forgot to localise some copy. Localisation may not be the hardest task to complete, but sometimes software doesn't work without it.

• How can you better schedule units of work?

  Once you have split work in critical and non critical, you already have two smaller sets of problems to solve. You focus first on the critical work. The way you prioritise your work becomes your rollout plan.

These three questions all share an interesting property: the smaller the average unit of work, the easier it is to answer each one of them. One reason more to be obsessed with tiny units of work.

Thinking of releases as projects to manage gives you good indicators of the seniority of your team. No matter what your definition of "senior programmer" is, it's fair to assume that one trait senior people share is their ability to get things done. It's hard to get things done by improvising. A little planning goes a long way. In this sense, you can think of project management as a mentoring tool, too. You can teach your teams to solve bigger problems using simple project management techniques:

• Break down work into the smallest units possible, but not smaller.
• Separate work in critical and non critical.
• Prioritise so that the rollout plan makes sense.