AoAD2 Practice: Energized Work

Book cover for “The Art of Agile Development, Second Edition.”

Second Edition cover

This is a pre-release excerpt of The Art of Agile Development, Second Edition, to be published by O’Reilly in 2021. Visit the Second Edition home page for information about the open development process, additional excerpts, and more.

Your feedback is appreciated! To share your thoughts, join the AoAD2 open review mailing list.

This excerpt is copyright 2007, 2020, 2021 by James Shore and Shane Warden. Although you are welcome to share this link, do not distribute or republish the content without James Shore’s express written permission.

Energized Work

Audience
Coaches, Whole Team

We work at a pace that allows us to do our best, most productive work indefinitely.

I love my work. I enjoy solving problems, writing good code, watching tests pass, and especially removing code while refactoring.

But if I’m on a team with unclear goals, little collective responsibility, and infighting, I’ll wake up dreading going into work. I’ll put in my hours at the office, but I’ll be tempted to spend my mornings reading email and my afternoons picking at code while surfing through marginally related web sites.

We’ve all been in this situation. Because we’re professionals, we strive to produce quality work even when we feel demoralized. Still, consider the times of greatest productivity in your career. Do you notice a big difference when you wake up and feel eager to start work? Isn’t it much more satisfying to stop on time at the end of the day, knowing that you accomplished something solid and useful?

Energized work is about recognizing that, although professionals can do good work under difficult circumstances, they do their best, most productive work when they’re energized and motivated.

How to Be Energized

One of the simplest ways to be energized is to take care of yourself. Go home on time every day. Spend time with family and friends and engage in activities that take your mind off of work. Eat healthy foods, exercise, and get plenty of sleep. When you’re busy with these other things, your brain will turn over the events of the day. You’ll often have new insights in the morning.

If quality time off is the yin of energized work, focused work is the yang. While at work, give it your full attention. Turn off interruptions, such as email and instant messaging, unless they’re part of your virtual team room. Silence your phones. Ask your manager to shield you from unnecessary meetings and organizational politics.

When the yin and yang balance perfectly, you’ll wake up in the morning well-rested and eager to start your day. At the end of the day, you’ll be tired—not exhausted—and satisfied with the work you’ve done.

This isn’t easy. Energized work requires a supportive workplace and home life. It’s also a personal choice. There’s no way to force someone to be energized. However, you can remove roadblocks.

Supporting Energized Work

As a coach, one of my favorite techniques is to remind people to go home on time. Tired people make mistakes and take shortcuts. The resulting errors end up costing more than the work is worth. This is particularly true when someone comes to work sick; in addition to doing poor work, they could infect other people.

Allies
Pair Programming
Mob Programming

Pair programming is another way to encourage energized work. It encourages focus like no other practice I know. After a full day of pairing, you’ll be tired and satisfied. It’s particularly useful when you’re not at your best: pairing with someone who’s alert can help you stay focused. Mob programming isn’t as good as ensuring focus—it’s easy to tune out—but it is good for preventing the errors that occur when you’re tired.

It may sound silly, but having healthy food available in the workplace is another way to support energized work. Fruits, vegetables, and yogurt are a good choice. Donuts and other junk food, while popular, contribute to mid-afternoon lows.

Allies
Purpose

The nature of the work also makes a difference. [McConnell 1996] reports that software developers are motivated to do good, intellectually challenging work. Not every team can feed the poor or solve NP-complete problems, but a clear, compelling purpose can go a long way. Creating and communicating the team’s purpose is the responsibility of team members with product management skills.

Allies
Forecasting

To be compelling, the team’s purpose also needs to be achievable. Nothing destroys morale faster than behind held accountable for an unachievable goal. If the team is responsible for meeting specific date targets, make sure the targets are realistic and based on the team’s forecasts.

Allies
Whole Team

Speaking of targets, every organization has some amount of politics. Sometimes, politics lead to healthy negotiation and compromises. Other times, they lead to unreasonable demands and blaming. Team members with product and project management skills should deal with organizational politics, letting the rest of the team know what’s important and shielding them from what isn’t.

Allies
Informative Workspace
Reporting

People with project management skills can also help team members by pushing back on unnecessary meetings and conference calls. Providing an informative workspace and appropriate reporting can eliminate the need for status meetings. In an environment with a lot of external distractions, consider setting aside core hours each day—maybe just an hour or two to start—during which everyone agrees not to interrupt the team.

Allies
Team Dynamics

Finally, jelled teams have a lot of energy. They’re a lot of fun, too. You can recognize a jelled team by how much its members enjoy spending time together. They go to lunch together, share in-jokes, and may even socialize outside of work. As with energized work, you can’t force jelling, but you encourage it with by paying attention to team dynamics. The classic work on this subject, Peopleware: Productive Projects and Teams, now in its third edition [DeMarco and Lister 2013], is well worth reading.

