9 Success Factors for Working with Remote Teams

Share
Reading time ~6 minutes

Some management archaeology from me this morning…

A photo of a sundial overlooking the sea and a coastal area

When I started managing teams and projects for the first time I used to write down my most significant insights and lessons I’d learned in a little Black & Red A5 notebook.

A couple of months ago I pulled it off of the shelf and thumbed through my old notes. They’re almost all still as relevant today as they were over a decade ago.

Hiding among the notes on capacity planning, estimation, reporting, change management, innovation, reward systems, performance management, situational leadership and even a list of personal “observed best practices” was a single half-page of bullet points that simply read:

“How to ensure offshore teams are successful”

Since not long after I started writing publicly I’ve not needed to use those insights.

I have the rare luxury of working with completely co-located teams (even “the business” sits with the team here). However I know many of you wonderful readers still face challenges with offshore or near-shore collaboration & quality. As Dan noted in the comments below, these apply to any globally diverse team, not just “offshore”.

So that these insights aren’t lost to time, I thought I’d share and expand them here.I’m bound to have missed many others and this is my personal view from being UK-based and working with teams all around the world so I have 2 requests for you as readers…

  • What tips and suggestions would you add to this list?
  • If you’re based in an “offshore” type team, please, please, please share your insights from the “other side” – we don’t hear enough here.

1 – Management & Team Mindset

First – stop thinking “offshore”. You’re a global team. Once you start treating your remote staff/suppliers/contractors as being “on your team” relationships start to build.

Pair team members and managers across locations. You’re working on the same goals, behave like it.

Manage all your team in the same way. Arrange 1-1s, feedback sessions, informal catch-ups, full team training. Have off-sites or outings for every site and share the pictures. Better still, do it together.

Your team includes your customers and suppliers too – involve them in your challenges and be rewarded.

2 – Shared Accountability

We often outsource to reduce effort, overhead, cost and risk. As soon as these become significant motivations, you’re already behaving in a flawed way. You’ll find your offshoring or oursourcing isn’t actively owned or managed.

You own the working relationship. It’s up to you to make it work. Find a counterpart on the other side to pair up with and make it successful.

A remote team will never be successful if your only reason for using them is cost. Figure out the unique strengths, talents and value they bring to you. Invest in partners and locations where you have better access to specialist domain knowledge, broader experience or better delivery capabilities.

A great example of this lies in the domain of one of my former employers – power systems. Power systems engineers are rare people at the best of times. In the US in particular, much of the power systems & networks domain knowledge is being lost through retirement. China on the other hand has a huge number of extraordinarily smart engineers in this space.

3 – Quality of Team

Perhaps it’s purely a capacity thing – staff availability in your home location may be a problem.

It’s a lot harder to hire a dozen amazing developers in Cambridge than it is in San Francisco or Mumbai. But given the size of the talent pool in those locations, it’s also a lot easier to hire mediocre or bad team members. Your bar should be set high wherever you are.

Expect the same from your partners or suppliers. If your supplier is competing on cost alone and not capability you’ll eventually fail – period.

4 – Selection Of Work

Don’t just farm out the dull stuff, the maintenance, support, and bug fixing. This is something very few people enjoy taking personal ownership of or pride in. I’ll admit there are exceptions (I love clearing down a massive bug backlog) but most technical people need a balance. All brown-field work wears people down eventually.

5 – Political Structures & Power Dynamics

Career paths and job titles are important.  The “senior” in someone’s title may even be seen as acceptance to push others around or exclude team members from important conversations.

Halt “pecking order” problems early.

Be inclusive, publicly encourage collaboration, and transparent communication from senior managers and give direct private feedback when you smell a problem.

6 – Management Style

Some countries and companies have a more top-down formal style than others. It may be unacceptable to “question your superiors” despite the fact that nobody can be right 100% of the time.

Learn about how things run. Who’s respected, who’s feared, who helps things happen and who gets in the way.

Encourage questioning. Explain that everyone is making rapid decisions all the time. If someone doesn’t understand, is worried or unsure about a decision, make it safe to call out, ask or correct. This capability may take months to build but it’s worth the slog.

As a tech lead in one company I worked at I used to run a game called “Captain, you’re wrong”. We made calling out errors fun and engaging rather than difficult and negative.

