Engineering Fitness

An Agile Program Management Primer for Distributed Teams

Our job as program managers is to help create and maintain high performing teams. In most cases, this is much easier said than done. While many view the program manager as the person who creates schedules, corrals team members for meetings, and follows up on action items, in reality we do much more. In most cases, program managers help coordinate between engineering teams, product managers, and business stakeholders. In the best cases, program managers are able to assist each team to work to their fullest potential. That means helping business stakeholders achieve their vision for the market, working with product owners to clearly define their ideas for developers, and understanding timelines and progress with the engineering teams to ensure a successful delivery.

I encountered this exciting challenge when I started with Fitbit in November 2015. As a new program manager stepping into an organization that had not traditionally had a full-time program manager, my initial goal was to observe and understand the team with which I would be working. The team was split between two locations: a local business stakeholder group and a remote product and engineering organization. In the early weeks, I came to understand that the program management role had been filled loosely between business stakeholders, product owners, and development leads. Each group was enthusiastic and focused on bringing value to the company – business stakeholders had their strategies in mind to help bring the benefits of a fitness-oriented culture to the corporate world, product owners had their amazing ideas for achieving these goals, and the engineers were smart and ready to deliver to spec. However, what I soon realized was that despite the positive energy from all teams, having a distributed team meant it was sometimes difficult to stay on the same page. Although everyone had an idea of what they wanted to achieve, the messaging between teams could get lost. Without that solid base of understanding between all teams, it became challenging to effectively drive towards the same end goal.

image00

Setting up for a milestone planning meeting with our remote office

 

All programs must begin with a solid foundation of clear communication and visibility. Many teams understand that they must have a long term vision or strategy to drive their business, and most inherently understand that they must have predictability from their engineering teams to achieve this. Agile helps teams get to a better state of predictability, but without the base – being able to convey what is needed and how it is progressing – it is difficult to reap the benefits of an agile organization. Hence, after my first few weeks of observation, I began to focus my attention on building this foundation on which the rest of our team’s business would be placed.

image02

Communication and visibility sound simple enough – and there are some quick ways to achieve some initial wins. Luckily, visibility is largely built into Agile already – with Scrum, think daily standups, burndown charts, and sprint demos. Working with a remote team, however, presents several challenges. When email, video conferencing, and chat are the main means for communication, it becomes imperative to ensure that the messages are clearly understood and key decisions are documented well.

To help with this, here are six concepts that help distributed teams start building a solid foundation of communication and visibility:

1. Roles and Responsibilities
Roles and responsibilities are often overlooked – after all, everyone should know what their job entails, right? Sometimes responsibilities become blurred over time, especially when there are new joiners to teams and they weren’t well communicated at the beginning or maintained over time. It’s always worthwhile to make sure the team members understand their roles and all that is expected of them.

One useful tool is the RACI model to help team members understand who is Responsible, Accountable, Consulted, and Informed. I reasserted the roles and responsibilities when I officially kicked off program management for our team. It was useful for our business stakeholders to understand who would be consulted for their expertise and who were responsible for decisions rather than just needing to be informed. It was very useful for team members to understand who would be accountable for completing work and answering questions from the team as well. This really helped set the stage for building out the other aspects of clear communications and visibility for all our team members.

2. Meeting Etiquette
Work to establish and reinforce good meeting practices. Most important to these are taking notes during meetings and clearly documenting any key decisions made during the meeting. Action items determined during meetings should be distributed after the meeting and followed up on to ensure accountability.

One thing that some people forget is to check with their teams about meeting times. If you’re working with a team in a different timezone, make the effort to understand their working hours and the most convenient times to hold meetings. We learned after a while that it was more painful to spread out meetings over the week and especially to have meetings on our Friday mornings (which would be late Friday evening at our remote office). Instead, what worked best for our team was to consolidate meetings to one or two days during the week so that the engineering teams could spend the rest of the week focused on implementation.

