I once had a manager of mine ask what he should be focusing on. My answer was “adding business value and team cohesion”. Two pretty broad topics but intentionally so because it’s easy to ask yourself if what you’re working on ties into one of those two things. Separately, I had a friend that had stepped away from the day-to-day of his teams and they suddenly stopped executing. We discussed this and again it boiled down to lack of team cohesion. To me, there are a few core things you can do as a leader to help your team work better and smarter without wading in too closely or accidentally micromanaging them.
Team empowerment
The first big one is to empower the team members themselves. You don’t want a team of order takers because then you constantly have to generate detailed work for them, and when they run out of work, they twiddle their thumbs until new work is handed to them. You want each person to truly understand the ‘why’ of what they’re doing. This lets them think about the problem themselves and engineer a solution to solve that problem. This might be exactly what Product defined in the story requirements, but often it’s different in small or large ways.
Sometimes doing this requires a reboot of how a team works. I once inherited a team that was cranking out stories but ultimately the work being done had no material effect on business metrics. I had to jump in and question each engineer on each story “why are we doing this?”. If they didn’t know, I threw the card in the backlog and asked Product to explain it better. Then you can follow up with “how will we measure the success of this change?” Again, send it back if there’s not a clear answer.
Another key way to help get people moving in the right direction is to share the business KPIs that the company is trying to improve and the company goals around those metrics. If there’s not a clear tie from the day-to-day work to those metrics, go through the effort of cascading those goals into department goals, team goals, and individual goals, and show people how they are inter-related. When a team can see their work moving the needle in the bigger picture, you’ll see a lot more creative solutions come up and the team will help prioritize and drive the roadmap to see the benefits for themselves. This will also help stop doing tech work for tech sake. All work should tie into something benefiting the overall business.
Cycle time measurement
Cycle time is a common measurement in agile software development — it’s essentially the time between something being started and when it’s completed. Many project management tools can measure and report on this for you, but my preferred way to manage cycle time is by looking at pull request activity or lack of it at each step of the way. When pull requests don’t have any activity for a while, they become stale which is one of my strongest pet peeves as I think they are very negative for several reasons:
- Code constantly changes and stale PRs can cause conflicts or unexpected behavior the longer they are open.
- It’s difficult to context-switch so the longer time between development and testing (and ultimately release), the more time it takes to address any issues that arise.
- It’s bad to fall behind in sprints and hurts overall team velocity.
- It’s bad for team morale in that the story was important enough to work on, but not important enough to ship.
- The whole team ends up feeling like they are doing unimportant work.
How I keep an eye on stale PRs is simply to create three links with the right search criteria across all app code repositories for 1) draft PRs, 2) PRs in code review, and 3) approved PRs awaiting testing (in my git strategy, testing occurs on the branch-level and QA Engineers do the merging to the main branch). When you look at these links, it tells you how long it’s been since the latest activity.
The first time you do this, you will likely find at least a few forgotten PRs that are over a month with no activity. I would personally just close those without thinking, but you may want to see if there’s anything of value to keep. Then start setting a shorter and shorter threshold and nudging whomever you need to for an update, which could be as simple as a comment with the current status. My personal strategy is to start with ensuring nothing goes more than 7 days without activity. Then once I’ve achieved that, I move the number to 5 days and chip away further. Finally, I move my mental threshold to 3 days and set a reminder to check on these three sets of PRs every Thursday morning. If something was started in the prior week and hasn’t been touched at all this week, it’s a red flag that needs to be investigated further.
There are several different issues that could be at play depending on the stage of the PR:
- If you have a low number of draft PRs, engineers may not understand the value of Continuous Integration tools occurring earlier in their development cycle, or they may need coaching on how to chunk their work into smaller and more meaningful commits (vs a single large commit after several days of work).
- If draft PRs are getting stale, engineers could be getting stuck, going down rabbit holes, continually wanting to start on new more-exciting/challenging stories without wrapping up previous ones. There could be some coaching opportunities around not multitasking so much, and empowering people to unblock themselves and reenforce their responsibility to shepherd their work through all the development stages.
- PRs waiting for code review are the “easiest” to address because the heavy lifting was already done. You just need to ensure that the reviewers on the team have the mental headspace and physical time to perform reviews (and potentially expand the pool of reviewers to help spread that skillset around the team).
- After code review approvals, PRs move to the testing queue, and I’ve found that queue is most prone to being distracted by higher priorities. Stories of all shapes and sizes continually feed into QA and Product is highly attuned to pushing through the priorities of the day, with less focus on the slower moving pieces. If the testing queue gets too backed up, it’s not as simple as the other stages because new PRs never stop coming. Often the solution here is to get the testers involved earlier in the process so they understand the context before the work is done, start on any automation ahead of time, and ensuring that any requirements changes during development are fully documented. Occasionally you do have to force an older PR to the top of the queue just to get it out the door too.
Github activity
The last big area to monitor is also the trickiest to get right. The first tricky part is that you need to understand what activity your teams should be doing on any given day in order to look for anomalies. If you teams are following the release-when-ready model it’s much easier as activity is generally expected to be similar every day of the week. Without release-when-ready, you’ll have different expected activity during code freezes, bug fix days, and release days. The second tricky part is that you have to continually remind yourself that the focus is on the trends you can identify instead of micromanaging specific stories, PRs, or commits. Lastly, once your engineers know you look at their specific activity, some may try to game the system.
Usually I’ve found that inconsistent activity or lack of activity is often the sign of broader team issues to address:
- Perhaps the team or specific engineers are in too many meetings and don’t have time to work on feature delivery. I once had an entire team have zero commits on two Fridays in a row. Upon digging, it turned out that retro and sprint planning had organically grown to over three hours of meetings, sucking away any energy people had to wrap up work before the weekend. We ended up moving a lot of the meeting content to asynchronous prep work for a smaller group of people (ex. creating retro boards to gather feeling ahead of time, grooming the backlog and buttoning up requirements before meeting with the team, etc).
- An engineer might be struggling with unclear requirements or missing important context causing them to meet and discuss with others more so than normal. Sometimes people aren’t immediately available either, so they may be sitting and waiting for the meetings to occur as well.
- Sprints might not have estimated correctly and engineers might feel swapped and struggling with what to work on next, or they might run out of work to do and not know or be empowered to pick up additional work from the backlog, which leads into the last point…
- Sometimes the engineers wrap up their sprint’s worth of work but then there’s nothing queued up for them to do next. The backlog must remain groomed and prioritized, for ideally a week or so of work, and importantly the team must have a shared understanding that work is ready to be picked up (I once had a team that had a backlog ready to go but the team didn’t know they should be grabbing from the top!).
Of course you’ll find issues with specific engineers too, such as:
- Engineers stuck trying to understand too much of the system before working on a specific related feature.
- Engineers spending too much time on a specific task without asking for help. I prefer timeboxing work to a specific number of hours. If you can’t figure something out in let’s say 2 hours, then ask to pair up with someone that’s worked in that area before, talk to your manager and ask for help, or even pass over the story to someone else.
- A general sense of apathy or lacking a sense of urgency. This is often linked to not understanding the ‘why’ or knowing how what they’re working on ties into the bigger picture.