Monthly Archives: February 2013

No, You Probably Can’t Work Remotely

Agile sucks when it’s about stuff you don’t like. Just ask the guys at Yahoo.

The good news is that there is no “standard” Agile. It’s best practices around iterative and incremental development. We write books and list out a bunch of stuff, people try them all, and we compare notes. Somethings apply most all of the time, so we keep those. Some apply every now and then, so we keep those too — but keep them in our back pocket. We’re always just interested in what works for us, right now.

The bad news is that a lot of stuff that works most of the time is stuff we might not like. Being an old dinosaur, I was never a fan of TDD. Didn’t care much for fluffy charts on the wall, or playing with crayons and glue again. Did enough of that in kindergarten. This thing where you get together standing up every day seems the height of lunacy. Why not just talk like normal human beings?

It turns out we do a really bad job of trying to figure out ahead of time whether something works or not. Many times when we don’t like something, we just don’t try it. Or we try it a little bit and then give up on it without “getting it”.

Which brings me to the number one thing that we’re finding in Agile that works most of the time but people don’t want to hear about: co-located teams.

Everybody and their brother wants to work remotely, you know, in their pajamas. And it’s slowly turning out that for many types of technology work, distributed teams aren’t going to cut it.

Yahoo is bringing all their remote workers back. Startups have long found that their odds of success are dramatically multiplied when they are physically together. These aren’t just business opinions, these are moves in the marketplace that we’re seeing from groups that succeed.

Big business is still trying to crack the nut of offshoring. Yes, it’s possible, but you always end up either breaking the work up in to such small pieces as to have done it yourself, or training up a bunch of experts in how your company operates who don’t work for you. Either path is problematic.

If you think about it, this makes sense. If you are working without a lot of interaction, it’s either because you have a job that’s minutely-defined or you are an expert in this customer, this domain, and can work with little interaction.

But wait! I can hear you say. We HAVE tools for remote work. Chat, Skype, and so forth. We have TONS of tools!

Here’s where it gets a bit tricky, and remember that I’m only trying to reverse engineer why we’re observing that it doesn’t work. I don’t have all the answers.

Technology development — indeed much of human existence — is a social construct. It’s about people, personalities, relationships, teams, and so forth. The technology and the problem have little to do with anything. “Give me a good team,” the saying goes, “and I can do most anything”

Lots of truth in that.

What we want technology development to be about, however, is moving bits of data around. I have a list of requirements in Excel. We have a project plan on the web. I can chat with you online to explain the way this code works.

Our working theory, mainly because we’re all bit-heads living in the digital age, is that with the correct bits flowing the correct way, things happen. So “friends” on facebook are kinda like friends, but kinda not. Email is kind of like having a conversation, but kinda not. I “know” Joe because we follow each other on Twitter, but not really.

Agile technology development, where you are changing the nature of how you work and the definition of success dynamically, has almost nothing to do with bits of data. So it’s not like having a video conference, or emailing a specification. It’s like making real friends, with real strengths and weaknesses, and learning to use each other’s characters in something greater than the sum of the parts.

There’s not an app for that.

I like Agile when it tells me things I want to hear: project management doesn’t have to be dull, endless meetings, we can work faster the closer we work with the customer, and so forth. I don’t like it so much when it tells me things I don’t want to hear, like in many situations I have to be sitting in a room with the rest of my team instead of in my pajamas.



I saw something a month ago I want to share.

I was observing a team of 8 people from across the hall. I couldn’t hear what was being said but I saw one them stop working and look confused. He looked around the room. Everybody else was busy. So he went to the flipchart and started sketching out his problem for himself. When I looked back a minute later two of them were working around the flipchart, the second guy pointing out things to the first guy.

For many minutes everybody else kept working, many with headphones on. Then one guy got to a stopping point, looked up, and saw the conversation. He gets up and walks over. Now there’s three guys talking and drawing.

They talk for a bit, then there’s four, then five people, all around the flipchart, all working on a solution. The fifth guy was interesting. He stands by the chart for a bit, then realizes the conversation is not for him, so he goes back to his work.

They reach a conclusion and everybody goes back to their seats except the first guy, who stays to make sure he’s captured the results.

This all took place in about ten minutes. No meetings planned, no time waiting around for introductions, no stop in the flow of work, no having to bring somebody else in, no hanging threads, no pre-planned agenda, no figuring out who to invite. Just a bunch of people working together organically, naturally.

An hour later they all went out to lunch together.

I don’t know how you do something like that electronically.



the commenting system is currently down. If you would like to comment, send me an email and I promise to publish your comment unedited

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Agile for Familes

One of the cool things about Agile is how it is a blend of several different disciplines — sociology, applied psychology, sales, marketing, branding, team-building, structured analysis, and so on.

This is also the toughest thing about Agile: it’s not a solid set of principles. It’s best practices around iterative and incremental development. And “best practices” will change over time and in different circumstances. That means that we’re constantly trying out new ideas and seeing what works and in what kinds of situations.

