Developer Oriented Project Management

As project managers we need to think about how developers work rather than expecting them to adapt to our mindset.

Project management is hard. Between the initiation of a project and the (hopefully) successful closure of it, keeping up to date with the execution of a well-defined plan can be incredibly difficult, especially when developers are sometimes reticent to update a tracking system.

There can be various reasons for this: maybe there’s a lack of understanding of the importance of frequent updates, or maybe they’re unaware of the expectations that are being placed on them.

However often it is our own approach to managing projects that can be the issue. Issues such as:

  • Constraining developers with details.
  • Unrealistic expectations around estimates.
  • Enforcing inappropriate tools.

We often end up undermining developers and making their job harder. Nowhere is this more true than on unnecessarily constraining levels of detail.

Don’t constrain developers with details

Specificity can be a huge problem for a development team. Sometimes plans can be too specific, and other times they’re not specific enough. It is typical in many organisations for a project manager and lead of a team to meet with the business once every few weeks to discuss the upcoming priorities and projects.

Once the priorities have been laid out, the project manager will then add high-level overviews of the expected outcomes of the project to a project-management system like JIRA.

This is usually a great idea, if managed correctly.

But these updates frequently contain little to no explanation of what the desired outcome of a piece of work entails. Or so much information that it takes a dedicated reading session to comprehend what needs to be done.

Overly specifying work can prevent developers suggesting alternative solutions. This damages the project and morale.

Tweet this

These longer tickets, whilst having all of the required information, often go into granular detail. This can sometimes make the developers on the team feel as though they aren’t being given an opportunity to have any input into the project. It prevents them from being able to solve a problem in the best way that only someone heavily involved with the code on a daily basis can know. This leads to all kinds of morale issues within a team and de-motivates developers.

How to get the level of detail right

Some teams prefer more detail than others, often depending on how involved that team is in a product’s lifecycle.

Often, developers like outlines in the form of scenarios. These can take the form of:

  • Given this thing is the starting point…
  • When this thing happens…
  • This is the expected outcome.

This is the primary construct behind Behaviour Driven Development, and, done correctly, gives all of the possible scenarios to the developers without forcing an implementation on them.

Ideally, these scenarios will be decided upon together through discussion with the stakeholders and the developers. This will ensure that everyone knows and has had input into the specification for the upcoming work. It also gives developers the opportunity to spot edge cases that may otherwise get missed.

Discuss with developers the best approach to managing a project. It will almost always lead to a better product.

Tweet this

Discuss with the developers directly what the best approach for them is and how much detail they prefer. And always encourage them to ask questions about unclear objectives. This not only makes the process easier, but almost always results in a better product.

Avoid unrealistic expectations of estimates

Once a developer has been given a task, they’re usually asked to estimate how long they think that task will take to complete. Whilst there is nothing wrong with this from a planning perspective, often they are asked to pull a number out of thin air and are then held to that estimate as though it is gospel. Or, even worse, they are told how long they have to complete the task.

There are a number of problems with this approach.

There is a whole movement dedicated to the cause of #NoEstimates and, given the above implementation, I have to agree with them.

A better way to approach estimating

This situation can, generally, be fixed quite easily by allowing the developers to break down the set of steps they need to take to implement the entire feature, and then providing the resulting figure to the business, rather than having to give a figure immediately.

In addition to this, it’s important that when a deadline is slipping, the developer is given the chance to discuss with the project manager why that’s happening, rather than feeling as though they’re going to be reprimanded. Development can be difficult, and the tiniest of things — even just a single missing semicolon — can derail an estimate.

Development can be hard to predict. We should not reprimand developers when they fail to hit a deadline.

Tweet this

By allowing the developer time to work through the different facets of a problem and to estimate each one separately, the resulting combined timeframe is much more likely to be representative of the actual time it will take to complete.

One thing to keep in mind though, is that the figure quoted is just that — an estimate. Developers are inevitably asked to do things each day that they haven’t done before.

Whilst they may have a good idea on how something will work, or even if they’ve implemented something almost identical before, there will always be new things and quirks that mean they have to work through an issue.

Finishing things on time is important and every developer knows that. But finishing something that isn’t going to break is even more important, so allow the developer the time to do that if they need it.

Don’t enforce inappropriate tools

When a task is completed, developers will often neglect to update the project management software to alert others that the code needs to be reviewed, staged and tested.

Every developer loves his work being deployed to production, so this seems like an omission that should never happen. But, it does — and frequently.

This can be critical for a project manager so they’re informed about the work that’s getting done during the project, so why do developers not do this?

Often, it’s down to the tools.

Why do developers have to switch from their coding environment to a tool such as Basecamp to close a ticket?

Developers like to be in a code editor or in a Terminal committing code, pushing to a version control system, and moving on to the next challenge. Loading up a project management application, logging in, finding the correct ticket and updating it disrupts that flow and takes them out of the programming mindset. Consequently, they update the code and move on, and sometimes don’t remember to log in and update the ticket.

Surely there has to be a better way to manage the closing of tickets?

Let developers manage tickets from their code

Most project management software has an integration ecosystem that allows commits to be pushed to a version control system to update a ticket’s status.

For example, if you’re using GitHub to manage your issues, the developer includes text like Fixes #123 and when they push that code, the issue will automatically be closed.

Using a system like this, the developer can continue his development workflow without interruption, but still alert people that issues have been tackled and completed easily.

This system can be taken even further when combined with other tools such as Slack.

Wouldn’t it be great if you were informed in Slack every time a developer committed an update.

If the Project Manager uses the same communication tools as the developers, it’s possible to set notifications so that as soon as an issue is closed by a commit to the version control system, a message can be sent directly to the project manager or broadcast for all to see.

When tied with a continuous deployment system, this closure of a ticket can also trigger a deployment so that the approved change is live immediately.

When this system is set up fully, the developer doesn’t need to interrupt his workflow to deal with project management issues, the project manager is notified that tickets have been closed immediately, and the product can be deployed so that the change is visible to all.

With this kind of setup, even if it’s only the notifications, developers can easily keep everyone up to date without any extra effort, and without resorting to using a project management tool directly.

Where project managers and developers collide

These three areas are the ones that I have encountered most frequently at organisations where project managers and developers collide. Using the above solutions the problems that they have faced have been smoothed out over time, and everyone has been able to keep everyone else updated and happy.

And, with happy developers and project managers, all projects can run smoothly!

This is a guest post by Matthew Davis

Matthew Davis is a developer and speaker from Stoke-on-Trent in Staffordshire. He specialises in in Laravel and Symfony and has a strong passion for decoupled, clean code. He’s also a recovering musician, having spent five years touring the world on cruise ships playing drums and keyboard.


Originally published at boagworld.com on August 2, 2016.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.