The Benefits of Limits

June 10, 2011

I can see it coming. As I walk by the open area with white-board paint on the walls and desks designed for pairing, I see everyone concentrating intently at their desks, some with headphones on. People are working hard, yet there is something wrong.

The sprint ends with far less than expected velocity.

A common way that teams get into trouble is that they try to put too much work in flight at any one time and the task board morphs into “swim lanes” where people are working feverishly, but independently. The result is a race to see if the “team” will accomplish its work by the end of the sprint. This can lead to a BIG disappointment, with a lot started, but little to nothing completed.

People want to do a good job (I don’t know people who show up to work every day with the mindset of doing a poor job) and teams – particularly teams new to Agile – make the mistake of thinking that in order to meet their sprint commitments, they need to start all of the items immediately.

The problem is that software development is a complex undertaking. And while some things that the team has committed to are likely to be easy, it’s a good bet at least some items have complexity to them that would benefit from knowledge-sharing and collaboration.

Limit WIP
Limiting work in progress (WIP) focuses the team’s attention on the highest-priority items and improves productivity because it creates a situation that fosters collaboration. And complex problems are best solved through collaboration.

People will instinctively assert that, “Everyone can’t work on one task,” and they are right. However, the experience of our teams demonstrates that there is usually a greater opportunity for collaboration than anyone initially thought. Explore the possibility before dismissing it out of hand.

As a manager, I’ve pushed back on teams when an “impediment” has been raised to me when I’ve observed a lack of collaboration. I had one team ask for a consultant to help them overcome an issue, but I asked the team for a few hours of true collaboration before agreeing. (There was some back-and-forth involved with this, and I was not perceived as the “good guy” by refusing to take an issue off of the team’s shoulders.)

Within two hours of collaborating the issue was resolved! Not only that, the team members had some delighted looks on their faces, which made it worthwhile to me in the end. I had full confidence that they could overcome this obstacle without a consultant, and this was one case where the team needed a manager to stand firm in order for them to take true team ownership of the problem.

Collaboration boosts productivity. But how do you foster greater collaboration?

The obvious way is for teams to discipline themselves to limit their work in progress, as discussed above. This takes discipline on the part of teams, and it does leave the door open to slips because there is still work that teams commit to accomplishing on the board, tempting them to start too much. The team should agree to limit WIP and make it a part of their working agreement that they all monitor and call themselves on.

Limit Sprint Length
A great way to foster collaboration is to reduce the length of the team’s sprint. The shorter sprint length means that a team is automatically limited to the number of user stories it can possibly take on (a by-product of limiting sprint length is reducing WIP as someone pointed in our recent Agile User Group here in Portland). If the team wants to improve its velocity, they will need to find ways to complete their work faster – through technical practices and collaboration.

Shortening sprint lengths have another benefit: it tightens up your act. The Product Owner needs to work with the team to define small, crisp features. The shorter the sprint, the smaller and crisper these features need to be.

And the team won’t have certain luxuries, either. Sometimes – even with two-week sprints – people flounder. They wrestle with problems longer than they should, and they place work at risk because they don’t ask for help. A natural tendency in the first few days of a two-week sprint is to think that, “We’ll have plenty of time to make up ground.” The shorter the sprint, the less likely this type of thinking will creep in.

I will say that it takes time for teams to gravitate towards shorter sprints. When we first started Agile development, three-week sprints were considered short, and most teams couldn’t see how they could possibly get any work accomplished with anything less than four-week sprints. Now two-week sprints are the norm, and all of our teams have used one-week sprints quite successfully at one time or another – with one team using one-week sprints as their norm. Although we’re not quite there using one-week sprints as our new norm across the board, I’m confident that this will come to pass.

Limit Overtime
Using overtime as a mechanism to deal with software project schedule issues creates far more problems than it solves, period. There are long-term risks that include burnout, turnover, and overall sustainability along with some short-term effects that are worth noting.

Research has shown that when people work more than 55 hours in a week, they experience problems with memory, reading and comprehension. A study on the impact of overtime on software development demonstrates that defect rates drop dramatically when no overtime is used.

Limit Multi-Tasking
Actually, eliminating multi-tasking is the more desirable option. In his book Quality Software Management: Systems Thinking, Gerald Weinberg notes that you lose 20 percent of your time switching between just two projects.

The case against muulti-tasking is supported by other studies written about in a Wall Street Journal article, New Studies Show Pitfalls Of Doing Too Much at Once. One study in the Journal of Experimental Psychology points out that people who multitask are less efficient than those who focus on one project at a time, because the brain has to overcome "inhibitions" it imposed on itself to stop doing the first task in order to take on another tasks.

There are times when task-switching is a good thing. There are studies that demonstrate that people need to mental break to get their concentration back. A short break doing some web surfing can make you a happy, productive employee. Task-switching in this respect is a good thing.

Shameless self-promotion (as a teacher I had in college was fond of saying, “It’s my chalk and my board!”): I recently published an article on titled The Unintended Consequences of Common Productivity Tactics that talks about overtime, multi-tasking and the importance of rest. Take a look at it and tell what you think!

The message is simple: setting the right limits will boost productivity.


Nice thoughts on a common problem, how to get people to truly collaborate. I call the behavior we wish to see "swarming" - like bees to the fresh flowers of the day. It is a collective behavior we are after, not for the actual behavior - but the results we have experience that it results in. Better outcomes from group/team behavior.

June 19, 2011 at 3:36 PM
Dave Moran said...

@Dave Koontz,

Nice call! We've called it swarming as well. And for those complex, difficult problems, good things happen when swarming takes place, no question.

June 20, 2011 at 5:53 AM

Post a Comment