DEV Community: Ben Flath

Remote Pairing Strategies

Ben Flath — Wed, 08 Apr 2020 22:13:59 +0000

On our team we do a lot of what we call “pair programming”. Many of you may be familiar with this term already, but for those who aren't, pair programming typically involves sitting in a room together and tackling a particular problem or feature, often for a day or more. However, since our office is temporarily closed for safety reasons we’ve had to learn to adapt our practices. During a recent retrospective the team collected some of what has worked for us for remote teamwork since the start of quarantine.

Most of these tips and techniques can be applied to any kind of work, not just writing code! They are geared toward two people working together rather than a full team or larger meeting.

Note that many can be applied to working with another person more generally, but we found that every challenge that comes with 1-on-1 work in person is magnified when doing so remotely and therefore worth highlighting.

One final message before we begin: all of this data is qualitative, with a small sample size. By bringing this post to the community we hope to expand that and create a list that more closely represents universal trends.

Benefits

We’ll start off with the benefits of pairing on work.

The biggest reason we pair on tasks is the classic adage: “two heads are better than one.” It’s true! When two people are working on something together it is delivered more polished and complete than one person working alone, thanks to real-time review and quality-control. The people involved also report that they come out with a better understanding of the final product.

When more than one person is working on a subject this also furthers the dissemination of understanding across the team. Leaving one person to work on a particular problem means that only one person truly understands the solution and we’ll need to hope they’re around if it pops up again.

And finally, a huge benefit to pairing is you get some Real Human Interaction! As we’ve heard frequently over the past few weeks, it is important to balance our physical and mental health with our working lives. Take a few minutes at the start of a call to be social! Show your coworkers that you care about their well-being. It helps to relax your mind and takes off some of the pressure that we’re all feeling.

What has worked

Without further ado, here are some strategies and techniques that have worked for our team.

Start with a goal and milestones

This one is helpful for any project you’re working on, remote or in person. Creating a project goal and smaller milestones allows you to pick which items you would like to focus on completing during each call. Be sure to brainstorm this at the beginning if it’s not something that already exists on your project!

It is also a good idea to define your roles and responsibilities at this point. When each of you is clear as to who is doing what, it makes working independently easier if you can’t find a time to work together. If it makes sense for one person to take on more of the project, they should. There’s no sense in dividing the work equally if it will actually be harder to complete that way.

Set a working schedule

Let’s get real: most of us are working from home right now, we’re not used to it, and that has totally messed up our normal schedules. That can be good in small doses, but also stressful! Setting a daily check-in with your pair programming partner can help regulate your schedule in general, but it will also help you both get in tune with individual progress and what still needs to be done. This doesn’t need to be a video call; it could simply be ten minutes set aside to message back and forth with minimal distraction.

In addition to the short check-in, creating a daily work session will provide a block of time for heads-down work without fear of someone scheduling another meeting for you. This is especially useful when there is a short turnaround time. You don’t always need to work together during the daily session, or even to use the entire time, just keep it on the calendar!

Take turns being “the driver”

Watching someone else write code can feel like watching grass grow. I’m sure if you're reading this you are more interested than most, but after a while it gets old. Try switching off who is sharing their screen with whom regularly. Not only does this keep attention better, but it increases the sense of “ownership” around the feature. It also helps with QC, as the passenger is more likely to spot an error where the driver may be focused elsewhere.

An important part of being the driver is making sure your passenger knows what you’re doing. If they don’t, you’ll both get lost and frustrated. It helps to narrate what you are doing. Speak what you’re typing; say why you created that function the way you did; explain the unit test you’re about to write. Especially when one of you has a poor connection and can’t make out the code, this sort of explanation helps you stay in sync. Creating this shared understanding helps with continuity when you’re working separately, too.

Use a shared digital workspace

Whether it’s a shared IDE, online notes program, or whiteboard app, having a place where both users can type or draw simultaneously while talking on video chat helps describe ideas, remember bits of information for later, or provide examples for something. You may also find that sharing this out later helps other team members gain a deeper understanding of your feature.

