Mending Walls

Scrum is focused on teams. But who’s on the team? And how can others help?

Not too long ago, a manager told me, “It’s seems like you’re saying that Scrum separates me from my team. That doesn’t feel right, because I’ve worked hard to create an open atmosphere here.” And he had a point: the language we often use when talking about Scrum teams includes “protecting” the team, focusing on the people who have “hands on the keyboard.” We think we need to separate the Scrum team from their partners in the organization.

Before I built a wall I’d ask to know
What I was walling in or walling out,
And to whom I was like to give offence.
– Robert Frost, “Mending Wall

That conversation reminded me of a time, years ago, when I was working with a team whose managers had asked me to help them learn how to deliver using Scrum. These folks worked in what some technology professionals might see as an extremely stable company; many people had been at the company for double-digit numbers of years. They worked together, celebrated together, knew each other’s families and kids. They knew a lot about being together before I ever came into their lives.

When it came to the time when we were forming the Scrum team – choosing who’d work on which team, who’d serve as ScrumMaster, and so on – we got a bit stuck. “I think I should definitely be on the team,” said Richard, who was the manager of most of the developers and testers who’d be working together. “I need to see what the team is doing.” Others piped up, remembering what we’d learned about cross-functional delivery teams, and offered that Richard didn’t have a delivery role; he was a manager.

The brand-new ScrumMaster, Amy, suddenly brightened. “Richard,” she said, what if you were a ‘team friend’? We’re going to have lots of challenges as we learn to work using this Scrum thing, and we’ll need all the help we can get. And friends are important: they care about you, they’ll listen, offer advice…they’ll pitch in and help you out when you’re in a tough spot. Sometimes, they’ll even lend you money!”

Amy had captured everything I’d wanted to say about supportive work environments and empowered teams. Our team was going to need friends to survive our learning and adapting times ahead. And so Amy made a poster labeled “Our Team Friends” and invited Richard to come over and sign in as our first friend.

When the poster went up on the team’s wall later that week, it quickly attracted attention from others whose work brought them into frequent contact with our team. “Can I be your team friend too?” they’d ask, in all earnestness. Amy would explain what our expectations were from friends, and to our surprise, one by one they happily signed their names.

Here’s the best part: we soon discovered that one of the team members had to be gone for two entire sprints, and the team felt shorthanded without him. Richard heard our concerns, and said, “Could I help? Could you use an extra hand?” The team was surprised at his offer, but quickly accepted it. Richard, like a true friend, backed us up wholeheartedly – he temporarily moved out of his office and onto a table in the team room and there paired with team members to deliver software, complete stories, and accomplish our iteration goal. Reflecting on Richard’s contributions at our retrospective a month later, we realized we couldn’t have done it without him. And the team felt that they had a real commitment from management to support them through this time of change.

I wished that I’d remembered Amy’s idea when I was working with that recent team and its involved, supportive manager. But it’s not too late for them, nor for your team. Consider inviting the support, understanding, help, and trust of those “outside” your delivery team. Make more friends, and try to keep them. And don’t forget to invite them to the post-sprint celebration at the pub!

Lost. Moved. Somewhat.

Anything we wait for long enough happens.  And that’s the story with my old Web home, MichaelJTardiff.com; that address now points here, where I have (some of) my (old) blogs posts. But what’s missing is what was at the old site: my bios, pics, resumes, and the like.

With the advice and assistance of folks more capable in this realm, I’m moving the whole kit and caboodle to a new home. In the meantime, here’s the place I’ll be.

Should you want some of the info that used to be at michaeljtardiff.com, drop me a line. I’m pretty easy to reach.

 

Lost, Now Found

I’ve been away for a bit.

But now, here I am, aloft and winging my way home to Seattle, deciding that it’s time to actually write the 482 posts that I’ve sketched out, started, even nearly finished.

I have a lot to say; I need to get in the habit of actually saying it, here.

Here’s what got me going again, inspired me, really: reading Steve Job’s resignation letter. The man has, for ever so long, had a knack for being essential, spare, and very, very clear.

As even this post indicates, I do not have such focus, discipline, or talent.

But let’s see what I do have, shall we?

It’s good to see you again.

The Agile Coach: “Establishing Trust”

Where it all happened

