Fixing to get flexible

When adopting scrum, one of the more subtly difficult issues that can arise, derives from the varying expectations generated by the word agile. Customers who are used to long lead times and cumbersome procedures are delighted at the prospect of 'going agile' – they will get to call the shots and there will be no penalty for change. This lightweight interpretation of agile, inspired by a craving for flexibility, can cause problems when customers decide mid-sprint that they need something new, tomorrow.

When faced with the situation outlined above, the scrum master will of course state that the customer needs to talk to the PO and that, in all likelihood, (some portion of) the new functionality will be delivered no earlier than at the end of the next sprint (which could be up to 4 weeks hence!). The customer's response will often range from disappointment to disillusion; what's so agile about that?

Or, what to do as freshly minted scrum master when the sprint ends and the last story or two (!) on the sprint backlog are not done? The freshly minted PO, who is also still learning, and his customer base are pushing hard for an extension to the sprint – surely adding a day or two to the sprint is better than delaying delivery of the story in question for (at least) another whole sprint; where is the agility in (such) strict time-boxing?

Management might also react negatively when it transpires that agility does not involve people hopping nimbly from one team to the other as the (perceived) need arises. How to ensure efficient use of resources; what's so agile about all this rigidity?

So, how should a scrum master explain to his or her environment that a measure of intransigence is in fact conducive to flexibility?

They might point out that four weeks is still significantly shorter than 12 or 26 weeks but I wouldn't recommend it.

They could delve into the theory of complex adaptive systems and explain how scrum is an astutely chosen set of boundaries (constraints; time-boxes, rules etc) imposed on the behaviour of a complex adaptive system (team) catalysed by the probe of certain types of information (user stories, feedback).

Or they could point out that scrum's basic measure of progress and unit of prediction, velocity, requires fixed sprint length and fixed team composition to have any meaning.

Otherwise they might pontificate on the magic of cadence and appeal to their listeners' sense of (universal) rhythm. Or they could point out that if the team does not have to constantly busy itself with a fluid agenda that they can concentrate on what really matters; delivering working software that the customer actually wants with astonishing regularity.

For the PO, whose time is also usually at a premium, stable sprint configuration means that he or she knows months in advance what possible delivery dates are, but also when they need to be in the office as planning meetings, grooming sessions and reviews take place in the same locale, at the same time & for the same duration and on the same day of the week, sprint in, sprint out.

If all else fails, a story might help; it is often said that Einstein's wardrobe was filled with identical suits because he felt that (mental) energy expended on deciding what to wear was energy wasted. As with much of the myth of Einstein it is difficult to establish the veracity of this anecdote but recent research indicates that decision fatigue is indeed a force to be reckoned with. Developers, scrum masters, POs, line managers and customers will surely all agree that a team's (decision) energy quotient is far better spent on coding questions than on deliberations as to the best time for this week's grooming session.