Work at a Sustainable Pace

Too often, teams feel pressure from someone outside the team to “do more!” That’s often accompanied by the depressing “with less!” I don’t know of a way to do more with less. I understand how to do less with less. Much of that less is thinking.

I said at the beginning of the chapter we should optimize for reading the code, since team members tend to read a lot more code (and tests) than they write. Why? Because people are looking to see if someone has already done this thing somewhere. Or this piece of functionality looks more like an octopus, with tentacles dangling into multiple places in the code or tests.

When people read code, they think. When people discuss what to do in the form of a small story and how to do it in the form of design, they are also thinking. Sometimes they think collaboratively with other people when they define stories or acceptance criteria. Sometimes they think alone. However, they think.

Software development—in fact, most of knowledge work—is about the thinking ability of the people developing the product. That means the people need space and time to think.

Some people can manage being inside a team room and still think. Some people can’t think there—they need a private place to think. For me, even more important than having space to think is having time.

When managers or product owners pressure a team to deliver instead of think, the team creates defects. We see this effect when we multitask. We see this effect when people take shortcuts when they shouldn’t. Artificial deadlines don’t make it easy for people to deliver.

Small stories make it easy to deliver. If you need high-quality code, the technical practices, especially around review and testing, make it easy to deliver. Pressure does not.

I have never seen teams deliver under sustained pressure. I have seen teams deliver with very brief pressure, a break, and then back to normal time at work. That means if you want sustained delivery of features, you should create a project that has a sustainable pace. People work together for a six-to-eight-hour day, five days a week. Some teams understand how to do ten-hour days. Some teams actually take time off in the summer, working four eight-hour days.^[17]

If your team pairs or mobs, they will be exhausted at the end of somewhere around six to seven hours a day. They have finished what they can. Encourage them to go home and recharge.

I have seen many teams improve their throughput when they stopped working overtime. (I wrote about those circumstances in Manage It! [Rot07].) I have seen too many teams, agile or otherwise, lose momentum and create problems for themselves when they pushed to work more hours than they could sustain. If you want your team members to do “more,” make sure they aren’t spending time in unnecessary meetings, that they aren’t multitasking, that they work on the highest-value work, and that the work is small.