In fact, that’s also the coolest part of Agile. Agile is a community of learning where we’re always trying new things in different situations and reporting on whether they work or not. One set of folks comes up with a big set of best practices, the community tries them out, people publish their lessons, then we all learn.

I thought about that today — the good and bad parts of Agile — as I read about Bruce Feiler’s “The Secrets of Happy Families: Improve Your Mornings, Rethink Family Dinner, Fight Smarter, Go Out and Play, and Much More

Bruce has gone into the Agile community and used some of our best practices to apply to family life. Things like a stand-up, or goal-setting. He’s also done a high-level review of a lot of self-help stuff from all kinds of disciplines.

There are folks who might call such books facile — simplistic, formulaic pablum for people wandering from one self-help book to another.

I think if you view these kinds of books as somehow holding the answers to life, the universe, and everything, you’re probably right. But that’s way too high of a standard.

Life’s a buffet, not a Happy Meal. You get to try new things and see what works for you. Looks like Bruce has done a lot of the legwork in putting various ideas together for you and your family — some from Agile, some from other places. Try some, see what works for you. Perhaps then you can write the version 2.0 of this book; ideas that work most of the time with most families. And that’d be a good thing for the rest of us.


ADD: For those of you who are interested in hearing more about the book, I came across Bruce’s book through this NPR story that a friend shared on G+.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Good Coaching Means Being an Example

In the Agile coaching game, many times we coaches work as close as we can to several teams at one time. We’re there to provide structure, feedback, and a mentored learning environment as teams move to more agility. And of course, like any consultant, we’re paid smart friends. The client’s needs come ahead of our own.

But the goal is for the teams to become more Agile: to work better, faster, and have a happier work life and life balance.

So I was wondering how to handle a question we received a few weeks back. A friend and I were doing some Intro to Agile courses, and during one of the free-form discussions somebody flagged me over.

“So which is it?” he asked, “You told me we were supposed to have the sprint close, retro, and sprint planning all in the same day. This other guy says you split them up.”

He pointed at my friend. He was clearly frustrated.

I looked at my friend. I felt that the advice he was giving was not-so-good, but it was also important not to argue randomly in front of the client. On one hand I felt we were going the wrong way. On the other hand if we were to make the training too chaotic, nobody would get anything out of it.

“Hey, i do it this way,” I said, “and here’s the reasons”

“We’ve always told them this other way,” my friend said.

My friend and I kinda looked at each other. Both of us wondering: are we going to get into a long, boisterous discussion here? Is this the place?

So I looked back to the guy. I said “Look, I still feel my way is better, but it’s not that important thing. I like strawberry ice cream, you like chocolate. Let’s do it the way it’s always been done and see how it goes. We can always adapt later.”

There are a lot of coaches that would have a problem with this. Every little thing they coach is terribly important, and it must be done a certain way.

I’m not one of those people, and more to the point, when we coach we need to be an example. Do we want our teams full of people who either a) disagree all of the time and refuse to back down, or b) are so apathetic they can’t have an opinion on anything?

Of course not. And so we shouldn’t model that behavior. We should have “fierce opinions, lightly held” — be willing to explain and advocate, at length, why we feel a certain way. But never let that get in the way of things moving forward or the spirit of the team. Keep perspective.

I think a lot of time coaches (and the rest of us) get hung up on the details of coaching and forget the purpose of coaching.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.

Weight Loss 1 — The Decision

I’m going to take my blog and keep track of my weight loss journey. I know, I know — it’s not technology, management, or humor, but it’s my blog and I get to do what I want!

:)

As many of you may know, I am a bit overweight. By “a bit”, I mean the doctor said I either had to lose weight or capture an asteroid in my gravity well so I could be declared a planet.

It’s something I’ve struggled with over the years. Tried all kinds of things to help.

After continued failure, I’ve decided to look into bariatric surgery. You know, where the doctor rips your stomach out with a fork. In this fashion, without a stomach, you find it difficult to eat, so you lose weight.

I did a lot of research, and traveled several hours to Northern Virginia yesterday to meet with a doctor. As it turns out, it’s much more complicated than I imagine. They don’t actually use a fork.

Instead, there’s this involved process of tests, double-checks, counseling, and so forth to give this thing the best shot possible. After an initial consult, I was given a list of about a dozen things to do — including an endoscopic examination which requires sedation — just to go to the next step, which is planning for surgery.

There are a lot of pros and cons to having bariatric surgery, and it’s not something I do lightly. One of the guys yesterday asked what my goals for being there were, and I said “To save my life” So, as much as I joke, to me this is a pretty serious situation.

I hope to use this blog to describe my journey.

Share
If you've read this far and you're interested in Agile, you should take my No-frills Agile Tune-up Email Course, and follow me on Twitter.