You’ve been patient, and I appreciate it. Here’s your reward: the second episode of The Agile Coach, entitled “Establishing Trust.” (Oh, wait—if you only follow my blogging here, this is the first you’ve heard of the podcast. No matter; the first episode was all about introducing ourselves, and if you want to listen to that one, just visit iTunes and download it. This time, though, we start getting meaty.)

In a little over 20 minutes, we—Skip Angel and Michael Tardiff—explore how an Agile coach establishes trust with those she or he is trying to help…and what can happen when that trust is lost. We tell stories of our successes and a few failures in this crucial aspect of coaching…and we barely scratch the surface of the subject. You can expect future episodes on different dimensions of trust.

Getting out the second episode of the podcast (the first one with real content), was trickier than we thought. Some unexpected travel forced us to try a “double-ender,” where the two of us, separated by 3,272 miles yet joined by the Internets, each record our own high-quality audio while watching and listening to each other using Skype. (The picture above is of the “studio” I set up in my childhood bedroom to record my end of the show.) To our astonishment, it worked, although not without a few complications and a bit of variable audio quality. We’re learning, and we expect that not distance, nor rain, nor snow, nor gloom of night will stay this podcast from its appointed schedule in the future.

Some of you have written to tell us you listened to and liked Episode 1, which was pretty content-free, really. If you liked Episode 1, you’ll love Episode 2. For the rest of you who are a bit harder to please…try Episode 2. You’ll like it. Let us know what you think, because that’s what makes all this work. Tell us what worked, what didn’t, and what you want to hear in the upcoming episodes by sending us a message

We think we’ve worked out the syndication issues, and we’re now on iTunes: search for “The Agile Coach” or just click here.

We promise that Episode 3 will come along a lot sooner than this one followed the first!

Let Your Fingers Do the Tossing

pixellated-walking-fingersI just threw away all of the telephone books.

For years, they’ve been delivered to my doorstep, from a few different companies. For years, I’ve unwrapped them and placed them on a high shelf. For years, I’ve never touched them. Why, oh why, have I bothered to waste time and space for all those years?

Because losses loom larger than gains.

I first saw that phrase in Chris O’Leary’s brilliant, one-page distillation of the the forces behind successful innovation. Chris points out that “people find the threat of loss to be far more motivating than the promise of gain.” And I see this every day as I work with teams that are trying to get better at doing what they spend their days doing, delivering business value to their customers through software.

“Change? Sure, that sounds like a good idea. There are lots of things wrong here. Wait…I need to do stop doing that? But I’ve always done that. Why? It’s the right way. Results? Well, yeah, when we do that, it doesn’t always work, but that’s just because Dave over there isn’t thinking things through when he…”

Change is what we want other people to do. But the rule is this: if you want to engender change in a group dynamic, go first. Be the change you want to see in the world. Charity starts at home—wait, that’s a different maxim. But you get the idea.

So I no longer have telephone books at hone. What’s next? The land-line telephone’s already gone; maybe I drop the VoIP service I got to save my long-time phone number? Stay tuned and see.

Waiting Is the Hardest Part

runners startingIt’s right there in Tom Petty’s song: “Waiting is the hardest part.” But Tom got it wrong: starting is the hardest part.

Everyone from Alexander Pope to Elvis points out that fools rush in while wise folk wait (Elvis gets right to the point, while Pope takes considerably longer). And who could fault a team, timid ScrumMaster, or tentative manager for sounding the depths before diving in and doing what needs to be done?

Well, Ron Jeffries can. In his book and presentations, Ron says don’t wait—start reaping benefits (and revenue!) early by getting working product into the market now, before your competitors do. My colleague Skip Angel exhorts teams to “just do it.” And my own experiences with watchful waiting have shown me the rear end of many opportunities that didn’t just knock once, but found another door when I was slow in answering. So why do so many of us, knowing what we do, still hesitate to start, whether it’s start a sprint, start a project, or start telling the truth.

Maybe it’s because we’re afraid.

I was listening a week ago to a presentation Diana Larsen gave at SolutionsIQ when I suddenly sat up straight. “We only learn at the uncomfortable edges,” she said, and I was launched back into a time a few years ago when I was working with a team to deliver a functional overhaul of a B-to-B e-commerce Web site.