Recognise that career paths, job titles and management styles differ from country to country.

7 – Respect cultural and language differences

I had mentee that would say “I have a doubt” when they had a question or needed support. That’s quite an interesting translation. “Doubt” in English reflects personal uncertainty. Be supportive, take time to explain things clearly and most of all encourage questions and discussion.

Work ethic may varies from place to place and person to person but sometimes you just don’t see what’s going on.

I had a team member in Hyderabad who consistently outperformed everyone else globally. She was truly amazing at everything but more than that she worked relentlessly.

I’d come into work in the morning at 8 and she’d have been in the office for 4 hours. I’d leave at 6 or 7 in the evening and she’d still be working. The irony was that even when working sensible hours she was still smarter, more productive and delivered higher quality output than a lot of our team. The excess hours weren’t healthy.

Having spotted the excess working I’d check daily around 4/5 pm and if she was still Online I’d call her up and just and encourage her to go home and enjoy her evening. (Her home life was great too so I’m pretty sure she wasn’t avoiding going home).

8 – Spend Time Together

Seek ways to bring your whole team together for a day, a week, a month or even longer. If this really isn’t possible, how can you do the same for individuals and managers instead?

Spending time together helps you understand the working environment, the personal subtleties and nuances and communication styles. After you’ve spent quality time face to face with someone, those offline interactions become much easier to understand.

It works both ways. Spend some time (at least a couple of weeks) in the remote environment yourself. Go see what working life’s like over there. I promise you’ll learn something every day you’re out there.

9 – Re-learn how to communicate

A lot of communication on a co-located team happens by osmosis.

If some of your team are remote they won’t get that benefit. Invest in tools like slack and github that support asynchronous collaboration but don’t just use them for “work” – dial up the chatter and small talk so that everyone can feel part of a human team.

 

Dark for the last few months?

Share
Reading time ~3 minutes

photo looking up a medieval chimney

There’s some bright lights ahead…

Over the last year I’ve changed roles (twice – but still in the same company) so things have been pretty quiet on here as I cram a mountain of new information, ideas, thoughts and challenges into my brain and try to make sense of it in ways that are insightful or useful to anyone that reads these posts.

I picked up and then put down development of my text adventure after a few months – I learned more than enough to meet my stated goals when I started but re-discovered how addictive coding something you really care about can be. I got to the point where I was head-down coding 6+ hours a day on top of a full time job. This was stealing time away from learning more important and valuable (but probably less fun) things for me and not leaving me enough head space for much else. (It was also mentally exhausting doing both)

As some context, Last Spring I moved on from my Head of Project Management role here to work with our Sales Operations team for a couple of months. This was a combination of me wanting to get my head back into the commercial side of the software business and a pull from the team to have some support and a tune-up around their capacity, flow of work and goals.

I’ll write a short post on this as it was useful for both me and the team but in a nutshell it was just under 3 months of applying lean, agile & theory of constraints principles to an ops team and setting them up for future success.

Since the Summer I’ve had a new long-term challenge. It’s a far cry from leading agile teams but still uses my broader industry skills & experience.

I’m now heading up Product Design here.

So far I’m loving the move. It’s full of new challenges. I’ve picked up support for our Technical Communications, User Experience and Product Management communities, bootstrapped a major product design initiative and (as always) I’m interviewing like crazy for new recruits for all these roles.

I’m now working directly for our CTO as part of a team of 6 amazingly talented people covering our innovation, strategy, engineering and product design capabilities. We’ve a load of work to cover and our roles intersect enough that we can collaborate on some bigger things affecting the way we operate.

At the moment we’re in the middle of rebooting our communities of practice, a portfolio-wide strategic review, a push toward design-led product thinking, building a strong learning and development foundation for our product organization and significant market and innovation research.

After feeling that much of the new focus in agile (around scaling) was in contexts that no longer applied to me, it’s good to be back into researching and studying in depth around strategy, design and innovation and finally feeling these ideas all coming together. I’m thoroughly enjoying the break from running software teams directly and working hard on my influencing, sharing and leading again.

So… Time & motivation-permitting I’ll start posting a few new lessons and experiences over the coming weeks and months. They’ll still have relevance to agile and software but will be much more focused on the business end of things; product design, strategy, recruitment, organizational capabilities and innovation.

Thanks for sticking with me this far.

