How does the Plandek team use the Dependabot to maintain important dependencies?

We absolutely love running retrospectives with our teams here at Plandek. In any organisation, retros give you the dedicated time you need to step away from your day-to-day work and focus on what you can learn about improving your team for the future.

Like all software teams, the Plandek crew is constantly trying to improve and find software delivery metrics that help drive and measure our improvement. I’m yet to be convinced that there’s a level of Agile DevOps maturity a team needs to reach before they can get value from metrics: utilising the power of well-chosen metrics helps us identify our challenges faster and gives us a standard to measure ourselves against as we grow.

One particular issue this Cycle was the impact that maintaining dependencies was having on progressing the work we’d committed to our customers.

What was going wrong?

In our last Cycle, we couldn’t deliver two important user stories that we’d committed to. It’s always disappointing when you don’t deliver what was planned. We knew that our missed deliverables didn’t have anything to do with the team not working hard enough or not putting the hours in – everyone was working to the top of their scope.

This begged the question: why couldn’t we deliver?

We looked into our Cycle data and it was clear that the team had been focussing on bugs that were created by our QA team. Some of these bugs were a direct consequence of upgrading lots of Pull Requests that had been generated by the ever-dependable Dependabot.

Dependabot-Generated Pull Requests vs. Associated Bugs | Plandek Dashboard

How were dependencies affecting our output?

The chart above shows the number of Dependabot-generated Pull Requests and the subsequent number of bugs created in the system. For January, we could see that there were:

• A high number of dependencies to upgrade (who knew that January was the month to release updates?)
• A high number of bugs caused by regressions from upgrading

As always, the team had worked really hard, but they were being consumed by dependencies and associated bugs.

Namely, our team lead was ultimately being consumed by these dependencies. He’d long ago volunteered to be the one to manage and maintain all of them (something I’m sure is common among a lot of dev teams out there). With him consumed and the rest of us focused on bugs, we couldn’t deliver the two user Stories to which we’d committed.

Dependabot-Generated Pull Requests | Plandek Dashboard

The chart above shows the Dependabot-generated Pull Requests and a series for each of the engineers who either closed or merged the PR. Guess which colour our Team Lead is…

How did we fix our dependencies?

Equipped with this new information, we now had to think about what to do next.

Upgrading and maintaining dependencies is a core part of good software development practice, but we want a little more control over when we do it and the impact it has on us delivering business value.

As such, we have an initiative for next month, which is to :

1. Share the Pain Love: Ensuring that more than one member of the dev team is managing the upgrades reduces the impact on one member of the team (in our case, a key member of the team). It equally encourages professional growth across more of our team members.
2. Deal with Dependencies Weekly: Rather than allowing the backlog of dependency updates to grow, the team will triage and address them at shorter intervals. Smaller sets of changes reduce the risk of regressions.
3. Prioritise Dependencies Against Features: When a dependency update has more complexity than usual (e.g. a major version upgrade rather than a patch), we will prioritise it against other features we’re trying to develop.
4. Measure and Learn: Now that we have both of these metrics, we’ll be monitoring our performance regarding initiative using the data from Plandek.

What does the team think?

Finally, the following are a couple of points on the impact this initiative will ideally have on our team:

Luke – Head of Product

This initiative will give us the ability to prioritise larger dependency updates along with everything else, so there’s no surprise for the business.

Edu – Lead Developer

This should ease the stress of having an additional workload that was hidden from the rest of the team, while also being given more time to focus on the core work we want to get done.

Jef – Head of Engineering

The initiative allows us to guide other team members in helping with dependency management, upskilling them and sharing knowledge along the way. It will also increase the visibility of necessary – but often unplanned – work impacting the throughput of the teams.

Maryna – QA Lead

I expect this to reduce the number of situations where the QA team have to put out fires as we have updated everything at once.

Key takeaways

1. Using Plandek to measure the number of Pull Requests created by the Dependabot, we gained new insight into work that is usually unseen. Overlaying that with defects generated made the impact visible.
2. Understanding this impact allowed the team to put actions in place that will improve the way we approach these going forward.

About Plandek

Plandek is an intelligent analytics platform that helps software engineering teams deliver value faster and more predictably.

Plandek mines data from delivery teams’ toolsets and gives them the opportunity to optimise their delivery process using both intelligent insights and predictive analytics. 

Co-founded in 2017 by Dan Lee (founder of Globrix) and Charlie Ponsonby (founder of Simplifydigital), Plandek is based in London and currently services the UK, Europe and North America.

Find out more about Plandek here: The Plandek Difference.