Is what we’re doing driving value? A look inside our Engineering process

As engineers we need to constantly ask: is what we are delivering really driving value or is it just something shiny that we tech people want?

Future of Work

We’re a customer-centric organization focused on value creation. As engineers we need to constantly ask: is what we are delivering really driving value or is it just something shiny that we tech people want? If we can’t articulate the value we are driving in a sprint, we aren’t focused on the right stories.

Creating a culture among remote workers

When we first set out to build our product and engineering team at WNDYR, we wanted to stick with the remote culture that existed and build a high-performance engineering environment. 

As a starting place, I looked at the high-performance teams that I had worked with in the past. Then I reflected on the teams I had worked on where it felt like Agile was broken and they couldn’t reliably deliver software. I tried to compromise between both by asking: what worked, what didn’t work, and how could we adapt the already existing processes to a virtual team.

The Process Drives Value

Like most modern software development teams, we needed a more “agile” process. Old school approaches, like Waterfall, struggle to deliver at the same level of consistency that Agile can provide, as well as the ability to pivot as the business needs us to. Agile is very focused on driving value on a consistent basis, which is key for any customer-centric business focused on value creation.

With that in mind, I started with the basic tenets of Agile: Grooming, Planning, Daily Standups, and Retro. Despite our spin on these, anyone with Agile development can recognize them. 

How to adapt Agile tenets for a remote work style

Is Agile the way to drive value?

You start out with a story. A story is just a task at a high level. 

What makes it different from the way work is traditionally tasked is it starts with the end user’s perspective. This way, you ensure that you’re focused on the customer and on delivering value. Starting with that story, we then figure out how to implement certain features. This is driving value for the end user.

From here, stories go into a backlog. 

Backlog Grooming

Backlog grooming is the process of prioritizing the stories and relaying all necessary details in order to direct workflow and communicate expectations.

We do backlog grooming like a typical Agile team. We get on a video conference, order our stories in the backlog, fill in details and acceptance criteria, and attach designs to the stories—all pretty standard. We’ve found when doing remote work that well-specified acceptance criteria is essential in order to ensure that instructions and expectations are clear to everyone.

Planning For Driving Value

Sprint planning involves estimating the size of the stories and, as a team, communicating what we intend to deliver by the end of a sprint, whether internally, or to the client.

Our sprint planning happens via video call, like everything else. It’s important in a remote context to do all meetings as video meetings and for people to have their cameras on. It really helps the team connect, communicate, and stay engaged. 

When planning, we follow these basic steps:

  1. Calculate team capacity for the upcoming sprint:

We check the vacation calendar for the upcoming 2 weeks for any meetings out of the ordinary. Then, we calculate the capacity of each team member to know how many points we are going to target. 

  1. Pull a story off the top of the backlog and start bidding the story points

We deviate from traditional Agile in terms of how we handle story points. Many teams do points as estimates of complexity. They will have a sizing ladder and try to bid stories relative to items on that ladder. In my experience, teams that have taken that approach have very mixed delivery and many failed sprints; there will be stories that are low complexity with a bunch of work, or high complexity with very little work. 

Instead, we estimate the level of effort, where 1 point is equivalent to 1 day. When we bid a story, at say 1 point, that means in 6 hours the code should be written, unit tested, reviewed with feedback addressed, and merged into the main branch. By estimating the level of effort, we’re able to deliver predictable sprints so the business knows that they can count on us hitting our deliverables. To do remote planning poker, we use the website:

  1. Double check that the sprint isn’t lopsided:

Once we’ve pulled and bid stories to capacity, we check that the work is balanced according to the skillset of the team. If it’s all back-end work, but most the team focuses on the front-end, the likelihood of a successful sprint goes way down. While we want people to grab whichever stories interest them, and avoid knowledge silos, we have to make sure the work mix aligns with the skill level.

Daily Standups and Driving Value

Daily standups help us check in every day in order to keep the sprint on track and identify and resolve any work-obstructing blockers. They allow us to determine whether a sprint is in danger of not landing all the stories, at which point we’re able to make adjustments and deliver what we had originally committed to.

Since we’re a remote team, dispersed across all different time zones, all of our daily standups are held virtually.

We do our standups in our instant messaging application. We have a dedicated “Team Sprint Channel” in which each member completes a basic sprint template:

  • What I did yesterday
  • What I’m planning to do today
  • Any blockers that are affecting my work
  • Something that I’m happy about today

The last point would probably strike Agile practitioners as odd, but studies have shown that gratitude changes our brains and makes us happier.

After running this framework for some time, we added a fifth part to our check in: the Sprint Update.

We found that, by checking in on developing stories, we can detect any danger of slipping early on and get everything across the line. People don’t necessarily want to raise a blocker for little things, but checking in regularly helps overcome this. On other teams that raise blockers early and often, this may not be needed; however, high performers tend to attempt overcoming their blockers independently and end up struggling for it.

Sprint Retro

Sprint retrospective marks the evolution of our processes, as we identify what isn’t working for us as a team. We weigh what went well and what didn’t after completing a sprint, and use this feedback to improve subsequent sprints.

We start our sprint retros by putting 7 minutes on a timer. In a separate text editor, each team member responds to the following:

  • What went well?
  • What could have gone better?
  • What did we deliver for the partners, customers, and business?
  • Shoutouts!
  • Ideas for improvement

Once the time is up, we go around the virtual room and read our responses to the questions. We put our answers into a shared document and review action items taken in the last retro to check their completion statuses. Then, we go around and review everyone’s “what could have been better” to prioritize actions items that could fix our processes. 

Next, we review everyone’s ideas for improvements. These can be changes to our Agile processes or systems we need to put in place to help us in our work. These suggestions get turned into action items and are assigned to the respective talent. Finally, we go around the virtual room and address any other team issues, and conclude our sprint retro meeting.

Moving forward

WNDYR is all about weaving together work and life.

Work hard and play hard; even when cranking out lots of work, we have fun doing it.

We’re always looking for ways to improve our processes, especially when it comes to scaling as our team grows and we become a larger organization. 

By getting a strong engineering culture in place when the team is small, you can then spread those initial engineers into multiple scrum teams and they will carry forward that culture to the new hires. 

The key when managing multiple scrum teams is maintaining communication, so we don’t end up with silos. On the one hand, you could shuffle people around regularly to mix it up, but that sort of goes against achieving stable, long-term velocity. To ensure each team has access to that technical leadership, put a senior-to-principal level engineer (that’s familiar with your platform) on each silo. Pair that with frequent engineering-wide lunch-and-learn meetings. This will help with sharing great ideas as the team grows and getting more engineers involved in technical presentations and leadership. 

We’re experimenting with new ideas around if a task were to go way off the rails. Instead of focusing our entire retro on that one task, we set up a standalone post-mortem meeting where we discuss why, how, and what went wrong. It’s an opportunity to brainstorm ideas on preventing those scenarios in the future. When we fail, we fail fast and together. And we’re stronger for it.

Whichever way we evolve, we have the framework in place to continue to reflect on our process, make an impact on the future of work, and teach others to scale their virtual teams in the modern work environment. That’s what value means to us.

Similar posts

Get notified on new future of work insights

Be the first to know about WNDYR’s latest work and productivity insights to drive a successful enterprise digital transformation