The product manager and I (the program manager) wanted to use Scrum for the project, but the development manager, who managed all the members of the team, was reluctant, and insisted on using what had worked for him before. What had worked before was a mish-mash of upfront planning, seat-of-the-pants estimating, and Microsoft Project-assisted project tracking. The tracking wasn’t really tracking, though; each time something didn’t happen as predicted, Project just kept telling us how much faster we’d have to work to hit the non-moving deadline for delivery).

The three of us were responsible for providing input to an executive dashboard that expressed the status of projects using the familiar red-yellow-green traffic lights. Each week, we peered intently at the Project sheet, which the dev manager had printed out on three sheets of paper that he taped together. After a handful of week, we knew that the project had drifted into red territory. Each week, the dev manager said that he thought that, with a little more effort and a bit of luck, we could get back on track. Each week, we were willing to believe something that we wanted to believe. And so each week, all three of us agreed to ignore our misgivings and doubts and delay reporting the project status as red. Until one week, more than half the way into the project, something happened.

Stay tuned to hear the rest of the story.

The Bright Side

smiley faceNot all of us naturally have the gift of helping people recognize and resolve dysfunction and impediments without, um, peeving people off. When serving a team as a ScrumMaster, it’s easy to turn into a harping kvetcher. When management and team members both start changing their paths when you walk down the corridor, you know it’s time to find a more effective approach to your job.

Gretchen Rubin makes a familiar but often forgotten good point recently in her blog: there are different ways of looking at a given situation, and some may be more palatable and effective than others. A frequent result of your good work as a ScrumMaster is exposed dysfunction in your team or company, but there’s no reason to rub people’s faces in it. With a little imagination or attitude adjustment, you can make your point in a way that’s effective instead of demoralizing, while avoiding becoming a Pollyanna or sweeping problems under the rug.

My favorite example of this approach comes from a performance review written by the best manager I ever had. Summarizing the primary accomplishment of my last six months, a technical manual that I’d researched for five months and written in one, she wrote, “Michael’s guide to system management is the best manual on the subject we’ve ever seen. One can only imagine how good it would have been if he’d started writing it earlier.”

Lately, I’ve been particularly aware of how, in response to a positive suggestion or idea offered by another, many of us start by saying, “The problem is…” We lead with the negative, hardly the way to make our conversational partner feel good about their idea or our interest in it. There’s always time for the challenges to surface and be identified, but perhaps that time isn’t seconds after we first hear the idea.

Agile teams spend a lot of time dealing with “the problem,” in retrospectives, in pairing sessions, in planning meetings, in raising impediments. This is why it’s so important to identify and celebrate successes frequently, but there’s no need to wait until success is obvious. Create environments where success can thrive, by focusing on what’s good and encouraging more of that.

Now that I think of it, that’s how you brew good beer. When the sweet wort enters the fermentation vessel, it has lots of wild yeasts (from the air) and brewing yeasts (from you) in it. The trick to getting good beer is to encourage the brewing yeasts to grow and work faster than the wild yeasts. The good pushes out the bad, or if I’m going to be more facilitator-y about it, the useful prevails over the not useful. I’m told you grow a nice lawn the same way, but I know more about fermenting beer and Scrum teams than I do about gardening.

Two Steps Forward

 

I’m old enough that I spend some time looking back at a distant and immutable past. Forget the sundry poor personal decisions I’ve made; no one could get older without accumulating a sack of those. I wonder more about the large amounts of time I spent doing things at work that didn’t work. 

Why would I do that? I was getting paid, after all, and I was reputed to be smarter than the average bear. But more often than not, I found myself falling into one (or both) of two traps:

  •  Doing what I was told to do
  •  Thinking I couldn’t do what I knew was right

Wait, you’re saying – that’s what you’re supposed to do at work. So I used to think, and who could blame me? We get taught the first from birth, and learn the second sometime before entering the working world, or soon after.

But now that I’ve spent nearly a decade immersed in agile, I realize that  there’s no way that I can do a good job for my employer or client unless I ignore my upbringing. And that’s a problem since I can’t always do that, and I’m sure I’m not alone.

No matter what role you’re playing in an agile process, you need to do at least two things:

  •  Listen to what others are saying.
  •  Decide, along with your teammates, what’s the right thing to do.

It doesn’t hurt a bit to work for people who can deal with, or even welcome this kind of behavior.

As luck would have it, agile methods depend on this kind of behavior and others like it.

But this kind of behavior requires large amounts of something that not all of us, and perhaps for the reasons noted above, bring to work with us every day.

Courage.