A Day in the Life of a Cloud Common Services Engineer

Whether pairing, solo programming, playing strategy games, or exploring on an upskill day, our CCS team is serious about making agile fun.

Guidewire Engineering Team

Published in

Guidewire Engineering Blog

13 min readApr 22, 2022

Authors: Anoop Gopalakrishnan (VP Engineering) and Muralicharan Gurumoorthy (Senior Director, Engineering)

Top left: Toronto, ON, Canada; Top right: San Mateo, CA, USA; Bottom left: Birmingham, AL, USA; Bottom right: Bengaluru, KA, India

Introduction

In case you missed it, three of our Cloud Common Services (CCS) interns at Guidewire shared their internship experience in a previous blog post. (Go check it out!) In that article, they touched on some of their daily activities, including pair programming (pairing) and their diverse learning experiences. In this blog, we’ll talk about the benefits, learning opportunities, and techniques we have used to effectively formalize pairing and Test Driven Development (TDD) within our group.

Daily Routine

Certain formal exercises that we engage in on a daily basis are valuable to the success of our 2-week sprint cycles.

Pre-requisites

Since we utilize the benefits of pair programming, the cognitive overhead is lower if best practices and tools can be encoded in a repo. To ensure that each developer has a similar toolset installed on their machine, we use a group-specific dot file for setting up commonly used tools on Mac. This step simplifies the process when we are pairing and move from one machine to another.

Start

A typical day starts around 9:00 AM. We use the first 30 minutes as MyTime — each team member decides how best to use this time. It is often used to catch up on communication threads or for self-training and learning. This includes:

Catching up on Slack threads or emails
Completing an assigned corporate behavior/security training
Engaging in a self-paced O’Reilly course or learning material
Learning about new frameworks and technologies relevant to the work
Preparing updates for the stand-up

Standup

The standup, which starts at 9.30 AM, is one of the most important rituals we do to stay aligned as a team. It helps us to coordinate on projects and ensure we are focused on the same outcomes, approaching roadblocks as a team, and sharing interesting technical findings as they are discovered. The standup also sets the stage for the tasks that the team will focus on for that day. After the standup is done and pairs for the day are decided, we will check to see if there are any discussion points we should address from the parking lot and/or follow up on interesting topics that were raised during the standup update.

We use Pair.ist as our pairing and standup board. And we shuffle the pairs every day to make sure required knowledge and skills are spread across the team. We also do everything we can to help each pair succeed. For example, we will keep one person anchored on a specific track (i.e., a Jira story) for 2 days and then stagger the rotation of the pairing partner to ensure we have redundancy in knowledge and can reduce the risk of missing delivery milestones. We also make sure we don’t pair two less experienced engineers to work on a project with no prior knowledge or context.

We do acknowledge that this approach to pair programming does require additional context switching for our development team. However, this offers each team member more flexibility since the knowledge is spread across our whole team, ensuring that one or two people aren’t required to take on all the maintenance work by themselves.

Morning pairing time

After the stand-up, each team member settles into pairing with their partner for the day. Often, one of the pairing partners will have more knowledge about the track they are working on. This could be due to that person working on the product the day prior or overall engineering experience in general. Because of this dynamic, it is imperative that both pairing partners openly communicate to understand and align on what needs to be achieved for the day. Each pair starts by either picking up a new user story from the sprint or continuing on an existing user story. Once there is alignment on what needs to be done and prior context has been shared between partners, the pair starts writing tests. These start with writing behavior-driven development (BDD) acceptance tests. The teams use different tools depending on the product they build, but karate seems to be one of the more popular tools among our team members. During the process of writing the acceptance test, it is possible that a discussion is warranted with either the Product Manager (PM) or Tech Lead (L1) to fill any gaps in the acceptance criteria that would cover the required use case. Writing the acceptance test up-front ensures that both the pair and the PM are aligned on what needs to be built at a feature level. The pair will then write an integration test followed by a unit test to validate the design of the feature code. Using git plugins — like git-duet — pairing partners are able to split credit equally and ensure rotation between author and committer in the git history. Take a look here for more information.

In order to stay fresh, we also encourage teams to take mini breaks as needed to grab another cup of tea or coffee, take a bio break, or simply stretch.

Lunch

Around noon, we take a 1-hour break for lunch. This is free time to unplug and take a break. During in-office days, folks often grab lunch with friends/colleagues, walk around the campus, or play games.

Afternoon pairing time

