Domain Champion. 2. Hoarding the Code. 5. Unusually High Churn. 8. Bullseye Commits. 11. Heroing. 13. Over Helping. 15. Clean As You Go. 18. In the Zone.
371 KB – 53 Pages
PAGE – 1 ============
Find out how Data-Driven Engineering Leadership has transformed hundreds of organizations worldwide. ﬁAll software companies reach a certain scale where it becomes increasingly di˜ cult to write code and release new product. I can™t imagine a company like ours operating without Pluralsightﬂ Mathew Spolin, VP Engineering, AppDirect ﬁPluralsight Flow™s metrics really get to the heart of helping ensure my team is e˚ ective.ﬂ Michael Baj, CTO, 128 Technology ﬁWithin days Pluralsight Flow was transformational for me as a manager. Now I can accurately assess how my team is doing.ﬂ Ivana Naeymi-Rad, VP Engineering, IMO ﬁWe could not scale without Pluralsight Flow. We just would not have the visibility we need to tell us when we are making a wrong turn.ﬂ Adam Abrevaya, VP Engineering, CloudHealth by vmware ﬁThere is no other platform that provides work˛ ow and process improvement data like Pluralsight Flow. We use it to surface insights that drive continuous improvement.ﬂ Kevin Leclair, Director of Engineering, Aaron™s Inc. ﬁIf we were not using Pluralsight, it would be like going back to the stone ages. We rely on the met- rics and the visibility Flow provides us.ﬂ Rob Teegargen, VP Engineering, DealerSocket A ˜ eld guide to help you recognize achievement, spot bottlenecks, and debug your development process with data 20 patterns to watch for in your engineering team 20 Patterns to Watch for in Your Engineering Team A ˜eld guide to help you recognize achievement, spot bottlenecks, and debug your development process with data 20 patterns to watch for in your engineering team
PAGE – 3 ============
Table of contents PART 1 Domain Champion 2Hoarding the Code 5Unusually High Churn 8Bullseye Commits 11 Heroing 13 Over Helping 15 Clean As You Go 18 In the Zone 20 Bit Twiddling 22 The Busy Body 24 PART 2 Scope Creep 27Flaky Product Ownership 29 Expanding Refactor 31 Just One More Thing 33 Rubber Stamping 35 Knowledge Silos 37 Self-Merging PRs 40 Long-Running PRs 42 A High Bus Factor 44 Sprint Retrospectives 46
PAGE – 4 ============
Introduction At Pluralsight we believe e˚ective engineering managers are also e˚ective debuggers. E˚ective managers view their teams as complex interdependent systems, with inputs and outputs. When the outputs aren™t as expected, great managers approach the problem with curiosity and are relentless in their pursuit of the root cause. They watch code reviews and visualize work patterns, spotting bottlenecks or process issues that, when cleared, increase the overall health and capacity of the team. By searching for ﬁwhy,ﬂ they uncover organizational issues and learn how their teams work and how to resolve these problems in the future. 20 patterns is a collection of work patterns we™ve observed in working with hundreds of software teams. Our hope is that you™ll use this ˜eld guide to get a better feel for how the team works, and to recognize achievement, spot bottlenecks, and debug your development process with data.
PAGE – 8 ============
Start a new conversation in your next one-on-one:1. Acknowledge their expertise and encourage them to share that expertise with others. Ask them who, if anyone, would bene˜t from participating in code reviews in the domain to learn best practices. 2. Ask them what they like to work on Š ˜rst generally, then speci˜cally. 3. Ask them if they are willing to take on a small assignment outside their domain in part to help share the best practices they™ve developed re˜ning the code in their domain. Inch the engineer out of their domain using small, low-risk tickets. A little bit of diversi˜cation can go a long way toward minimizing attrition risk and maximizing best practices. 4
PAGE – 10 ============
2. Hoarding the Code This pattern refers to the work behavior of repeatedly working privately and hoarding all work in progress to deliver one giant pull request at the end of the sprint. It™s not uncommon for programmers to wait until their work is done to share it. In creative and research-intensive ˜elds, it can be a natural tendency to avoid sharing work when it™s only just started. There are plenty of reasons why this might be: a fear of having others judge the work in progress, a fear of others taking ideas, or a desire to make the whole process seem e˚ortless, to name a few. Whatever the reason, the heart of the problem is this: the more an individual saves up their work, the less they collaborate with others. Working alone is inherently riskier than working with others. And software engineering is a team sport. This tendency to work privately and then submit work all at once doesn™t just limit and slow down the individual Š it™s damaging to the team™s progress as a whole. Submitting work all at once means that there weren™t any opportunities for collaboration along the way. Even more, once the work was submitted, someone else had to review all of that work. So naturally, this work behavior can also lead to lower quality code Š both from the Submitter™s standpoint (who didn™t check in their work early to get feedback or notice potential missteps), and the Reviewer™s perspective (who likely doesn™t have enough time or energy to adequately review all of that code). When you see large and infrequent commits, ˜rst consider the pattern™s duration (have we seen this pattern for years, or has it only recently been visible?). This information can help determine whether this is the engineer™s preferred way of working, or if this is caused by something outside the normal development process. MTuWThFEng 1Eng 2CODE COMMITS THIS WEEKHow to recognize it Large and infrequent commits can be a sign that the engineer is working privately until their project is ˜nished, and then submitting their work all at once. This pattern is typically ˜rst seen in the Work Log report but is also identi˜able in the team™s Review Work˛ow. These PRs are larger and usually come later in a sprint or project. Because of this, they™ll typically either take a longer time to review (relative to the team™s average) or will get a lower level of review (see Review Coverage). 6
PAGE – 11 ============
It™s also common for these engineers to show lower than average Receptiveness in the Submit Fundamentals. When people work in isolation, only submitting it for review once they™ve decided it™s the ‚right™ solution later in the sprint, it™s generally much more di˝cult to take feedback on that work objectively. What to do Above all else, be compassionate. Odds are, you™ve recognized this pattern right before or just after the end of a sprint, so these engineers are likely tired, stressed, and worn out. Make sure they get the time and space they need to recover from delivering such a big payload. This can be great timing for an impromptu and informal 1:1. Going on a walk or getting co˚ee, for example, can keep the conversation casual. Get them talking about their latest project, ask what went well and what didn™t, and recognize their achievement. Along the way, bring up the topic of team collaboration, and how saving work until it™s completed leaves little room for learning from others throughout the process. When teams do work together throughout a project, they can learn from each other™s perspectives, reduce uncertainty and move faster, and even ˜nd improved solutions to the problem. In practice, that might look like submitting work far before the engineer thinks it™s ready for a review. 7
371 KB – 53 Pages