S

 

Shy? Try Exercising Your Asking Muscles

Share
Reading time ~4 minutes

Some Friday morning amateur social philosophy.

One of my current team is as shy as I am. We both agree that “we’d rather not deal with people”. It’s somewhat funny that even from the first day of my degree I had to work in teams and interact with external stakeholders. My ability to do so is my strength (but my dirty secret is that it’s also my biggest fear).

I’ve read and re-read loads of stuff on being an introvert, on being shy and assorted other musings for the “socially challenged”. I’m not socially awkward – I might be a bit of an over-sharer but once I’m up and running I can be the life and soul of the corner of the kitchen at a party, I enjoy sharing, I enjoy interacting with people but I’m like a dynamo – I need some winding up to reach that state.

I think my favorite term comes from Doc List who describes himself as an “Ambivert”. I think his observations closely define me as well.

Most people that I interact with in public or at work would never believe I’m shy. It’s one of the joys of the agile/conference scene – you know most people are just like you. They wear a mantle of bravery and a mask of confidence but after a week of conferences will happily spend the weekend recovering under the covers. Over the years those people become friends and the interactions become easier.

I gain short-term energy from talking to people but I’m exhausted afterwards. I find nothing more draining than leading planning sessions, demos and retrospectives but most people will never see it. In some camps that counts as introverted, in others extroverted – Let’s stick with ambivert.

Anyway. A challenge with being shy/introverted or even an ambivert is asking. Asking for help, information or even asking someone to do something you know is their responsibility or even pleasure to do for you.

As a project manager or leader this is a bit of a crazy situation. Every day I need to ask my team or external stakeholders for an assortment of things. The emotional effort needed to ask can vary from easy to terrifying and descends into experiences that are often addressed with Cognitive Behavior Therapy.

  • You believe it’s unreasonable to ask busy people for more of their time to meet needs you think are yours.
  • You feel (or have been told) you should ask someone for help or input.
  • You’re trying to make a difference, you know other people care but you don’t know how to approach the subject.
  • The list of doubts, “Shoulds” and “aughts” goes on.

From my experiences I’ve discovered the ability to ask is like any other mental muscle. If you use it regularly it gets better. If you don’t use it it wastes away. 

Unfortunately that shy moment freezes you up. It means you’re more inclined to not ask until it’s critical so you end up making life harder for yourself and the person you need to ask. All the while you’re procrastinating you’re expending mental cycles on stress and doing nothing.

But there’s more to it than that.

Each person you need to ask something of is a different muscle.

When I first started working as a PM in our DevOps group a few years ago I was new to the company, I had few existing working relationships and a number of key stakeholders I needed to learn to interact with.

How did I build up my asking muscles?

I reviewed my working relationships in the past to understand what I found easy and what was more difficult.  I found – even with my own team – that after about 3 useful interactions in a short period of time things became significantly easier so I decided to try an experiment.

There’s a neat idea in software development known as the “rule of three” – once you’ve needed to use the same thing 3 times then it’s probably time to make it generic and standardize it.

I bought a small (A3) sized whiteboard and placed it on my desk. On the board I drew a grid. Each horizontal lane represented a person I needed to learn to interact with. I wrote each name in the left-hand column. Each column after that was a placeholder where I’d mark an X every time I had an asking or collaborative interaction with that person. My goal was to get 3 X’s in each row over the space of about a month.

It worked – when there were only one or two X’s I’d figure out how I could build another interaction with that person that didn’t have to involve asking for anything significant.

One of those people came over to my desk and spotted my board – they asked what the “X’s” next to their name were. I explained and they immediately empathized. I wasn’t alone. That conversation counted as yet another X – It became easier to ask!

The tricky thing is once you’ve built those muscles up you need to kep them running.

If you neglect your asking skills for any time you need to rebuild them again (sometimes the second time is easier). If like me your projects and roles change a lot over the years you’ll probably find that by the time you’ve just got comfortable with everyone you need to ask that the world changes around you and you need to start again.

This is a good thing – it keeps us exercising our asking muscles.

Who do you want to ask something of today?

Go talk to them.

Have a great weekend

Simon

The Pitfalls of Measuring “Agility”

Share
Reading time ~7 minutes

This post expands on one of the experiences I mentioned in “Rapunzel’s Ivory Tower“.