Check on process regularly

Just like your agile (or kanban, or scrum, or…) process, your pairing process shouldn’t be set in stone. Check in every so often and ask some of the standard retrospective questions. What is working well and what could be improved? What should we keep doing, stop doing, and start doing? Any of these will work. You don’t need to spend too much time on it but be sure to ask and answer questions without ego. Remember: feedback is a gift! Use it to learn where you can improve and iterate on your pairing process.

Be patient!

Sure, you should always be patient when working with another person, but remote pairing requires an extra level of patience. Lag in video calls or screen shares may suggest that the other person is done speaking when they’re just delayed. It’s hard to read cues in body language over video that we take for granted with in-person interactions, so instead just wait another three seconds before starting to speak.

Pairing with someone remotely also exacerbates differences in the pace at which people work. Don’t get frustrated when your collaborator asks you to slow down or doesn’t know all the shortcut keys that you do. In addition, narrating while working is a new challenge for most of us, so expect that both of you will be going more slowly than usual.

Challenges

There are still many challenges remaining when it comes to remote teamwork. Here are a few we are still consciously working on.

All interactions are “meetings” now

Maybe it’s different at your employer, but with a workforce that is 100% remote, many people have found that they have more meetings on their calendars than before. Coworkers are scheduling time because they can’t just walk over to someone’s desk and ask a question. This can make setting a recurring meeting time more difficult.

Additionally, notifications from chat programs can be a distraction or privacy issue during screen sharing. Be sure to disable any popup or banner alerts before you start your meeting!

Technical issues

There are inherently more technical issues involved in coding over video calls and screen sharing than coding while sitting next to someone. You have to depend on your and your collaborator’s internet connections, the call app, any shared documents, and more. These issues can be particularly frustrating since they’re out of your control. But to reference back to the last section, just be patient! If you can’t work through a particular issue, take a break from pairing and come back to it later.

It is also important to keep in mind that some tasks don’t translate to screen sharing. Scrolling through code or webpages looking for something specific just does not work, even with the best internet connections. Small fonts or particularly detailed screens are another no-go; if you need to lean in toward your monitor to see something, your collaborator won’t be able to distinguish it.

Learning curve

Remote pairing is not easy! It takes time, cooperation, patience, and practice to do it well, so don’t expect your first work session to be flawless. It is particularly challenging for most people to talk and type at the same time. Even just explaining what you’re doing and why could be something you’re not used to.

During this learning curve you will also find the remote pairing sessions more physically and mentally demanding than in-person pairing. This is also normal! Just like the first time you give a presentation to the CEO or go for a run, some things take time to get used to. Practice. Iterate on your process. Don’t assume that the way you pair with one person will be the most effective way to pair with every person. Did I mention “iterate”?

Feedback

Let us know what you think! Have you tried any of these techniques? Do you have any of your own that you find invaluable? Let’s keep the list growing!

Balancing Dev & Ops: What is a Product Owner to do?

Ben Flath — Wed, 25 Sep 2019 22:52:56 +0000

Introduction

What’s the Problem?

As the product owner (PO) for a small software team, I have read countless blogs, training manuals, books, how-to guides, and more about how to order items in my team’s backlog. I’ve gotten tons of great advice and worked with my team to implement strategies that help us decide which features will deliver the most value to the customer. There is a near endless world of information on the subject and for that I am grateful.

However, my team is not just a development team. We are a DevOps team (or DevSecOps, if you prefer). This means our backlog is not just full of new features and improvements, it also contains bug fixes, infrastructure management, security tasks, and more. With such diverse tickets, how is a PO to compare and sort them in order of importance? What’s a higher priority: a patch fix to a production server, or creating that new front-end component a stakeholder asked for? It’s comparing apples and oranges (cookies and muffins? wine and beer?).

Team Background

