Foster Agile: Not Gonna Happen, Pt. 2

Part of the Foster Agile series.

In the original Not Gonna Happen post, I wrote about how my step-father says “not gonna happen” when I set some unreasonable goal for our work renovating my house.  The post focused on how his statement of hard limitations forced us to adopt realistic goals and why having realistic goals is valuable.  I just had a conversation with some Scrum Masters, though, and I realize there is another value of “not gonna happen” that the original post skated right past.  Long before we get into the benefit of realistic and well-crafted goals, we get the benefit of facing the truth.

Many if not most folks have at least some interest in working with others collaboratively.  We want to find solutions that make us all happy.  We want to help each other out.  So when someone comes at us with an unrealistic request, it is very, very hard for us to bluntly say, “not gonna happen”.  Not only are we afraid of them killing the messenger, but being that blunt feels…uncollaborative.  In fact, I wouldn’t be surprised if saying things that bluntly, even if dressed in slightly more corporate-friendly words, would result in the other person saying, “C’mon.  Why can’t you be reasonable?”

The truth is, steadfast adherence to one’s professional opinion of the impossibility of a given scope/time combination–i.e., sticking to “not gonna happen”–, is about as reasonable as you can be.  The trick is marrying that resolution to the truth with an attitude of cooperative invention, seeking and suggesting alternatives that could possibly work.  But that is one strange marriage: “not gonna happen” just doesn’t seem like it goes with the optimism of “here are a bunch of other options”.  If you let your desire to make things work out influence your sense of truth, “not gonna happen” turns into “won’t likely happen”, and then into “maybe it’s possible after all”.  Now the marriage is a mess, with neither partner true to itself: the truth of limitations is watered down, and the alternative plan probably hasn’t gone far enough to really address those limitations.

I now see the great challenge of keeping the marriage going in my head, between the hard “not gonna happen” and the soft “but, hey, partner, let’s work out some way that will happen”.  I recognize that I have often confused compromise with collaboration, trying in vain to compromise with the hard truth of limitations.  I’ll keep collaborating with others to find possible solutions.  However, going forward, when I really believe that something is simply impossible, regardless of the pressure put on me, I will try to say–and keep saying–, “Not gonna happen.”

Foster Agile: Keep Your Eye on the Ball

Part of the Foster Agile series.

About twenty years ago, I was working for my step-dad’s engineering firm. Deadlines all around, I was paralyzed. I told him that I didn’t know what to do.  He said, “My grandfather always told me: ‘Keep your eye on the ball.'”  I said, “Sure, but what if there is more than one ball?”  Without missing a beat, he responded, “Keep your eye on the one that’s going to hit you first.”

This advice has served me well over the years, but working alongside him renovating my house over the last few years has really made the lesson stick.  At the start of a day, we discuss what we aim to do.  Then, we do that and only that until the end of the day.  I have occasional moments of panic that I am neglecting something important out there, or that I am going the wrong course, but working alongside my hyper-focused step-dad, I stay with the selected task.  There is this strange feeling–perhaps it is Csikszentmihalyi’s flow, I’m not sure–that the rest of the world has been pushed outside a bubble around us.  By the end of the work weekend, we have accomplished an astonishing amount of work.  As for the things calling from the outside world, nothing has burned down as a result of my ignoring them for a while.

I’ve since tried the same thing at work. I noticed that I was letting my focus slide all over the place in the time slots available between meetings. If I could manage to attend a scheduled meeting for an hour, why was I struggling to maintain focus on a task for an hour? So, I set up meetings with myself to focus on those tasks. And I kept my eye on the ball. The same feeling from working with my step-dad came back. The world retreated behind a bubble. The same anxieties came, but I stuck with my tasks (kept my eye on the ball that was going to hit me first), honoring my commitment. When I emerged, nothing had exploded. The only real change was that I was burning through tasks at a much higher rate.

I struggle to exercise the enormous discipline required to give myself this gift of focus. First, I have to plan my time, committing chunks of time to given tasks.  This runs counter to my impulse to just dive in.  Second, I have to make hard decisions when I realize my list is simply too long for the day.  I have to resist impulse #2: rely on wasteful wishful thinking.  Third, even when I have planned my day, yet another impulse presses me to respond when things call, rather than keeping blinders on.  In all cases, I have to fight an ingrained habit in order to avoid distraction.

