My friend, Elinor Slomba, and I will be on a panel titled: Cultural Self-Inventory for Distributed Agile Teams over at Sococo. We’re going to be talking about distributed teams, prioritizing people and their needs over tools and processes, and how being in a distributed team does align with the principles of the Agile Manifesto.

Elinor gave a presentation a short while ago and wrote this wonderful accompanying blog post addressing how the 12 principles of the Agile Manifesto can support distributed teams – its about how you go about doing it. My favorite excerpt from her post:

Keynote Craig Larman had reviewed with us his fourth “law of organizational behavior:” Culture Follows Structure. If this is indeed the case, and Larman points to evidence gathered by another thought leader to suggest that it does, then choices made about how to support the structure of distributed Agile teams represent a unique opportunity.

Might it not be possible, in fact, to work backward, selecting structures which prioritize individuals and their interactions over tools and processes?  Can distributed configurations be set up primarily to address a team’s social needs in line with Agile cultural values?

–Elinor Slomba, Distributed Culture Self-Inventory

I wholeheartedly agree! How people interact offline and online should be consistent, and you use appropriate tools to enable that. Distributed teams work a little differently, but they are still based on relationships, trust, and clear and consistent communication.

Distributed teams and Agile can go together like chocolate and peanut butter – we’ll be talking more about that on Tuesday.

Thanks, Elinor, for including me in this event. I’m so excited!!

Readers – I hope you can make it on Tuesday at 11am PT/2pm ET!

Before I forget: I’m guest blogging on her site – the first piece explores Agile Principle #1 (Our highest priority is to satisfy the customer
 through early and continuous delivery
of valuable software.) for distributed/virtual teams and soon in the future, I’ll be writing about Agile Principle #5 (Build projects around motivated individuals.).

After working on Principle #1, I know way too much about the term “valuable software!” 

There was a neighborhood street with 5 boulders in it of varying sizes and a lot of sand. The residents couldn't drive down the street in their cars or bikes. The sand was too deep and prevented a bike from working properly on it; cars were too large to maneuver around the boulders. 

The residents had to walk around on the grass; there was so much sand that the street was like a beach. And that sand started coming into their lawns. It was just a mess.

The residents had a meeting to do something about this problem. And they came to 2 solutions:

1. Sweep the street so they could ride their bikes on it and park their cars on the neighboring streets. At least with this plan they could get to their cars!
2. Remove the boulders that they could do on their own for now, then sweep. They would then collect money to remove the boulders that were too big – hire a crane and removal team. Then the street would be clear and they wouldn't need to keep sweeping the street; wind and rain would take care of the sand.

The second solution seemed to require too much commitment, so they decided to go with option 1. All of the residents had to do their part and sweep the street every day, but new sand seemed to come from everywhere. And there was always sand under the boulders. It was like the boulders created sand!

The work never seemed to end.

After a couple of weeks, option 2 seemed to make more sense. With a little team work, they removed the boulders they could, took turns sweeping away the sand, and generally most of the sand was gone and didn't return. There were two boulders left on the street, but they could maneuver their cars around them to park in their garages and driveways rather than their neighbors' homes (some were relatives of Homer Simpson).

It was suddenly easy to ride a bike and walk in the street. 

They then collected funds each month to move the boulders. While doing this, they learned that the town they lived in had a program to remove boulders from streets – and they qualified for funding.

They removed the final two boulders and didn't have to worry about street maintenance again.

In some ways, this is the same story could be used for your app or site. Boulders are usability issues – and some of us work on apps that have massive ones. A cranky database that delivers data after a few minutes rather than seconds. A horrible navigation approach that makes maneuvering around the site impossible. The sand represents the little things that are just not quite right – colors, fonts, buttons. Sure, those things make navigating the app painful and difficult, but cleaning that up won't fix the boulder problem. If anything, you may find additional small issues.

(Making you feel like the sand won't go away.)

You need to remove the boulders – fix the big things to remove the sand. If you remove the big app challenges, the little things may go away on their own with those repairs. When you redo the navigation, you may update that part of the style sheet and make the navigation look better. Or while fixing the error messaging, you may be updating the forms and reduce usability issues on that page by 90% (no more sand!). Fix the database and you may decide to fix the front-end display to make it easier to scan.

In the meantime, you may find money for the larger issues from other groups or the corporate team (the town and beyond). There may be a larger organizational initiative that could fund your project. Or if people see how your app is more successful with some of the larger "boulders" remove, you may get more money to generate even better results. 

To sum it up: To clean the street, remove the boulders and stop sweeping the sand.