agile.brazism

Sustainable Pace and Meetings

I’ll admit it: I’ve been triple-booked at work more than I can possibly imagine.

Part of that is a pure lack of institutional respect of people’s time, and the culture that dictates that everything is a priority, so obviously the other commitments you’ve made can’t possbily be as important as My Meeting.

But, part of that is an inherent lack of understanding of Sustainable Pace, especially when it comes to meetings.

Looking over my calendar for the past few months, I’m constantly amazed at the number of meetings that get scheduled in the miniscule crevices between other meetings. “Oh, you’ve got fifteen minutes between those two meetings. Let’s have a quick meeting to discuss this…”

Now, if I worked somewhere that employed a bunch of Marissa Mayers (see: BusinessWeek on “How to Run a Meeting Like Google”) then there’s a distinct possibility that this would be a very productive, if overwhelming possibility. But, I don’t, and it compounds the basic problem in my mind with this constant-stream-of-meetings mentality.

Today, I’ve had the opportunity to sit in a small conference room with one of my peers, and focus on one important deliverable. We called in a couple of experts when we needed them, and turned around our deliverable in a couple of hours. In short, a great use of our time.

After that, I felt myself mentally decompress. I took a few minutes to jot down some next-steps, and prepare myself for the next item on my big to-do list.

That took ten minutes.

Once I took that time, I was able to clearly and succinctly take care of the next items on my to-do list with a minimum of fuss, and with minimum interruptions on other people’s time. What could have (and possibly would have) resulted in two or three “quick little meetings” ended up being handled by a discussion or two, in under five minutes each.

I’ve read a lot over the past couple of years about two topics: multi-tasking at work in the name of productivity, and Adult ADD. Being ADD, I fully understand and live the juggling a thousand things lifestyle. It keeps my brain engaged, and paradoxically helps me focus.

But, I also realize that hand-in-hand with juggling a million different things is the ability to hyper-focus. When I need to, I can focus on a particular task and work on it to the exclusivity of anything else. In order to do that, I need to take the time to clear my plate, and catch the balls I have in the air, so to speak.

When my schedule is filled with back-to-back meetings, there’s no chance to clear my plate, no chance to take a minute to shift gears mentally. It’s a constant stream of new information and context switching, and much like when I’m juggling a million different things but none of them well, I’m in a meeting but not able to give it my full attention. Invariably, there are loose ends from the previous meeting that I need to capture, that will enter my head and distract me from the things I should be paying attention to now.

It’s an unsustainable pace, and it’s just as true with management and meetings as it is with Sprint tasks or a myriad of other things in life.

Without the time to absorb and acclimate new information and ideas, we’re just in an unsustainable flurry of things, and everything suffers.

How can we communicate this need to those making demands of our time? How can we - as developers, testers, or more generally as professionals - explain that we need moments of rest between bursts of activity? If that basic human need isn’t understood, what can we do to make it understandable?

Training for the Marathon

I took a bike ride last week with a friend who’s training for a half-marathon coming up soon - she ran, while I rode. Suffice to say, I was at a slower pace than I usually ride, and that left me time to think about the process of her training.

The first thoughts were all about the ideas of sprints versus iterations, and how far too often, teams end up falling into the “we never stop sprinting” trap. Instead of focusing on the sustainable pace portions of any agile set of practices, the team gets caught up in doing more, more, MORE. It’s unsustainable, and teams doing this begin the sacrifices to keep doing more.

Why do they do this? What’s the driver behind this self-destructive practice? In almost every case I’ve seen, it boils down to velocity.

“We did X points this last sprint, and our velocity is Y. We’ve got Z points left on the backlog for this release, so if we can keep that up, we’ll be able to release in [Z/Y] sprints…”

This is typically the point where Someone comes in, and objects to the reality of the situation.

“That’s not good. We need to release sooner.”

Ideally, this should be a pretty simple discussion. To complete all the stories on the backlog, as written, will take a given amount of time if their velocity’s right, and their estimates, and…

There’s the first trap: that past performance will always be an accurate predictor of future performance. That’s just not true, and velocity was never meant to be much more than a rough guide to potential future performance.

But, let’s assume that the team and Product Owner understand that. At that point, the negotiations start: reducing the scope, reducing the number of stories required for release, renegotiating the stories themselves to find ways to release stories with business value sooner. That’s too frequently not what happens, though.

“We need to increase our velocity, so let’s…”

Let’s what? Typically, the answers fall into something like:

  • …hire more team members
  • …work longer hours
  • …silently reduce quality to increase how many things are “done”
  • …something else equally short-sighted

When that happens, the sprints are failing, and the project will quickly accrue technical debt that, if left unchecked, will consistently reduce a team’s ability to get any new features done.

Which brings me back to my bike ride, and my friend training for her marathon.

How does she do it? Right now, she’s planning on running a half-marathon this fall. She’s typically able to run seven miles without much trouble, and the half-marathon goal is totally within her grasp.

This time last year, she wasn’t running at all, and hadn’t for years.

I have every expectation that, barring any unforseen injuries, she’ll be running in marathons by this time next year without any problem.

How did she go from not running for years to being ready for a half-marathon this fall, to being on-track to easily running a marathon next year?

First, she’s not sprinting. She has running Iterations, but they’re fixed and have definitive goals.

Second, her goals are gradually increasing. She’s running regularly, and inspecting her performance to set her next goal - just a little bit more this time, and see how she does.

Third, she’s inspecting and adapting. If she an off week this week, then she doesn’t expect to be able to pick up right where she left off the last, good week. Adapt her training schedule, and get back on track. Her velocity last week changed, and as a result, she’s adapting her current expectations. If that happens enough, she’ll have to adjust her schedule and run a marathon later in the year, or adjust her goals and only run a half-marathon.

But lastly, and I think most importantly, she’s built a sustainable pace, and she’s sticking to it. Of course she wants to be able to run a marathon now, of course she wants to be done with all of this training and have that feeling of success that comes from completing 26.2 miles. But that’s not realistic, and no amount of pushing, of running too hard or too far will get her there sooner without negative consequences - injuries, frustration, taking the enjoyment out of running.

I know I can’t be the first person who’s compared Agile iterations to training for a marathon, but it took slowing down on my bike, and watching someone else train for me to finally be able to articulate it.

Agile isn’t just about delivering software better. It’s also about delivering better software, at a sustainable pace, with a team that enjoys what they do.

That’s at the core of the principles behind the Agile Manifesto, and it’s at the core of being able to enjoy anything you do.

Even running.

About

talkin' the talk, with the battle scars to back it up

Ask me anything

Search

Following