Focus is a core value of Scrum.  At the daily stand-up, for example, team members have this wonderful opportunity to select a single task, or a set of serial tasks, to take on for the day.  The system explicitly lays out their right to keep the rest of the world off behind a bubble.  Scrum and other Agile frameworks enable this focus through the key structural component of iteration: “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”  Breaking a schedule into chunks allows you to break your work into chunks in the same way, leaving everyone the freedom to focus only on the set of work selected for the current chunk.  It keeps you from the much more complicated discussions you have to have when you have a boundless future in which to schedule your boundless list of tasks.  Focus is one reason Agile principles can work. However, it’s not enough for them just to enable focus; one must discipline oneself to apply those principles.

The folly of multitasking is well-known, but I suspect that many people see its danger only at coarser levels. For example, they talk about the problem of having to go to a couple of half-hour meetings a day, or of having to switch product focus from sprint to sprint. While I agree that these switches degrade focus, it is at the grain of minutes and even seconds that I think context-switching does its greatest damage. You click the bookmark for your bug-tracking software and the system is slow. In the moment you wait, you switch to look at an email that just came in reminding you to submit your time sheet. You open the time sheet app. Another delay in loading. You switch back to read the next email. This pattern continues, and all of a sudden you have eight tasks cluttering your mind. The impulses had good intention: “It is a waste of time for me to stare at the screen while the bug-tracking software loads, so I’ll do something else for a minute.”  Unfortunately, it just doesn’t work. It is actually more efficient by a stunning degree to stare at the screen until the system responds. This is the powerful counter-intuitive truth of “keep your eye on the ball”.

Are you as focused as you think?  I offer this challenge. When you are done with this post, figure out your next few highest priority tasks.  Rank them.  Do the first, and focus only on that until it’s done, at which point you move on to the next.  Pay a little attention to yourself as you do.  Are you really focused?  Did you switch over to email for just a second?  Did you make that spreadsheet a little fancier than it needed to be?  Did you remember something “more urgent’ you had to do and switch to get it done because it would just take a second?  If you switched away, try again.  This time, force yourself not to switch.  Once you’ve succeeded in avoiding a switch, look back on how it went.  What was different?

Highfalutin talk aside:  Keep your eye on the ball.  And if there’s more than one, keep your eye on the one that’s going to hit you first.

Foster Agile: S**t My Step-Dad Said

My step-father has been very successful in academia, private business, and–most relevant here, oddly—making buildings. As far as I know, he only knows about Agile because of my yammering on during some visit. Nonetheless, I learned many of the truths underpinning Agile and Lean thinking from him.

Note that I wrote “truths underpinning Agile and Lean”, not “core Agile/Lean principles”.  The folks who wrote the Agile Manifesto didn’t hunker down in some laboratory and invent Agile ground-up as a theoretical framework.  Rather, they extracted certain commonalities from their empirical observations of real work experience.  Indeed, they start: “We are uncovering better ways…” (emphasis mine).  Read the manifesto or any of the principles.   They don’t say why the approach works, but only that they have observed it to work.

This is one reason I believe so strongly in Agile: it stems from broad empirical knowledge, and not just some cool theory that seems like it might work.  For those new to Agile, though, it can smell like the emperor’s new clothes.  “I can’t really tell you why this works, it just works.  Trust me.  It’s magic.”

I am generally trusting, so it’s enough for me to give it a shot and see for myself.  However, I am also obsessively analytical, and—especially when I am asking others to take a leap–I like to have a better theoretical understanding.  I want to connect the empirical observations of others to some less lofty things that I have observed myself.

That’s where my step-dad comes in.  Before working in Agile, I worked in a variety of roles in different organizations.  During those 18 years, I noticed many things that don’t work and a few that do.  Near the beginning of that time, I worked for a consulting firm of my step-father’s, and toward the end of it, starting renovating my house with him.   During work weekends, I and others were repeatedly stunned by how much more work we got done when he was there leading.  The model presented by this productivity and his superlative discipline allowed me to distill my rough observations of work into–yes, I’m going to say it, and with a capital T, no less–Truths.  What a nerd.

When I started working in a Scrum shop, I read Ken Schwaber and Mike Beedle’s Agile Software Development with Scrum.  Here was a way of working that mapped to the Truths I had seen.  Woohoo!  Again: what a nerd.

Why does this matter to me?  It calms my anxiety that this new set of clothes is of the imperial variety.  And it helps me, as a coach, calm similar anxieties in others.  I’m grateful to my step-dad for showing me these things, and I’m planning a bunch of posts about these Truths that I learned from him.  He’s from a small town called Foster, so I’ll call the series Foster Agile.  Let’s see how far I get.