I started to title this post “On Being in Two Places at Once,” but can one really do that?
One can more easily appear or publish in two places at once, and I wanted to say a few words on that.
I intend to let these musings emit on a number of frequencies and forms. My personal blog is what you’re reading here. My employer’s employee-blogs site will also contain versions of what I write. And I’m experimenting with one of my favorite tools, Slack, by posting blog dispatches there, where they’ll be joined by comments and contributions by my collaborators at my employer and perhaps even my client,
Here’s what I wrote, in a series of messages, to start out the new channel:
Welcome to a form of my blog that begins today about my experiences living physically in Seattle and working full-time and in real-time in London. This is going to be fun!
Dispatches will post here, where we can treat them like we do posts in any other channel, with comments and other people’s contributions and comments. I’ll also post to my personal blog, FeelingAgile.com, and to an Accenture blog that I’ll create as soon as I ask my friend Janel to guide me through how to create one of those.
Is this effort well thought-through? Most assuredly not. How can one think-through what one can’t yet conceive?
Time is moving fast, or at least events are. A week ago, I was in Seattle, still two days away from boarding a plane to Heathrow to being my first month living and working in London. Seven days later, I’m back here in my Seattle living-room workspace, beginning the various incarnations of this blog. And it’s not even the beginning of the Monday workweek yet!
Tune in, ponder, and contribute! This is—I hope—going to be interesting, both as an experiment and, if I/we/y’all write it well, as a blog!
But first, this message from my spirit guide sponsor. “Remote” seems to be the hardest word; it’s doesn’t have great connotations, even in the “remote control” sense. I picked this title for this blog-channel so people searching for the two other newly created channels, #remote-virtual-teaching and #remote-virtual-coaching-engagements, would stumble upon this one too. “Virtual” is a bit better, suggesting that all the virtues of whatever it is one is doing are still present and delivered, but the virtual-reality wave might have flavored that a bit too much, with it’s uncanny-valley feeling of being not-real.
Semantics, you say, but in the U.S.—I’ll be using that phrase a lot, as my being and heart are in two countries whilst this experiment unfolds—the Republican party has made decades of inroads into dominance of American political life by paying attention to the semantics and metaphors that guide our lives, our thoughts, our feelings, and our choices (see The Metaphors We Live By and master of re-framing Frank Luntz) among many others, including “noted semanticist” S. I. Hayakawa)
So what do we call this? I’m going to go out on a limb, even though I’m not comfortable or skilled at prognosticating: this is what the future is. The Current Crisis is just one more straw that’ll, instead of breaking the camel’s back, will help build our new house. We’ll see if the wolf blows it down, or if it turns out to be much sturdier than we thought.
One last semanticalistic note: I called this channel “remote_virtual_LIVING” because I don’t think the dichotomous “work-life” balance exists. Rather, we exist in a diunital “both-and” world, where work and living are difficult to tease apart.
It’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.
Not 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.
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.
It seems – at least to me – unlikely that I’d be moved to write a post by learning that O.J. Simpson, thirteen years to the day (!) after being acquitted of murder, was convicted of kidnapping and robbery. My first thought was this: it may take a while, but as Shakespere said in The Merchant of Venice, “at the length truth will out.”
Tell me if this sounds familiar. You’re on a project, you come to a milestone, a crossroads in the schedule, you take stock of where you are, and suddenly comes that feeling: you’ve been here before. And last time, it wasn’t fun when you arrived at this point. How could you have ended here again, after all you learned last time?
If you’re on a team, maybe it’s even worse – you’re not the only one who remembers the past, now that you’re facing a present that looks just like that ugly memory. Sure, I could have missed the signs we were heading towards ruin, but all of us? Isn’t this why I work in a team, so that my teammates can save me from myself?
I remember when, sitting in Ken Schwaber’s Certified Scrum Master class, I first saw his slide warning about the challenges we’d face as intrepid Scrum Masters when we returned to work:
- The era of opacity
- The tyranny of the waterfall
- The illusion of command and control
- The belief in magic
“The belief in magic.” I sat bolt upright in my chair, realizing that I’d spend years and years (and years) again and again believing, or hoping, or praying that what I could see coming somehow wouldn’t come.
“Sure, last time things didn’t work because of a, b, and c, but this time, things will be different,” I’d think. “Next week, we’ll catch up” (after six successive weeks of not catching up). “This time, QA will discover the really bad bugs at the start of testing” (instead of near the end). And “this time, no one will get sick,” or “we’ll be done before Christmas for sure.” “If I can just spend one more day trying to fix this bug, I’m sure I’ll get it done.” “It’s been two weeks, now – that kidney stone is sure to pass tomorrow and Paul will be back on the team pairing and testing.” You have your own list, don’t you?
I’ve been compiling an new list recently, and it’s even more horrific.
- “We’ve been writing tests throughout the project, but here at the end, it’s crunch time, so let’s speed up by dropping tests.”
- “Yeah, pairing works pretty well, and it means we don’t have to do those code reviews, but heck, we can work twice as fast if we split up and work alone.”
- “But we have to work longer hours until we get done; we won’t keep this up forever, just until we get over this hump.”
- “Well, if we get the code feature-complete, we can use the QA period to find and fix the bugs before ship.”
“I want to believe,” we think. In the end, perhaps, we’re thinking no more clearly than Mr. Simpson, that we won’t get caught this time, that what doing is “right.” Magic tricks. done right, are awfully convincing. It’s a short hop from the willing suspension of disbelief to knowing self-delusion.
I started, a month ago, writing a blog that was about agile and feelings and how they intertwined for me. Seven days later, my close friend died, after a very long battle with illness and, sometimes, with life.
It turns out that I have feelings about that.
For a long while, I wrestled with whether that was something to write about here. It’s become apparent to me that if I don’t write about that, there’s nothing else I can write here.
For some of you, this might be the time to skip ahead to the next post, which is more likely to be all about agile. I do promise, though, that this one has more than just the minimum Obligatory Agile Content, to invoke a newsgroup meme from long ago.
Whenever I was with my friend, with the occasional happy exception, resistance and conflict were a part of what happened between us. That’s an odd foundation for a friendship, and a dynamic that often sees friends drift apart.
That didn’t happen with us. Why?
My friend had decided, ten years ago, that she was going to be my friend; this was long before I wanted that to happen. I am, like many of us, resistant to changes, even those that might be good for me. And so, for two years, I resisted. I was cordial; she brought me lunch when she went out to get food. I was standoffish; she invited me to group gatherings after work and Easter celebrations. I was reserved; she was effusive, funny, larger-than-life. And persistent.
One day, and I don’t know what made that day different than the hundreds that preceded it, I stopped resisting. I said yes. And we became friends. I don’t know why, but I decided that what I would bring to our friendship was honesty: I resolved to always — always — be honest with her.
There’s a reason that people often use “honest” and “brutally.” All-honesty-all-the-time is a tough thing to pull off, but even tougher to put up with.
Still, I, she — and we — persisted. There were periods where we argued, or fought, or sulked, or withdrew into our respective corners. I remember some of those apart-times as being — I’m being honest here, just as I promised to always be with her — wonderfully relaxed and happy. It was so much easier to go on with my life without the drama, without the conflict, without the burden of being honest even when, and especially when, it hurt. We’d always come back to some middle ground where we could, and did, deal with each other, and be the friends we were.
The last night my friend was alive, I visited her in the hospital. I’d like to tell you that the time we spent together was peaceful, loving, and mindful of the short time that remained. I can’t.
Whenever I think of agile approaches to making software, I think of resistance and conflict. I like to think that those aren’t what I bring to the table, but who knows? If those things are there when I am, maybe I bring them. And regardless of who brings them, they’re there, and they can’t be easily ignored.
I like agile because it fits how I want to live my life. I want to be honest; I prefer being direct; I value hearing what people really think, and want to know what they feel. I like working with others to get great things done. And to a greater extent than anything else I’ve used in the decades I’ve been at that, agile approaches give me more of all that in my working hours.
Once there was a small team in a startup company that needed someone to help them accomplish their goals. They picked me. Together, we learned how to work and be agile, and we shipped software. One day, I remember finishing a standup and slumping slowly to the floor — it had been a contentious meeting. Sitting there, I realized why I wanted to be working beside and with these people — they wanted to work beside and with me, even when the reality of our working together resulted in contention, resistance, and conflict. We could have retreated to our corners, backed away from our principles, stopped working on working together.
Our working relationship succeeded, not in spite of our differences or disagreements or conflicts, but because we brought all those to the table along with our talents and passions and energy. There were times when you couldn’t tell which was which — it all just was what we were, and how we were, and it was what we were willing to work with.
Working with people who “get along” feels better than when there’s discord and disagreement. To me, agile feels right because of the commitments teammates make to each other: we’ll be honest, we’ll be transparent; we’ll work together for a while, them look at what we do and make changes where we think they’ll help. Those aren’t hard to endorse and encourage.
Good agile teams also make a commitment that’s less explicit, and every bit as essential: to stick together, to value everything that each of us brings to the table, to find unity in our differences. Sometimes, it’s not that easy to see what’s right in front of us.
You can bet we’ll visit some of these ideas again in the months ahead.
There’s a poem by Edward Estlin Cummings. You probably know him as ee cummings, but that’s just typesetter’s revenge. He never wrote his name that way, but he was particular about how his poems were rendered into type, and that just frustrated the folks who put books together for a living. They’d learned all these rules about how to put together punctuation and capitalization, and here was this guy who wanted the book to look the way his typescript looked.
Anyway, there’s this poem. It doesn’t have a title, but most everyone (thanks to those same typesetter guys, or maybe their partners in publication, the “ediders”), uses the first line of the poem as a handle for the rest of it. So if you were to search the interwebs for
since feeling is first
you’d find it, I’d avoid violating the intellectual property rights of the estate of Mr. Cummings, and you’d get a lot of commentary and interpretation thrown in for free. I’ll wait while you go search and read…
This blog, unlike the poem, isn’t about love or punctuation (but see this). It isn’t about methodology, and it might not even be about agile, at least not much. We’ll see. But this poem is what gave me the idea to write — or try to write, much as Westerners have tried to write books “explaining” Zen — about how it feels to practice an agile approach to developing software, and how that feeling doesn’t stop with the bits but has spread through my life.