This reassessment was refreshing, and left me with some energy to write about more of these Agile practices that foster creativity and sustainability.
Slack
Definitions of "slack," and related practices, abound. To me, "slack" means not allocating 100% of the team's time. The team commits to a realistic amount of work, rather than falling for the "planning fallacy" that everything will go according to a rigorous plan.
Teams who don't plan out 100% of their iteration tend to provide more value. This may seem paradoxical, until you consider human nature: If people go into a sprint (a.k.a. iteration) sensing that they are committed to 100% capacity, they start the sprint...sprinting! They are stressed from day 1, and will lose enthusiasm for the work long before the end of the iteration.
Related Practices
Velocity: Team velocity, measured by "yesterday's weather," can help. If the team tends to do 12 points in a sprint, we schedule 12 points. Velocity--when it's not constantly debated, gamed, or artificially increased--already takes many unforeseen difficulties into account.
Leave Room on the Plate: I've seen teams who set "stretch goals" or add "low priority" stories to the trailing end of the iteration plan. If trust is strong, this can work, but it could lead to overcommitment and disappointment. Instead, I suggest allowing the team to pull small, high-priority stories in at the end of the sprint, if there's time left.
Of course, all other stories must first be "done done." Is there any further testing needed? User documentation to alter? If so, there is still work to be done, and the team should not pull in more work yet.
You know the phrase "too much on my plate"? Be sure you're not asking the team to "super-size" their iteration plan.
Creative Time: Some teams set aside actual "slack time." During this time, the team may:
- Explore a new technology that would help improve flow later.
- Refactor that old area of code that bothers or worries us. Perhaps it doesn't need to change very often (else we'd refactor prior to expanding its responsibilities), but we just have some energy and desire to clean it up now.
- Brainstorm on some upcoming technical challenge.
- Run a "spike" or experiment.
- Thursday afternoon was set aside for "play."
- Each person could use the time to explore some area that was of interest, and that had potentially positive effects on career skills or the team's well-being.
- The team was asked not to work on stories from the iteration. If they had, this would throw off the velocity and thus erode this practice over time.
- Examples of acceptable activities: Spikes (timeboxed experiments). Refactoring away some technical debt. Trying out a new development or testing tool. Holding an extended brown-bag to talk about Design Patterns. Anything that didn't break the previous guidelines.
- We asked the team to describe how they had used their slack time at the next stand-up meeting, and "it wasn't very productive" was an acceptable answer, with no stigma attached.
- Full-time employees could even simply play video games or surf the web if (a) they sincerely needed the down-time and (b) they gave a report at the Friday stand-up (and "I played Dragon Age and got my mage to level 17" was perfectly acceptable).
I suggest Thursday afternoons rather than Friday afternoons, because on Friday afternoons people will naturally just escape after lunch for the weekend, and little team value will be obtained.
Sustainable Pace and Energized Work
Different people have different amounts of daily sustainable energy for doing certain parts of their jobs. It often appears that younger developers have more energy to work long hours on a problem. I've since realized that what most knowledge-workers of any age tend to do is to push themselves beyond their own rational limits, into an "irrational loop." They're too wrapped up in a problem to realize that they're tired and hungry, so they keep pushing on that problem. In the irrational loop, they become more and more frustrated, and are prone to make simple mistakes that cause the solution to elude them further, resulting in more time spent looking for a solution.
I sometimes quip that most bugs are written in the last two hours of a 12-hour day. It's probably not accurate as stated, but it gets the point across: Work hard while you have the energy, then stop.
I cannot count the number of times over my 25 years when I've had to be the one to say "Y'know, this problem will wait for us until tomorrow morning." In fact, it's now one of the most fulfilling parts of my job as coach to say "You're stuck? Roll back to the last green bar [i.e., all tests passing] in your local repository, go get some food, some rest, and some time with your families. Go home!" Nearly always, the next day someone walks in having realized what the roadblock was, and with a good solution rattling around in her skull.
There's another benefit: People will sometimes avoid going home because there's even worse stress waiting for them there. But those troubles won't fix themselves, while we hide at the office answering megabytes of e-mail. Letting people have the time to spend with families, on hobbies, and on a full night's sleep pays off almost immediately: Fewer sick days, fewer chronic family issues, higher retention, and alert, relaxed teammates!
In my own experience, I know I can teach my courses with four hours of sleep and a double-shot espresso, if I have to. But I'm effectively on autopilot, playing back the recorded messages in my brain when asked a familiar question. Instead, I prefer a good dose of actual sleep, and no caffeine: I'm more focused and more in tune with the needs of the attendees.
Related Practices
Go Home: Once you know approximately where your limits are, set a time when you plan to go home, and stick to it. Let colleagues know when you're starting to run down, and that you've got about an hour left of productivity in the office. Schedule time for yourself at the end of the day: A yoga class, dinner with the spouse, or just a "go home" reminder on your calendar. When asked if you can attend that 6:30pm meeting, say "No."
One Failing Test: For TDD or XP teams, this is a favorite for lunch breaks or at the end of the day. Leave your (small amount of) uncommitted changes on your dev machine with a single failing unit test to mark where you were. It will take no time at all to figure out where you left off. Much less context switching! Of course, "all-green and committed" is an alternative, but there's nothing quite as concrete as a single (uncommitted!) failing test to get you back into the Zone.
We appreciated this practice so much, we'd start a new task and write the first failing test with only a few minutes left in the day.
Continuous Learning
On a day-to-day basis, people are energized by intrinsic motivators such as interesting, valuable work; pride in quality work; and interesting learning experiences. This does not have to be limited to a yearly trek to a trade conference. Those are great, but if they're the team's only source of fresh mental stimulation, all those spongy brains are going to be surviving on minimal subsistence the other 51 weeks of the year.
Related Practices
Sharpen the Knives: You've heard the old adage about the lumberjack who--in order to cut a tree in an hour--will take 45 minutes to sharpen the saw?
This old analogy really needs updating: Not many of us are all that familiar with the logging industry. Right now, reality cooking shows (Top Chef, Iron Chef, ...) are hot, and I've just learned the right way to sharpen cooking knives (one way for me to contribute in the kitchen, besides cleaning it).
So, why do chefs sharpen their knives? Because they can go faster, work more accurately, and create higher quality. We wouldn't tell a chef to "just keep cooking! Go, go, go! Never mind quality or technique or safety..." Would we?
Most teams need to "slow down to speed up" using "Slack," and this practice takes slack one step further: We improve throughput of value by allowing the team the time and authority to learn an effective new skill.
Pair Programming: Two people collaborate on critical efforts, so teammates constantly learn from each other. This learning is not the result of a teacher-student or master-apprentice relationship: Peers can share a variety of things, including efficient tools and techniques, domain knowledge, product knowledge, and appreciation for the skills and responsibilities of other teammates.
Summary
"Measure twice, cut once."In all endeavors, at all of life's stages, the best action to take is often counter-intuitive. When you feel that old chaotic wind spinning around you, step back, get more of the big picture, and try out one of these practices, or one of your own invention. They are all essentially the same: You are taking the time necessary to complete your task with a high degree of quality, integrity, and craftsmanship; and without ruining your health.
"Sharpen the saw."
"Slow down to speed up."
"It's a marathon, not a sprint."
Okay, I'm outta here...!