I presented these lessons and the story at Agile Cambridge back in 2010.  It’s taken nearly 5 years to see the light of day in writing on here. I hope it’s not too late to make a difference.

I and my team hadn’t been in our roles long. We’d been given a challenge. Our executives wanted to know “which teams are agile and which aren’t” (see the Rapunzel post for more). We managed to re-educate them and gain acceptance of a more detailed measurement approach (they we were all Six Sigma certified – these people loved measurement) and I’d been furiously pulling the pieces together so that when we had the time to work face to face we could walk away with something production ready.

Verging on quitting my job I asked James Lewis from Thoughtworks for a pint at The Old Spring. I was building a measurement system that was asking the right questions but there was no way I could see a path through it that would prevent it being used to penalize and criticise hard-working teams. This was a vital assessment for the company. It defined clearly the roadmap we’d set out, took a baseline measure of where we were and allowed us and teams to determine where to focus.

My greatest frustration was that many of the areas teams would score badly were beyond their immediate control – yet I knew senior management would have little time to review anything but the numbers.

James’ question he left me with was:

“How do you make it safe for teams to send a ‘help’ message to management instead?”

I returned to my desk fuelled by a fresh pair of eyes and a pint of cider. I had it!

At the time many agility assessments had two major flaws.

1 – they only have a positive scale – they’re masking binary answers making them look qualitative but they’re not.

2 – They assume they’re right – authoritative, “we wrote the assessment, we know the right answers better than you…”

  • What if the scale went up to 11 (metaphorically) How could teams beat the (measurement) system.
  • And what if 0 wasn’t the lowest you could score. What would that mean?

The assessment was built using a combination of a simpler and smaller agility assessment provided to us by Rally plus the “Scrum Checklist” developed by Henrik Kniberg, the “Nokia Test“, the XP “rules” and my own specific experiences around lightweight design that weren’t captured by any of these. As we learned more, so we adapted the assessment to bake in our new knowledge.  This was 2009/2010, the agile field was moving really fast and we were adding new ideas weekly.

The results were inspired – a 220 question survey covering everything we knew. Radar charts, organizational heat maps, the works.

The final version of the assessment (version 27!) covered 12 categories with an average of about 18 questions to score in each category:

  1. Shared responsibility & accountability
  2. Requirements
  3. Collaboration & communication
  4. Planning, estimation & tracking
  5. Governance & Assurance
  6. Scrum Master
  7. Product Owner
  8. Build and Configuration Management
  9. Testing
  10. Use of tools (in particular Rally)
  11. Stakeholder trust, delivery & commitment
  12. Design

The most valuable part was the scale:

  • -3 We have Major systemic and/or organizational impediments preventing this (beyond the team’s control)
  • -2 We have impediments that require significant effort/resource/time to address before this will be possible (the team needs support to address)
  • -1 We have minor/moderate impediments that we need to resolve before this is possible (within the team’s control)
  • 0 We don’t consider or do this / this doesn’t happen (either deliberate or not)
  • 1 We sometimes achieve this
  • 2 We usually achieve this
  • 3 We always achieve this (*always*)
  • 4 We have a better alternative (provide details in comments)

a radar chart from excel showing each category from the assessment

The assessment was designed as a half-day shared learning experience. For any score less than 3 or 4, we would consider & discuss what should be done and when, what were the priorities, where did the team need support, what could teams drive themselves and what were the impediments. Teams could also highlight any items they disagreed with that should be explored.

Actions were classified as:

  • Important but requires management support / organizational change to achieve
  • Useful, low effort required but requires more change support than low hanging fruit
  • Potential “low hanging fruit”, easy wins, usually a change in practice or communication
  • Important but requires significant sustained effort and support to improve

As a coaching team we completed one entire round of assessments across 14 sites around the globe and many teams then continued to self-assess after the baseline activity.

Our executive team actually did get what they needed – a really clear view on the state of their worldwide agile transformation. It wasn’t what they’d originally asked for but through the journey we’d been able to educate then about the non-binary nature of “being agile”

But the cost, the delays, the iterative approach to developing the assessment, the cultural differences and the sheer scale of work involved weren’t sustainable. An assessment took anything from an hour to two days! We discovered that every question we asked was like a mini lesson in one more subtle aspect of agile.  Fortunately they got quicker after the teams had been through them once.

