Wednesday, October 01, 2008

Just A Little Taste Of More

To celebrate the 2nd anniversary of this blog, and because my last working day was exactly two months ago today, here's a brief excerpt from the first draft of my current book, More Real-Life Adventures of AgileMan (Year Two: Easier Said Than Done). Note that the final version of the book could be drastically different, and that some or all of the following words could be changed or not even appear at all in what finally gets printed. But as of right now, here's what some of the words look like, in an Issue entitled "Buddy, Can You Maybe Just Cut Me Some Slack?":


For many of us at my company, books were common items to see resting beside our keyboards or making the trip home and back every day in knapsacks or briefcases. While not everyone was reading up on topics that were applicable to our jobs, lots of us were. Since moving to Agile, reading up on subjects that might help us in our work had become a much more prevalent part of the culture. Besides the big stack of Agile reference material, we also had copies of:

  • Good to Great: Why Some Companies Make the Leap… and Others Don’t by Jim Collins
  • Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister
  • The Responsibility Virus: How Control Freaks, Shrinking Violets – and the Rest of Us – Can Harness the Power of True Partnership by Roger Martin
  • Slack: Getting Past Burnout, Busywork and the Myth of Total Efficiency by Tom DeMarco
  • and others, with similarly long and important-sounding titles!
All of them had insights to share on various aspects of how to be effective in a healthy team environment. And that, after all, was a big part of what we were trying to accomplish when we first adopted an Agile methodology, as well as tying into what we were trying to get right with our Top 7 Learnings. I’d heartily recommend each and every one of them to anyone interested in that topic.

But it was Slack, by Tom DeMarco, that had the biggest direct impact on us as we moved into Agile Year Two. It’d be tough to get even this far into reading this second AgileMan book without appreciating that we suffered from the chronic problem of having too many key people, especially among leadership, who were loaded up to 200% or more and therefore often operated like chickens with their heads chopped off. Interestingly enough, DeMarco writes in his book about such organizations, and in many ways Slack read as if he’d stopped by and observed us in action for a few weeks! He advocates for something that’s even more counter-culture (by which I mean, counter to our culture!) than simply reducing everyone to 100%: he makes a compelling case for building slack time into everyone’s schedule!

While you should read DeMarco’s book to get the full story, what’s relevant here is that "slack" isn’t an invitation to goof off. It’s time to think. It’s time to pause and reflect, time to let your mind wander a bit into new areas because that can often lead to interesting revelations, or just time to deal with the unexpected. If I remember correctly, DeMarco refers to slack as having some give in the line, rather than having the line completely taut at all times. So think of that as I use the word “slack” from now on, and try not to picture the lazy, good-for-nothing “slackers” who you knew – or were! – back in high school!

Google, the one-time Internet start-up company whose product is now so ubiquitous that its name has –rightly or wrongly! – become a nearly-universal synonym for “search,” “research,” “fact check” and “look up,” has institutionalized the concept of slack with its “20% time.” From what I understand about how it works – and that’s very limited, as I’ve never worked there! – Google employees are expected to spend the equivalent of one day per week on unscheduled, “blue sky” type work. This could mean prototyping an idea that you’ve had but aren’t yet sure has any potential, re-factoring some programming code that’s been bugging you or causing lots of headaches, or researching some topic that you think may help you in the future, to name just a few ideas that are probably quite lame compared to how Google team members actually use that time. They’ve had this policy in place for several years and can point to various products (I believe gmail is one of them) that have come out of it. It’s now part of the Google culture.

So here we have the company that I work for, with its already-conflicting forces of sustainable pace and overloaded roles colliding violently, and into that mix steps the concept of slack time, operating, as it does, somewhere to the far left of sustainable pace! I mean, really, c’mon: how could hilarity not ensue?

OK, so perhaps it wasn’t all that hilarious, but some very interesting results did come out of the fact that several of us read Slack and took it to heart. Sometimes it was entire teams who began setting aside portions of their Iteration time for “slack work,” while in other cases it was simply individuals giving themselves a little breathing room in which to think, plan or dream. In this Issue, I’m going to describe a little of each.

3 comments:

Boneman8 said...

To see what has actually been borne out of slack time, or as some call it, "Product Improvement Time", it's definitely worth its weight in gold!

Anonymous said...

Well, right. But if you had put in 110% then we would have made the deadline on that stuff we committed you to.

Mike Marsman said...

When I was at Google last Aug, I asked some engineers there questions about slack time. I heard that, while slack time does still exist and can be used, it's no longer as free-to-use as it once was. You need approval from your manager for any items that you would like to use slack time for and they need to be demonstrable. Generally speaking, it can only be used to improve parts of the product you're working on (a recent example is the google maps walking/transit directions, i believe)