Before I jump into it, let me give you some quick background on my team. We are a small team (<10 people), embedded in an established engineering consulting company (>150 people), building a product for a small, but rapidly growing, market. We follow the Agile Principles and are leaning towards Scrum, with no illusions that we are a proper Scrum Team. Our largest user base by number are the company’s clients. Our largest user base by time spent in the application are internal to the company.

Note: I am not a software developer! My background is in civil engineering and I have just enough knowledge to say the right words in the right situations and mostly understand what’s going on in the code. Any technical bits in this post are meant for background only, so please forgive any mistakes or unelaborated, non-specific statements.

What Hasn’t Worked

First, let’s talk about what hasn’t worked for us in the past. A couple years ago we embarked on a long project to rebuild our data pipeline. It changed not only how data is processed when it arrives to our system, but how that data gets transformed and delivered to the front end. The entire team worked on this for a full year. The outcome was a nearly 10-fold increase in front-end performance, and dramatic improvements reliability and stability on the back end. It was a huge win!

Except we also delivered exactly zero front end features for a full year. Yes, users were happy with the speed of the application, but they also remember 11 months of silence. What we delivered did not replenish the magnitude of good will that we lost over that time, and it took close to another year before we were in good standing with our core internal users.

Fast forward a few years as we start to replace one of our long-in-the-tooth front-end modules. This was another major project with months of planning, user interviews, design iterations, etc. The importance of delivering our first “new page” since the initial release got us excited and we wanted to knock it out of the park. So again, everyone was working on one thing. You can imagine where this is going: we delivered a great product and our users were happy! But we also started running into the limits of our system architecture as more users switched to the new module. Time for another all-hands-on-deck infrastructure project!

At this point we know that going all-in for big projects doesn’t work. But what is the ideal split between ensuring the system is secure, developing new features, and managing operational tasks?

Strategies for Prioritizing

Here are some of the strategies that have worked for our team to order backlog items. We’ve been refining this system for about a year, and in true Scrum fashion, will continue to refine it every cycle going forward. Some of it may work for you, and some may not.

Security, Requirements, Breaking Bugs

In the words of Amazon Web Services, security is “job zero”. If our system is compromised, that puts our customers’ data at risk. That is a level of trust that we will never win back. Critical security issues are always the priority!

But not every task related to the security of the system is critical. There are some changes that will improve security but are not required for the application to be secure. Others may be associated with a particular compliance or contract rule but are not for security reasons alone. What is important in situations like this is to work with your decision-makers to ensure that any deadlines give you sufficient time to implement the necessary measures without stressing your resources.

It can help to explain what the trade-offs are of setting a shorter project time period. For example, if a proposed contract would require implementing changes within three months, and you need three months of all-in work to complete it, let the decision-makers know that the next few features in the backlog will not be released to the existing user base during this time. If the contract can be negotiated to six months, you can deliver new features and still meet the requirements.

The other type of task in this category is bugs that break functionality. Anything that prevents a user from doing what they need to do is important and should make its way to the top of the backlog. That could mean sliding into the current sprint, if a large number of users are affected, or the next, if there is a reasonable workaround.

Functional Obsolescence

Borrowing a term from my civil engineering days, I’m using “functionally obsolete” to describe a part of the system that typically runs fine, but at times of high traffic may start returning errors or becoming overloaded. There are often band-aid-like solutions, like increasing processing power or available memory for a service, that can be applied easily, however the larger solution would take more development resources. Even if the band-aid could get by for a year, you’ll need to re-build it eventually.

One key for us with projects like this is to spend the time to plan out, roughly, what needs to be done and estimate the size of the undertaking. This doesn’t have to be a full set of tickets, individually sized, with definition of done and acceptance criteria, but more of a bulleted list of how the team would go through the process. The brainstorming session could help determine if it’s a 6-week project or a 6-month project, which lets you fit it into the roadmap with more accuracy. It may also reveal discrete, independent tasks that move toward the proposed solution little by little rather than all at once. From there, you need to determine how other factors, such as the risk of downtime or loss of data, customer frustration, or increased server cost, weigh into the decision on when to move forward.