By the time we’d finished we’d started to see and learn more about the value in Kanban approaches and were applying our prior Lean experience and training rather than simply Scrum & XP + Culture. We’d have to face restructuring the assessment to accommodate even more new knowledge and realized this would never end. Surely that couldn’t be right.

Amongst the lessons from the assessments themselves, the cultural differences were probably my favourite.

  • Teams in the US took the assessment at face-value and good faith and gave an accurate representation of the state of play (I was expecting signs of the “hero” culture to come through but they didn’t materialize).
  • The teams in India were consistently getting higher marks without supporting evidence or outcomes.
  • Teams in England were cynical about the entire thing (the 2-day session was one of the first in England. Every question was turned into a debate).
  • The teams in Scotland consistently marked themselves badly on everything despite being some of our most experienced teams.

In hindsight this is probably a reflection on the level of actual knowledge & experience of each site.

Partway through the baseline assessments after a great conversation with one of the BA team in Cambridge (who sadly for us has since retired) we added another category – “trust”. His point was all the practices in the world were meaningless without mutual trust, reliability and respect.

It seemed obvious to us but for one particular site there was so much toxic politics between the business leadership and development that nobody could safely tackle that he had an entirely valid point. I can’t remember if we were ever brave enough to publish the trust results – somewhat telling perhaps? (Although the root cause “left to pursue other opportunities” in a political power struggle not long before I left).

Despite all this the baselining activities worked and we identified a common issue on almost all teams. Business engagement.

We were implementing Scrum & XP within a stage-gate process. Historically the gate at which work was handed over from the business to development was a one-way trip. Product managers would complete their requirements and them move on to market-facing activities and leave the team to deliver. If a team failed to deliver all their requirements it was historically “development’s fault” that the business’ numbers fell short. We were breaking down that wall and the increased accountability and interaction was loved by some and loathed by others.

We shifted our focus to the team/business relationship and eventually stopped doing the major assessments. We replaced them with a 10 question per-sprint stakeholder survey where every team member could anonymously provide input and the product managers view could be overlaid on a graph. This was simpler, focused and much more locally & immediately actionable. It highlighted disconnects in views and enabled collaborative resolution.

Here’s the 10 question survey.

Using a scale of -5 to +5 indicate how strongly you agree or disagree with each of the following statements  (where -5 is strongly disagree, 0 is neutral and +5 is strongly agree)

Sprint

  • The iteration had clear agreement on what would be delivered
  • The iteration delivered what was agreed
  • Accepted stories met the agreed definition of done
  • What was delivered is usable by the customer
  • I am proud of what was delivered

Release

  • I am confident that the project will successfully meet the release commitments
  • Technical debt is being kept to a minimum or is being reduced

General

  • Impediments that cannot be resolved by the team alone are addressed promptly
  • The team and product manager are working well together

If you’re ever inclined to do an “agile assessment” of any type, get a really good understanding of what questions you’re trying to answer and what problems you’re trying to solve. Try to avoid methodology bias, keep it simple and focused and make sure it’s serving the right people in the right ways.

Oh – if you’re after a copy of the assessment, I’m afraid it’s one of the few things I can’t share. Those that attended the Agile Cambridge workshop have a paper copy (and this was approved by the company I was at at the time) but I don’t have the rights to share the full assessment now I’m no longer there. I also feel quite strongly that this type of assessment can be used for bad things – it’s a dangerous tool in the wrong circumstances.

Thanks – as always – for reading.

Seeing the Value in Task Estimates

Share
Reading time ~5 minutes

a list of task estimate sizes with beta curves overlaidYou might be aware of the ongoing discussions around the #noEstimates movement right now. I have the luxury here of rarely needing to use estimates as commitments to management but I usually (not always) still ask my teams to estimate their tasks.

My consistently positive experiences so far mean I’m unlikely to stop any time soon.

3 weeks ago I joined a new team. I decided I wanted to get back into the commercial side of the business for a while so I’ve joined our Sales Operations team. (Think DevOps but for sales admin, systems, reporting, targeting & metrics).

Fortunately for me the current manager of the team who took the role on a month or so earlier is amazing. She has so much sales domain knowledge, an instinct for what’s going on and deeply understands what’s needed by our customers (the sales teams).

