Copyright© Waydev, Inc.
Engineering Managers’ Handbook
2
4 work patterns to look out for
We aggregated a collection of work patterns that we observed by working alongside engineering managers. Based on these work patterns, we will show you how to identify them, and how you should act.
Copyright© Waydev, Inc.
Scope Creep
3
Scope creep is a pattern whereby the originally agreed upon scope increases or changes after implementation has begun.
Scope creep can lead to missed deadlines, rising planned costs, negative impact in quality, and customer dissatisfaction.
Trends to look out for
Scope Creep - How to identify it
4
Increased Code Volume and Churn towards the end of the sprint - Project Timeline
High amounts of follow-on commits - Review Workflow
Scope Creep - How you should act
5
Scope creep is caused by poor planning and insufficient attention during design. It’s not the engineer’s responsibility to shoulder the work resulting from bad specs. Let the people who are responsible for project design know the negative impact of their actions.
By making the true consequences of scope creep visible, you create actionable solutions to the problem.
Code Hoarding
6
A common work pattern is to deliver one huge chunk of work at the end of the iteration instead of delivering incremental contributions throughout the sprint. This pattern is called code hoarding.
Code hoarding negatively impacts the velocity of both the developer and the project, while also limiting collaboration opportunities. Once the work was submitted, someone will need to review all of that work, commonly close to the deadlines, which will ultimately increase the risk of putting bugs into production and overall lower quality code.
Trends to look out for
Code Hoarding - How to identify it
7
Pushing single large commits at the end of the week/sprint - Work Log
Large pull requests - Review Workflow
Code Hoarding - How you should act
8
First of all, you need to empathize with the engineers. Chances are that you’ve spotted this pattern just before the end of a sprint, or after the end of one, so these engineers are most probably worn out, stressed, and tired. Ensure that they receive the time and space necessary to recover.
This could also be a good time for a one-on-one with the engineer. Look back at the sprint and learn from them what went well, what didn’t, and recognize their wins. During the one-on-one, let them know why hoarding code doesn’t help the learning process.
When working collaboratively, team members learn from each other, and move faster in finding solutions to the problems.
Unusually High Churn
9
Churn is a natural and healthy part of the development process and varies from project to project. We identified that the typical amount of churn varies between 15% to 30%. However, unusually high churn is often an early indicator that a team or a person may be struggling with an assignment. Bear in mind that it can also indicate perfectionism or issues with external stakeholders.
Trends to look out for
Unusually High Churn - How to identify it
10
Above average values (displayed with green) for churn code - Developers Stats & Teams Stats
*Clicking on any value will open up its corresponding trendline report.
Unusually High Churn - How to identify it
11
Prolonged low efficiency - Developer Summary
*Clicking on any value will open up its corresponding trendline report.
Unusually High Churn - How to identify it
12
Top performers in churn - Project Timeline
Unusually High Churn - How you should act
13
Firstly, determine if this is a one-time event or a recurrent issue. If it’s the latter, determine whether an external stakeholder is driving the situation. If so, show them the data. Show them how the last-minute changes or late arriving specs are slowing down the project.
You could, then, pull the ticket from the sprint, or decide on an MVP and split off the additions into a refinement sprint.
If an external stakeholder is not the driver for unusually high churn, we recommend the following:
Unusually High Churn - How you should act
14
You can set custom targets that you can track over time. You can also set up alerts that notify you via Slack or Email when a metric drops below the selected threshold.
Learn more about setting targets here - https://docs.waydev.co/en/articles/4042195-targets
Long-running PRs
15
Long-running pull requests are PRs that have been open for a very long time (more than
a week). A long-running PR often indicates confusion or disagreement amongst the team. Week-old PRs can quickly become irrelevant and turn into bottlenecks.
Trends to look out for
Long-running PRs - How to identify them
16
Open pull requests that are more than 1-week old - Review Workflow
We can notice that this PR was opened 8 days ago. It had 3 comments, and had been reviewed twice, but it was never closed or merged. We can also notice the high time to first comment.
Long-running PRs - How to identify them
17
Back-and-forth comments followed by silence - Review Workflow
- Review Workflow
In this example, PR #94 has several back-and-forth comments (represented by the half-lines) followed by silence.
Long-running PRs - How to identify them
18
Above average time to merge from PR creation - Developers Stats & Teams Stats
Values in green are above average, while values in blue are below average. In this example, Amelia Palmer and Christopher Zamora show an unusually high average time to merge from PR creation.
Long-running PRs - How you should act
19
It’s usually best to first check in with the Submitter. It’s their responsibility to get their work across the line, so they should be encouraged to surface any uncertainties or disagreements as they arise.
If there is a disagreement, get their read on it and offer advice to move it forward. Depending on the situation, get the Reviewer’s read on it as well — ideally when everyone is together in a meeting. Make a decision, and ask anyone that disagrees to ‘disagree and commit’.
Long-running PRs - How you should act
20
Managing this pattern in the long-term can be done by setting expectations around the Time to First Comment and Time to Resolve. The Pull Request Resolution report can help you gain a high-level view of outlying PRs.
Long-running PRs - How you should act
21
It’s also helpful to communicate best practices around timely response — when it takes engineers a day to respond to feedback (see Responsiveness), that can mean there’s a lot of time spent waiting on others, and the communication isn’t timely enough to be as effective as it otherwise could be.
22
Feedback
Copyright© Waydev, Inc.
Contact - Questions?
23
“Most of the world will make decisions by either guessing or using their gut. They will be either lucky or wrong.” — Suhail Doshi
Copyright© Waydev, Inc.