If a project turns out to be smaller, or if you are close to finishing a larger project, we’ve found that going all-in for a single sprint can actually increase the sense of accomplishment for the team. Coming together and working towards a single goal, with a defined ending, can be a boost, especially when it feels like lots of projects are floating around half-complete. Better yet, end the sprint with a team lunch or happy hour!

Saves Developer Time

Now it’s getting a little tougher! This category now has no direct effect on end users, but the indirect value is hard to ignore. If a task will increase the velocity of the development team, it’s worth doing, that much is clear. But how do you fit it into the backlog?

To start with, it can help to quantify how much time or effort the task would save, and how often it’s done. If you can save an hour every week, that’s a great opportunity! If it’s 5 minutes once per quarter, that has less value. Time isn’t everything, though. A task that reduces the complexity or likelihood of human error in the team’s work should also be higher value.

The most common way we’ve found to weave tasks like this into the backlog is to pick them up when that part of the code base is touched for another reason. For example, we recently implemented automated deployment for all our services. Rather than do this all at once, we went repo-by-repo as other backlog tickets touched the services. While it took half a year to get to each repo, we were able to balance it with continued delivery of new front-end features.

Candy Jar

This is a practice that can be controversial with some in the Agile community. If a task is small, let’s say only about a half-day of work for a developer, but it isn’t going to displace other tasks of higher value, we add it to the candy jar. Opponents argue that the reason the backlog is ordered is so that when a developer is finished with one task, they can move on to the next most important. However, if it’s the last day of the sprint, and all other committed stories are complete, a candy jar ticket fills in that space nicely. It also provides an outlet for a task that may not necessarily be important now but might be nice to finish before it becomes a problem somewhere down the line.

Side Projects & Experiments

While I don’t think any of us have the resources to implement Google’s “20% of time to side projects” policy, it is important to allow some time for experimentation. Especially during large, multi-sprint epics that can get monotonous, developer burn-out is a big concern. Making sure your team is happy and engaged is essential to a healthy workplace!

This is one area in which we have not made great progress. Every few months we sit down as a team and talk about how to start working on a fun team side project, but regular sprint deliverables always seem to get prioritized. One next option would be to meet with management to discuss the importance of “extracurricular” projects and budget time to support them.

A way to make these projects more attractive is to use them as a test bed for new tools or technologies that will eventually become part of your product. That way the team can iron out the kinks and make the newbie mistakes outside of the main code base, then implement them with more refined knowledge later.

Other

Of course, there are items that don’t fit into any of the categories above. If the backlog is always ordered by value added, they may never get done.

Okay, here’s the big secret: I don’t have the answer!

We tend to pick up tasks when they feel convenient, or when a developer gets frustrated enough with something on a given day that they just make the change (or convince me that it’s important enough to add to the sprint).

Sometimes a task can be added to an existing story with a small increase in scope, such as adding half a day to a three-day ticket. The important note for this approach is that you need to make that decision before the start of the sprint, not during the sprint. If it happens during the sprint, then it’s scope creep and your sprint could be in danger of going off track. But if you make the decision before the sprint starts, the team can size the ticket appropriately for the larger scope and still commit an appropriate amount of work.

Conclusion

Let’s face it: for a PO, ordering items in the backlog is hard when it’s a bunch of new features. It’s even harder when it’s new features, security updates, operational tasks, and bug fixes! I provided a few strategies for approaching this challenge that have worked for us, but I can say, with high certainty, that there is no one right way to do this. What has worked for us may not work for your team.

Fortunately, following Scrum practices gives us frequent feedback on what is working and what is not. This is really the key to everything! Just as important is sharing this feedback with decision-makers and stakeholders to ensure that they are bought in to whatever strategies you decide to use.

Lastly, I would like to invite you all to share what strategies you use to order your diverse DevSecOps backlogs. I’m interested to learn what other teams are doing, and hopefully bring new ideas into my repertoire.