Are you a manager accustomed to Management by Walking Around and Listening (MBWAL)? You can use MBWAL with collocated teams. MBWAL doesn’t work for distributed or dispersed teams.
Remember, working remote is Not Business as Usual. (And won’t be for a while.)
And, you might still have this question: “If no one’s in the office, how will I know what they’re doing?” You might be surprised—you didn’t know what they did when you were all in the office.
In my experience, if you don’t offer people autonomy for their work, they will game the system. You might have been under the illusion you knew what they did. You knew part of what people did—not all of it.
You have an opportunity to work differently as a manager. If you haven’t tried this before, you might feel nervous and not ready to cope with these changes. I do recommend you start by asking for help.
Consider asking for help with each of these:
- Focus on team collaboration
- Visible progress
- Reduce the team’s WIP (Work in Progress)
- Substitute video for MBWAL
The fifth tip is about not micromanaging from afar. You might need help with that, too.
Let’s start with team collaboration.
Tip 1: Support Team-Based Work, Not Individual Work
You might think that dispersed/remote work is all individual. Nope. If you’re creating products of any kind—especially software products—you’ve got a team sport.
Successful software product development is about how well the team learns together. The better the team learns together, the better the product is. If you want faster releases, teams that work together can deliver faster. (See the Flow Efficiency series.) And, if you want to make small changes fast, the team will need to consider its technical excellence. (See Product Orientation Requires Technical Excellence).
As a manager, you can ask teams to collaborate. When teams collaborate and focus on creating running tested features that work, the teams make real and fast progress.
And, you can ask the people if anything prevents their collaboration. You might be able to fix those problems.
Tip 2: Make All Progress Visible
Your customers only care about running, tested features. Your customers also might care about defects that remain in the product.
As a manager, while you might have a bunch of metrics, most of those measures don’t help you manage. ( See Agile Program Measurements to Visualize and Track Progress and Measure Cycle Time for my suggestions of what to measure. I have more ideas and a more in-depth discussion in Create Your Successful Agile Project.)
What running, tested features can your team show you today?
If your team is still learning how to work as a team, consider the ideas in Visible Progress. Here are some examples:
- Demos, even of partially working product.
- Interim designs and decisions made from those designs. (I expect to see some kind of running code. It might not be a customer-worthy demo, but it’s a demo of a sort.)
- Results of performance experiments.
All of these reflect various kinds of progress.
Here’s what’s not progress:
- Cards on a board. What the card represents is progress. Don’t look at cards; look at the outcome the card represents.
- Any of these individual metrics: number of lines of code, number of tests, hours spent in coding, testing, or reviewing.
You don’t need too many metrics if you can see visible progress. You might ask the team to suggest what they would like to show you for progress.
Tip 3: Reduce the Team’s WIP
Most teams I work with have a huge problem: way too much WIP (work in progress). (See Three Collaboration Secrets to Create Your Agile Culture.) You can help the team by working with the people who give the team requirements. You can clarify the organization’s priorities.
The world is different and will remain so for a while. I have no idea what “normal” will be or when that normal will arrive.
In the meantime, you can help your team when you facilitate conversations about “how little” thinking. (Don’t decide for anyone. Facilitate their conversations.)
And, ask the team and the product people what you can do to help reduce the team’s WIP.
Tip 4: Substitute Video for MBWAL
Back when I first started to manage distributed teams back in the 80s, we didn’t have cameras the way we do today. I had the phone.
I literally had no insight—no vision—into how people worked.
We don’t have that problem now. Every laptop has a camera. We also have tablets and phones with cameras. We have pervasive vision—if we choose to use it.
Turn your camera on. (Work in public if you want to see what people are doing.) Work with people in a tool that has video. Then, request that the other person turn their camera on.
Everyone needs to see each person’s context, and the camera will show us each other’s context.
Is a camera a substitute for MBWAL? Not totally. However, if you also add a check-in, you might be able to gain insight. And, you can ask people to tell you what’s going on for them.
Tip 5: Resist the Urge to Micromanage
I’ve heard about organizations with managers who want to know what their remote people do every minute. So, they install spyware on everyone’s computers.
Don’t do that. It’s the worst kind of micromanagement. Worse, it doesn’t tell you anything. Here are some reasons people might not use their computers:
- Your infrastructure doesn’t support what people need, so they’re using their phones to collaborate, not their computers. Or, they’re using a different app, not one you approved, for their collaboration.
- They’re reading/reviewing the product and thinking. You can’t see people think.
- They might use a sandbox you’re not monitoring to experiment. Especially if the infrastructure you provided isn’t sufficient.
Never mind managing the pulls of other people in the house.
One manager told me he needed daily one-on-ones. I asked him if he could really afford the time with everyone and still do his work.
He sighed and said he didn’t have the time.
I told him to return to his weekly or biweekly one-on-ones and instead ask for asynchronous information about obstacles he could remove. And, to focus on his work, which was more strategic.
Managing Dispersed Teams Requires Different Tactics
As you manage your now-dispersed team, think of how you can support them in finishing small deliverables. What can you do for the team, not the individuals? Change your tactics for better remote results.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Five Tips for Managers of Newly Dispersed Teams Opinions expressed by Java Code Geeks contributors are their own. |
Thanks for explaining the things. There are many-things which clears my doubt .
You’re welcome.