-
Managing Product Development » What Would a Successful Agile All-Remote Team Look Like?
Aside from sounding like some Agile Awards Team (“And now, your 2009 Agile All-Remote Team!”) Johanna has a good overview of some of the hurdles facing remote teams.
My two most recent perspectives, from today. Earlier, @mhsutton sent out a question over Twitter, asking if anyone uses remote desktop sharing tools to facilitate pair programming. I enthusiastically answered, “YES!”
Two of our DBAs use remote desktop sharing so one of the pair can work remotely a fair portion of the time. They’ve got pair programming down cold, and are a fantastic testament to the advantages of pair programming. It’s a great example of how remote pairing can work, well.
But then, earlier today as we were stressing out about the testing effort we’re undertaking with our outsourced testing team in India (yes, I know. It hurts. Deep, deep hurting) one of that pair exclaimed, “Dammit, it would be so much easier if Mohinder were sitting here, so we could actually see the output of their testing tools!”
So, thinking some more about Johanna’s blog post, I think that one of the things I’ve seen that leads to a successful remote pairing arrangement, and by extension remote teams, is that they need to work co-located for a bit, first.
There’s a natural shorthand that develops between team members. There’s a language of work habits and methods that, when working remotely, you encounter obstacles to developing.
I’m sure that you can develop these habits, only working remotely. It just seems that being co-located, first, allows those habits to develop sooner, and makes working remotely easier, later.
I’m sure there are lots of things I’m forgetting, too. But my brain’s wandering off to how to integrate new team members into a remote team, without bringing the entire team together to indoctrinate the new team member, and that’s a whole other blog post.
-
Column info : No: Such a Difficult Word
Whew, this hits really close to home.
I struggle with this all the time. Part of what makes the good people good, and a huge part of the reason I got into Agile at all, was because I enjoy helping. I enjoy making things better. I still - for better or worse, and increasingly for worse - define my success in terms of my value to others, be they my organization or my team, my friends, my girls, the people I care about.
When those people ask, my natural reaction is to say, “Of course! How can I help?” I don’t think of consequences or missed commitments down the road, and I surely don’t think of the negative impacts saying “yes” have on my mental and sometimes my physical health.
We spend so much time trying to figure out how to say “No”, how to build up the trust of our peers, our managers, our friends and family, so that when we do say “No”, it’s not questioned.
We spend so much time putting together process and procedures, self-help books and organization systems, all designed around the idea of quantifying our workload and preventing our well-meaning selves from over-committing, and consequently, failing.
The other day, it hit me: that’s Kanban. It’s another tool for people to use to help them manage their own intake. Whether it’s because they can’t muster up the strength to say “No”, because their opinions aren’t trusted (maybe because they’ve said “Yes” too often, and failed?) or because their inputs just don’t know how to work toward a common good - in all those cases, Kanban is Yet Another System to manage intake.
It’s “No”, with Big Obvious Charts.
Sometimes, when you say “No” every other way and you’re not heard, Big Obvious Charts might just do the trick.