Taking Breaks

When you make more mistakes than progress, it’s time to take a break. If you’re like me, though, that’s the hardest time to stop. I feel like the solution is just around the corner—even if it’s been just around the corner for the last 45 minutes—and I don’t want to stop until I find it. That’s why it’s helpful for someone else to remind me to stop. After a break or a good night’s sleep, I usually see my mistake right away.

Allies
Pair Programming

Sometimes a snack or walk around the block is good enough. For programmers, switching pairs can help. If it’s already the end of the day, though, going home is a good idea.

Allies
Team Room

In a physical team room, you can usually tell when somebody needs a break. Angry concentration, cursing at the computer, and abrupt movements are all signs. Going dark—not talking—can also be a sign that someone needs a break. When I notice a pair or programmers whispering to each other, I ask how long it’s been since their last passing test. I often get a sheepish reply, and that’s when I remind them to take a break.

Suggesting a break requires a certain amount of delicacy. If someone respects you as a leader, then you might be able to just tell them to stop working. Otherwise, get them away from the problem for a minute so they can clear their head. Try asking them to help you for a moment, or to take a short walk with you to discuss some issue you’re facing.

Questions

I work in a startup and a normal work week just isn’t enough. Can I work longer hours?

A startup environment often has a lot of excitement and camaraderie. This leads to more energy and might mean that you can work long hours and still focus. On the other hand, startups sometimes confuse long work hours with dedication to the cause. Be careful not to let dedication override your good judgement about when you’re too tired to make useful contributions.

We have an important deadline and there’s no way to make it without putting our heads down and pushing through. Do we set aside energized work for now?

There’s nothing quite like a late-night codefest when the team brings in pizza, everybody works hard, all cylinders fire, and the work comes together at the last moment. A great sprint to the finish line can help the team jell, giving them a sense of accomplishment in the face of adversity. However...

Sprinting to the finish line is one thing; sprinting for miles is another. Extended overtime will not solve your schedule problems. In fact, it has serious negative consequences. Tom DeMarco calls extended overtime “an important productivity-reduction technique,” leading to reduce quality, personnel burnout, increased turnover of staff, and ineffective use of time during normal hours [DeMarco 2002] (p. 64).

If you work overtime one week, don’t work overtime again the next week. If I see team sprinting in this way more than once or twice per quarter, I look for deeper problems.

Prerequisites

Some organizations may make energized work difficult. If your organization uses the number of hours worked as a yardstick to judge dedication, you may be better off sacrificing energized work and working long hours. The choice between quality of life and career advancement is a personal one that only you and your family can make.

Conversely, energized work is not an excuse to goof off. Generate trust by putting in a fair day’s work.

Indicators

When your team is energized:

  • The team has a sense of excitement and camaraderie.

  • Your team pays attention to detail and looks for opportunities to improve their work habits.

  • The team makes consistent progress every week and you feel capable of maintaining that progress indefinitely.

  • You value health over short-term progress and feel productive and successful.

Alternatives and Experiments

Allies
Pair Programming
Mob Programming

This practice is also called “sustainable pace,” and the alternative is, well, unsustainable. But some organizations still make energized work difficult. If that’s the case in your organization, pair programming or mob programming can help tired team members stay focused and catch each other’s errors. Ironically, your software will probably need more time to develop—to find and fix the errors tired team members introduce—so adjust your plans accordingly.

The extreme form of this organization is the death march organization, which requires employees to work extensive overtime week after week. Sadly, death marches don’t happen because of the massive value to be gained; just the opposite. [DeMarco and Lister 2003] (p. 161) explains: “In our experience, the one common characteristic among death-march projects is low expected value. They are projects aimed at putting out products of monumental insignificance. The only real justification for the death march is that the value is so miniscule, doing the project at normal cost would clearly result in costs that are greater than benefits... if the project is so essential, why can’t the company spend the time and money to do it properly?”

Your best experiments when faced with this sort of organization are the ones that involve sending resumes.

Further Reading

Peopleware: Productive Projects and Teams [DeMarco and Lister 2013] is a classic work on programmer motivation and productivity. It should be at the top of every software development manager’s reading list.

Rapid Development: Taming Wild Software Schedules [McConnell 1996] has a chapter called “Motivation” with a nice chart comparing programmer motivations to the motivations of managers and the general population.

Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency [DeMarco 2002] looks at the effects of extended overtime and overscheduling.

Share your feedback about this excerpt on the AoAD2 mailing list! Sign up here.

For more excerpts from the book, or to get a copy of the Early Release, see the Second Edition home page.

If you liked this entry, check out my best writing and presentations, and consider subscribing to updates by email or RSS.