Imagine you are participating in a marathon. For most of the race you maintain a steady pace, conserving energy and stamina for the last leg when you push for the finish line. What if you were expected to run the entire race like you were running a 100 meter sprint? Not only would it be impossible to maintain that speed throughout, you are likely to suffer burnout and might end up quitting the race halfway. Even though Agile projects are split into iterations or “sprints,” that does not mean they are similar to sprint races in which how fast you are determines whether you win or lose.
Agile projects run in a fast-paced environment where everything is time-boxed and change requests are the norm. Just when you think that you are about to complete an iteration, the customer will want to include new features or suggest changes to ones that have already been completed. Expectations of stakeholders run high on Agile projects and they can end up confusing quick delivery with efficiency and quantity for quality; thus leading to unrealistic expectations. Agile teams realize that the iteration they are finishing is just one lap in the whole race. An entire relay in not run in just one leg. To finish the entire race, the Agile team must develop realistic expectations.
If we want to be successful on Agile projects, we need to provide results consistently at a rate that we can sustain. This does not mean we decide to work at a slow pace, but we need to perform at an optimum rate during which we can deliver value and at the same time be motivated to continue doing so for long periods of time.
[JP1] Working longer hours does not necessarily ensure that more work gets done. Writing for CNN in late 2012, Robert Pozen, author of Extreme Productivity: Boost Your Results, Reduce Your Hours, asserted, “Long hours at work wear people down mentally. All too often, I see professionals work to 8, 9, or 10 every night and go into the office every day of every weekend, even if there is no real crisis. While these professionals might be increasing their output over the short-term, this type of overwork inevitably leads to burnout. And if you’re burned out, you’re not productive.” Numerous experts have noted that a person’s efficacy drops if he or she works longer than 40 hours a week. When stretched beyond this, workers are prone to making errors and producing output of poor quality. Rectifying errors and reworking to improve quality require additional time and resources, thus costing the organization financially and frustrating the custmoer. When long work hours are made mandatory, team members can become disheartened and ease off.
Overtime is sometimes inevitable on a project, but it is important that overtime is scheduled to limit negative impacts on the productivity of the team. For example, some experts suggest that team members should not work 50+ hours per week for more than two weeks in a row.
One of the reasons Agile and Scrum stresses that team members come up with estimates themselves rather than managers or customers, is that since team members are the ones who actually develop, they can more accurately do the estimating. Managers or product owners, on the other hand, might not be aware of the nuances of the work that needs to be done and therefore set unrealistic targets. For most managers, allowing teams to set their own pace can be difficult, and that is why trust between all stakeholders is a key requirement to make Agile projects work successfully.
Every team must determine the pace that they can sustain and at which they can provide high quality output. Wisely paced sprints in the short run combine to conquer the marathon in the long run.
Other Must Read Posts