We get back to pair programming at 1:00 PM. There are multiple strategies that could be used for both the morning and afternoon pairing sessions. Two of the main strategies are Driver-Navigator pairing and Ping pong pairing (compare strategies). When you start pairing for the day, you and your partner will decide which strategy to use. The preferred strategy often depends on the nature of the work. One thing that successful pairs often do on a regular basis is to articulate the goal for the day before they start pairing, which helps to improve focus and clarity in their tasks. Regardless of the strategy, the consistent goal of the process is focused on switching responsibilities at regular intervals so that both pairing partners are engaged and in sync.

End of the day

Our pairing finishes at 5:00 PM, with a final wrap-up at 5:30 PM. This last 30 minutes is set aside for MyTime again (as described at the beginning of the day). In addition, we review what hasn’t been completed or items that need further discussion. These topics are added to the pairing board for us to address in the next standup. This process helps us track the various discussion points that we need to communicate with the team so everyone stay in the loop. Even though this is how we end our day, adding to the discussion list can happen at any time throughout the day. Our pairing partners are also required to make one last commit before they close out their day, but they are also encouraged to make commits regularly throughout the day as well. You could use a WIP branch or a feature branch to commit the in-progress code or even merge it to the main branch. And finally, we update Jira with the current status of stories and also indicate what’s pending.

Upskill day

One day per sprint is unlike any other typical pairing day — which is our upskill day. We believe that pairing is helpful in forming a shared context as well as ensuring we don’t have a single point of failure. However, at times it can also prevent us from doing more development explorations. Upskill day helps us bridge that gap.

Before the upskill day we file exploration tickets in Jira about things we plan to investigate. Then, on upskill day we do that exploration and formalize findings on a Confluence page and/or on Jira itself. If the exploration hasn’t reached the desired conclusion, it will spill over into the next upskill day. At the end of the upskill days, we meet for 30 minutes to talk about what we did, what we learned, and how we can leverage the findings from that exploration. All the explorations and formalized findings are shared across teams so everyone can benefit.

Sprint Ceremonies (bi-weekly)

By now, you have a good idea of what our typical engineering day looks like. Besides this regular routine, there are days when we participate in more structured agile/sprint ceremonies. Our sprints follow a two-week cadence, from Monday to the second Friday.

Sprint Pre-Planning

This is a meeting that happens between the Tech Lead, PM, and Engineering Manager. Optional attendees include subject matter experts or stakeholders. These optional attendees often participate in order to better understand the theme for the upcoming sprint and decide which stories align with the theme. This is a soft prioritization — they can be re-arranged as part of the regular planning if needed. This meeting focuses on adding more details to the user stories to make sure they are consumable by the team and also to review acceptance criteria. Every effort is made to split stories if they are deemed too large and link them to blocker or dependent stories. This helps to make sure we can parallelize work on stories as much as we possible. This meeting to plan the next sprint usually happens towards the end of the current sprint, on the second Thursday (one day before the end of the current sprint).

Sprint Planning

This meeting is where the team comes together to discuss items that have been prioritized in the backlog and discuss point values based on Fibonacci series. The discussion usually starts with the theme for the sprint. For example: “On-boarding new customers” or “Delivery of platform in a pipeline” or “Integrating with Okta APIs” etc. Then starting at the top of the backlog, the Tech Lead/PM will pick an item to discuss. They will define the story and answer any questions pertaining to the description of the story. Then the team will reveal their point estimation for the story at the same time. If there is a huge variation in the values, we will ask the person with the highest point estimation to discuss the factors that went into their ranking. This might bring up points that were missed by other team members. The discussion continues until the complexity/effort is well understood. It can also be the case that the complexity was overestimated so we’ll also ask the person with the lowest point estimation to discuss their thought process. In short, the discussion between highest and lowest point estimations will continue until consensus is reached. Then the story is re-pointed. One of the most important items the team discusses is the acceptance criteria required to close a story. The team will also create necessary sub-tasks for each story as needed. We have used various tools to help us in this estimation process. During the pandemic, we utilized Scrum Poker Tool. When we are in person for sprint planning, we typically raise fingers for story point estimations.

Sprint Review/Demo

This meeting is typically held towards the end of the sprint. Since Friday is the last day of the sprint, we use that day to demo key stories/features accomplished to PMs and other stakeholders. The meeting includes all members of the engineering team, PMs, SMEs, and stakeholders. Since we use pair programming for all of our work, there is no single owner for a story. The team decides on who demos a particular story based on who recently worked on it or completed the story. This meeting is NOT to review acceptance criteria for each story or a time for the PM to accept or reject the story. Rather, it’s to review story completeness, map the outcome to the theme we picked, and discuss any deviations or new findings which need to be tracked as new backlog items. The team also talks about any change to sprint scope (new story pulled in during sprint, or removed/descoped) as well as stories that were not completed and will spill over to the next sprint.

