in 99 words
Professionals do their best, most productive work when they're energized and motivated. To achieve this, combine quality time away with focused attention while at work.
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.
While at work, give it your full attention. Silence your phone and turn off interruptions like email and instant messaging.
Support energized work by providing a compelling vision and creating achievable plans. Shield team members from destructive organizational politics and useless meetings.
the cicadas sing--
tired, sore, I'm ready for
a perfect evening
The following text is excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.
- Whole Team
We work at a pace that allows us to do our best, most productive work indefinitely.
I enjoy programming. I enjoy solving problems, writing good code, watching tests pass, and especially removing code while refactoring. I program in my spare time and sometimes even think about work in the shower.
In other words, I love my work. Yet put me on a team with unclear goals, little collective responsibility, arguing, and infighting, and 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 technical websites.
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 blessed to go into work? Isn't it much more satisfying to leave on time at the end of the day, knowing that you accomplished something solid and useful?
XP's practice of energized work recognizes 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
Go home on time.
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. While 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. Silence your phones. Ask your project manager to shield you from unnecessary meetings and organizational politics.
When the yin and yang mesh 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—though 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
Stay home when you're sick. You risk getting other people sick, too.
One of my favorite techniques as a coach is to remind people to go home on time. Tired people make mistakes and take shortcuts. The resulting errors can end up costing more than the work is worth. This is particularly true when someone is sick; in addition to doing poor work, she could infect other people.
- Pair 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 but satisfied. It's particularly useful when you're not at your best: pairing with someone who's alert can help you stay focused.
It may sound silly, but having healthy food available in the workplace is another good way to support energized work. Breakfast really is the most important meal of the day. Mid-afternoon lows are also common. Cereal, milk, vegetables, and energy snacks are a good choice. Donuts and junk food, while popular, contribute to the mid-afternoon crash.
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 project can feed the poor or solve NP-complete problems, but a clear, compelling statement of why the product is important can go a long way. Creating and communicating this vision is the product manager's responsibility.
An achievable goal goes hand-in-hand with a compelling vision. Nothing destroys morale faster than being held accountable for an unachievable goal. The planning game addresses this issue by combining customer value with developer estimates to create achievable plans.
Speaking of plans, every organization has some amount of politics. Sometimes, politics lead to healthy negotiation and compromising. Other times, they lead to unreasonable demands and blaming. The project manager should deal with these politics, letting the team know what's important and shielding them from what isn't.
The project manager can also help team members do fulfilling work by pushing back 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.
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. Like energized work, you can't force jelling, but you can encourage it; many of XP's practices do so. The classic work on this subject, [DeMarco & Lister 1999]'s Peopleware, is well worth reading.
Stop when you're making more mistakes than progress.
When you're making 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.
Sometimes a snack or walk around the building 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.
You can usually tell when somebody needs a break. Angry concentration, cursing at the computer, and abrupt movements are all signs. In a highly collaborative environment, going dark—not talking—can also be a sign that someone needs a break. When I notice a pair of 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 him to stop working. Otherwise, get him away from the problem for a minute so he can clear his head. Try asking him to help you for a moment, or to take a short walk with you to discuss some issue you're facing.
What if I'm not ready to check in my code and it's time to go home?
If you're practicing test-driven development and continuous integration, your code should be ready to check in every few minutes. If you're struggling with a problem and can't check in, go home anyway. Often the answer will be obvious in the morning.
Some teams revert (delete) code that doesn't pass all of its tests at the end of the day. This sounds harsh, but it's a good idea: if you can't easily check in, you've gone far off track. You'll do better work in the morning. If you're practicing continuous integration well, the loss of code will be minimal and you'll still have learned from the experience.
I work in a startup and 40 hours just isn't enough. Can I work longer hours?
If you dread going to work in the morning, you aren't energized.
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 judgment 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?
A sprint to the finish line might boost your energy. 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 can help the team jell, giving it a sense of accomplishing something in important in the face of adversity. However...
Extended overtime will not solve your schedule problems.
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. DeMarco calls extended overtime "an important productivity-reduction technique," leading to reduced 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 (whatever "overtime" means in your situation), don't work overtime again the next week. If I see a team sprinting more than once or twice per quarter, I look for deeper problems.
When your team is energized, there's a sense of excitement and camaraderie. As a group, you pay attention to detail and look for opportunities to improve your work habits. You make consistent progress every week and feel able to maintain that progress indefinitely. You value health over short-term progress and feel productive and successful.
Energized work is not an excuse to goof off. Generate trust by putting in a fair day's work.
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.
If your organization makes energized work difficult, mistakes are more likely. Pair programming could help tired programmers stay focused and catch each other's errors. Additional testing may be necessary to find the extra defects. If you can, add additional contingency time to your release plan for fixing them.
The extreme form of this sort of organization is the death march organization, which requires (or "strongly encourages") employees to work extensive overtime week after week. Sadly, "Death march projects are the norm, not the exception." [Yourdon] (p. ix).
To add insult to injury, [DeMarco & Lister 2003] (p. 161) weighs in: "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 with value so minuscule, 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?"
Peopleware [DeMarco & Lister 1999] 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 [McConnell 1996] has a chapter on "Motivation" with a nice chart comparing programmer motivations to the motivations of managers and the general population.
Slack [DeMarco 2002] looks at the effects of extended overtime and overscheduling.
Death March [Yourdon] describes how to survive a "death march" project.