I’d been working with her informally for a while getting her up to speed on agile project management so by the time I joined the team already had a basic whiteboard in place, were having effective daily standups and were tracking tasks.

The big problem with an ops team is balancing strategic and tactical work. Right now the work is all tactical, urgent items come in daily at the cost of important but less urgent work.

We’re also facing capacity issues with the team and much of the work is all flowing to a single domain expert who’s due to go on leave for a few months this Summer – again a common problem in ops teams.

I observed the movement of tasks on the team board for a week to understand how things were running, spot what was flowing well and what was blocked. As I observed I noted challenges being faced and possible improvements to make. By the end of the week I started implementing a series of near-daily changes – My approach was very similar to that taken in “a year of whiteboard evolution“.

Since the start of April we’ve made 17 “tweaks” to the way the team works and have a backlog of nearly 30 more.

Last week we started adding estimates to tasks.

I trained the team on task estimation – it took less than 10 minutes to explain after one of our standups. The technical details on how I teach this are in my post on story points. But there’s more than just the technical aspect. (In fact the technicalities are secondary to be honest)

Here’s the human side of task estimation…

  • Tasks are estimated in what I describe as “day fragments” – essentially an effort hours equivalent of story points. These are periods of time “small enough to fit in your head”.
  • The distribution scale for task estimates I recommend is always the same. 0.5, 1, 2, 4, 8, 16, 24 hours. (the last 3 are 1, 2 and 3 days) – It’s rare to see a task with a “24” on it. This offers the same kind of declining precision we see with Fibonacci-based story point estimates.
  • For the level of accuracy & precision we’re after I recommend spending less than 30 seconds to provide an estimate for any task. (Usually more like 5-10)
  • If you can’t provide an estimate then you’re missing a task somewhere on understanding what’s needed.
  • Any task of size 8 or more is probably more than one task.
  • Simply having an estimate on a task makes it easier to start work on – especially if the estimate is small (this is one of the tactics in the Cracking Big Rocks card deck)
  • By having an estimate, you have a better idea of when you’ll be done based on other commitments and activities, this means you can manage expectations better.
  • The estimates don’t need to be accurate but the more often you estimate, the better you get at it.
  • When a task is “done”, we re-check the estimate but we only change the number if the result is wildly off. E.g. if a 1 day task takes just an hour or vice versa. And we only do this to learn, understand and improve, not to worry or blame.

So why is this worth doing?

Within a day we were already seeing improvements to our flow of work and after a week we had results to show for it.

  • The majority of tasks fell into the 0.5 or 1 hour buckets – a sign of lots of reactive small items.
  • Tasks with estimates of 8 hours or more (1 day’s effort) were consistently “stuck”.
  • We spotted many small tasks jumping the queue ahead of larger more important items despite not being urgent. (Because they were easier to deliver and well-understood)
  • Vague tasks that had been hanging around for weeks were pulled off of the board and replaced with a series more concrete smaller actions. (I didn’t even have to do any prompting)
  • Tasks that still couldn’t be estimated spawned 0.5 or 1 hour tasks to figure out what needed to be done.
  • Large blocked items started moving again.
  • Team members were more confident in what could be achieved and when.
  • We can start capacity planning and gathering data for defining service level agreements and planning more strategic work.

I’m not saying you have to estimate tasks but I strongly believe in the benefits they provide internally to a team.

If you’re not doing so already, try a little simple education with your teams and then run an experiment for a while. You can always stop if it’s not working for you.

 

 

A quick update – Janne Sinivirta pointed out that “none of the benefits seem to be from estimates, rather about task breakdown and understanding the tasks.”

He’s got a good point. This is a key thing for me about task estimation. It highlights quickly what you do & don’t understand. The value is at least partially in estimating, not estimates. (Much like the act of planning vs following a plan). Although by adding the estimates to tasks on the wall we could quickly see patterns in flow of tasks that were less clear before and act sooner.

As we move from tactical to strategic work I expect we’ll still need those numbers to help inform how much of our time we need to spend on reactive work. (In most teams I’ve worked in it’s historically about 20% but it’s looking like much more than that here so far).

Martin Burns also highlighted that understanding and breaking down tasks is where much of the work lies. The equivalent of that in this team is in recognising what needs investigation and discussion with users and what doesn’t and adding tasks for those items.