Note: In some cases, there could be a demo to the PM of the stories that are done to facilitate acceptance of stories. However, we encourage doing this throughout the course of the sprint so it is not concentrated at the end of the sprint or during this meeting. The PM can approach the pair or Tech Lead to understand nuances of a user story when it is in a completed state ( if needed in order to accept the story) before moving the story to closed.

Sprint Retrospective

As a team, we hold retrospective meetings at the end of each sprint in order to discuss what we did well (and should keep doing), what we’re wondering about, and what was outright bad (and we want to change next time). We use an open-source retro application developed at Pivotal to capture this information. The team then nominates one person to be the orchestrator for the meeting — the orchestrator changes every sprint. After everyone has had a chance to add items for discussion, each person is asked to pick an item from the board (that was not written by them) to discuss. During the discussions, we will use the retro application to capture action items and indicate assigned owners. Discussing the state of these action items will kick off our next retrospective meeting. After we’ve discussed the open action items from the previous meeting, we’ll move on to new discussion items. We like to be creative in how we run these meetings to keep them engaging and fun. When structuring our retrospectives, we have utilized details from this article from Tanzu on How to Run a Really Good Retrospective.

Other Ceremonies/Processes

CCS Demo

This monthly meeting includes all members across CCS. Each team aims to demo key Features/Epics that have been delivered in the last month (over the course of the last 2 sprints). However, since the topics shared depend on Feature/Epic completeness and the relevance to the broader organization, we don’t always have a demo from every team. The responsible Program Manager facilitates this meeting and collects the Features/Epics to demo in advance from the teams. The primary goal of this meeting is to share knowledge across the CCS organization, highlight new features, give everyone on the team a broad view of the overall progress that CCS is making, and celebrate our deliverables!

Drumbeat

This is an email that each team in CCS sends out every 3 sprints (every 6 weeks) to share updates and progress. This update is not just sent to CCS, but to the entire Product Development and Operations group, which is almost half of the company! We typically have a TL;DR (if people don’t have enough time to read through the entire update) where we will call out key features/value that is delivered to the user base and customers.

Best Practices We Like to Follow

In order for any pairing session to be successful, it requires us to be empathetic to our colleagues. And we encourage our pairing teams to feel free to suggest breaks as necessary. Sometimes this means that we suggest additional breaks if we see that our pair is under the weather or feeling stressed.
The timings mentioned above are “soft” in nature and the teams take the daily start and end times listed as guidance.
A team is in better health when everyone on the team knows they can trust each other and everyone feels like they have the freedom to give and receive feedback. Open communication, without fear, empowers us to make sure we are all aligned and working towards the same goal.
With the additional understanding that they may have necessary meetings (which should be discussed at the standup), the Tech Lead pairs just as much as any other team member. They will also make sure the pairing is done in such a way that a person with equal or higher context is paired with the Tech Lead. The goal would be to minimize this as much as possible, but in the case of impromptu meetings, it’s understood that there would be some solo time for the person that is paired with the Tech Lead.
Sometimes the best way to learn is to fail. Keep this in mind when pairing with a person who is more junior. Sometimes this will mean that you will explain where we want to go with an implementation, give some directions to minimize potential frustrations, and then let the junior person try to implement. You can also help them along by asking leading questions like “What do you want to do next?” or “Sure, let’s try that and see if that works.”
We value our solo time as an opportunity to gather thoughts and help us become better mentors or learners.
Live Code reviews are part of the pair programming model. The goal is to elevate the team members to an equal understanding of practices and technology. When a pair is unsure about an implementation and they want a review, they have two options. When possible, we encourage the pair to huddle with the entire team to discuss the ambiguity or code practice. It’s easier to come to a conclusion when the topic is discussed together in real-time, as opposed to only using emails and formal PRs. There will be times, though, especially at the beginning of a project, where it may be valuable to raise a PR to the team instead. Regardless of the method used — team huddle or raising a PR — we always strive to make the entire process as easy as possible and value a fast feedback cycle.

If you are interested in working on our Engineering teams building these cutting-edge cloud technologies that make Guidewire the cloud leader in P&C insurance, please apply at Guidewire Careers.