For those who aren't familiar with decision fatigue, it’s a condition where your ability to make decisions deteriorates with the number of decisions you make after a rest period (think nightly sleep). One of the most iconic counters to decision fatigue was Steve Jobs' seldom changing wardrobe. The number of decisions we make in a day is really staggering. And the impact of making the wrong one can vary from insignificant ("Should I wear the sand chinos or the tan chinos today?") to traumatic ("Can I make the crossing before the train gets here?").
Consider a typical commute in the metropolitan area where I work; I encounter 36 miles of traffic, sharing the road with both experienced, rational, licensed, insured and kind drivers, as well as drivers who meet none of those criteria. Should I speed up? Slow down? Yield? Take the right of way? Sam Rayburn Tollway or PGB? I literally make thousands of decisions (including which Sirius station to listen to) in those 36 miles, and that is all before I get to work!
One of the greatest practical (and immediate) benefits of starting your Agile Transformation by implementing Scrum is the reduction in the number of decisions that you need to make:
- Should I go to the next update meeting? (daily Scrum, all development team members are there every day)
- When should we get everyone together for a check point? (Sprint review)
- Should I ask Sally to help me? (development team member)
- Who can decide how that looks? (product owner)
- When should we have our next planning meeting? (Sprint Day 1, The Sprint Planning Session)
While the "tight" deadlines (more about that in a moment) can initially cause some team members stress, the predictability of the Scrum event cadence ought to remove a significant number of decisions (and the accompanying fatigue).
Applying Extreme Programming (XP) engineering practices to your Scrum implementation can reduce decision fatigue even further:
- Should I test this? (test driven development)
- Is now when I need to get a second pair of eyes on this? (pair programming)
- When should I merge my code? (Continuous Integration)
All of these reductions in decision fatigue create the conditions for team members to make better decisions throughout the day, certainly for their products, but more importantly, to their interactions with each other. The sum of these better decisions are one of the seldom discussed benefits of applying Scrum.
Backing up for moment to the "tight" deadlines stressor, when teams feel the Scrum deadlines are tight, it is a clear signal the organization has not mastered both self-organizing teams and breaking work down. When teams feel pressure to meet features on specific dates the organization might be more focused on "doing" vs. "being" Agile.
What about the common occurrence when a team starting Scrum isn't feeling relief from decision fatigue? And maybe is experiencing even more fatigue? The organization needs look at providing training and coaching throughout the adoption. This coaching should include a review of the "Shu-Ha-Ri" concept. In the adoption part of the transformation, the teams need to be focused on "Shu," doing Scrum with little adaptation. As teams focus on mastering (rather than re-inventing) Scrum the decisions should be contained and reduced. An experienced agile coach can guide a team through Shu-Ha-Ri in order to help them defer the need to inspect and adapt until they have mastered a technique or practice.
One of the great competitive advantages of being Agile is that we gain benefits we didn't plan or anticipate. Relief from decision fatigue is an important, and often overlooked, unanticipated benefit from being Agile using Scrum.
Here is some additional information: Decision Fatigue: Wikipedia and Yes, No, Maybe So: Defeating Decision Fatigue. Do you have questions about Scrum and decision fatigue? We'd be happy to answer them: email@example.com.