3. Lost in Translation
When working with distributed teams, it is even more important to be as clear and concise as possible. If it can take up to a full day to receive responses, it is important that questions and answers are clearly understood to provide the fastest quality turnaround possible.

When summarizing meetings and notes, I try to keep my writing to the basics – eliminate colloquialisms as much as possible and keep to simple and plain English. Not everyone understands the sayings we use in American Business English – even sayings like, “We need to not only talk the talk, but be able to walk the walk” do not always make sense when translated.

4. Visibility into the Process
Scrum has many built-in mechanisms to show progress ranging from verbal communication during daily standups to more formal progress reporting through team burndowns. However, be sure that your stakeholders understand what they’re being shown.

I learned early on that although burndowns are a great way to monitor team progress from an engineering and product standpoint, our business stakeholders were not always as interested in seeing burndowns, and instead were more interested in understanding overall progress. For our business stakeholders, we summarized our teams’ progress into an overall goals burndown to show progress during our release cycle. I kept to regular cadences to get our teams used to updates: weekly summaries for our business stakeholders, bi-weekly status updates from our developers, and reviews of our product roadmap prior to planning every other month. This provided our stakeholders plenty of opportunity to find out what was being developed and give feedback to our Product and Development teams so that the end deliverable met their expectations.

5. Know Your Audience
Your communication style should be catered to your audience. While some appreciate detailed accounts of every meeting and an understanding of every story in progress, a busy executive may not have the time to dig through the minutiae.

Similar to visibility into our process, I quickly realized that I needed to provide notes and status reports specific to my audience. For the most part, I like to try to keep as many details as possible. However, when writing to executives, I will keep an executive summary at the top with any important action items they can contribute to easily viewable in the first few lines. I usually follow up with a more detailed account for those that care for more information. On a weekly basis, I provide a program summary that contains a simple status (red/yellow/green) so that an executive can quickly glance through and pick out the projects that need help.

6. Remember Feedback
Oftentimes, projects are started with much fanfare and expected to continue on its course towards completion without much handholding afterwards. While this can work, it often requires a disciplined team and a very well written specification at the start. In reality, requirements may change, which makes it important to provide points for review and feedback during your implementation.

One key part of Scrum is the sprint demo – a chance for your stakeholders to see your iterative progress over time. When I arrived, I found that sprint demos to stakeholders had stopped due to issues with scheduling (timezone issues) and lack of interest (early on there was little progress to be seen). An unfortunate consequence was finding out near the end of the project that several requirements were not met as expected due to small changes throughout the development cycle. Since then, I have been working to promote sprint demos and provide a way to show them while keeping our stakeholders engaged throughout the implementation.

These are just a few ways we have been able to reinforce a culture of clear communication and visibility within our teams here at Fitbit. I have been able to provide my team with greater clarity using these ideas. There may be challenges ahead that get in the way of having a consistently strategic mindset with all our team members, but having a solid foundation has been a huge step towards conveying those ideas much simpler.

Program management doesn’t end after building this base. There is still plenty more work to get teams to become the high performance teams that you know they can be. Have your teams struggled with communication and visibility? Have you found other tricks that have worked for you?

About the Author

image01Stanton Chan is a Program Manager at Fitbit. He has been using Agile and Scrum for the past 9 years in roles ranging from developer to Scrum Master and has worked with remote teams for the past 7 years including teams in China, India, Mexico, the UK, and Belarus, as well as with distributed teams within the US. When he’s not thinking about ways to make his teams more efficient, Stanton enjoys long runs on local trails to keep fit and active.

1 Comment   Join the Conversation

1 CommentLeave a comment

  • Very useful and spoken like the expert practitioner that Stanton is. I have worked with Stanton and know how he can seamlessly manage complexity like a smooth operator! Way to go, Stan!

If you have questions about a Fitbit tracker, product availability, or the status of your order, contact our Support Team or search the Fitbit Community for answers.

Leave a Reply

Your email address will not be published. Required fields are marked *