In the book Switch: How to Change Things When Change Is Hard by Chip Heath & Dan Heath, the authors described the results of a study to answer the question: Would people with bigger popcorn buckets eat more at the movie cinema?
As part of the study, it was carefully engineered to serve the popcorn five days stale. Some people received medium sized buckets and others got a large bucket. The results were stunning:
People with the large buckets ate 53 percent more popcorn than people with the medium size. That’s the equivalent of 173 more calories and approximately 21 extra hand-dips into the bucket.
The book further states that other popcorn studies were always the same:
It didn’t matter if our moviegoers were in Pennsylvania, Illinois, or Iowa, and it didn’t matter what kind of movie was showing; all of our popcorn studies led to the same conclusion. People eat more when you give them a bigger container.”
No other theory explains the behavior. These people weren’t eating for pleasure. (The popcorn was so stale it squeaked!) They weren’t driven by a desire to finish their portion. (Both buckets were too big to finish.) It didn’t matter whether they were hungry or full. The equation is unyielding: Bigger container = more eating.
Recently in To Change Culture, Change the System David Joyce says:
Deming learned it’s not a problem of the people it’s a problem of the system that people work within. He found that if you want to change behaviour, then you need to change the system, and change management thinking that creates it. Doing so, culture change is then free.
To change someone’s behaviour, you’ve got to change that person’s situation.
Agile welcomes changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Short feedback loops in Agile allow the team to get fast feedback and incorporate changes required by the customer and reduce the possibility of the team developing the wrong product for too long.
The Product Backlog is dynamic and evolves over the lifetime of the product and requires constant grooming and refinement. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.
During an iteration, the Agile Team should invest some time to work with the Product Owner to refine the Product Backlog (a.k.a. Product Backlog Grooming). This includes requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. Priorities can change and requirements can move up and down in the Product Backlog. When new items are discovered, they are inserted into the Product Backlog causing the lower ones to move down the list (and possibly fall outside of the scope of the release) or old requirements removed as appropriate.
Although Agile welcomes changes, when using time-boxed delivery like Scrum, there are no changes allowed during the iteration, and the end date of the iteration does not change. In return for not making changes during the current iteration, the Product Owner can make any changes they want to the Product Backlog before the start of the *next* iteration. The Product Owner can add, remove, reorder, or change items before the start of the next iteration. This enables the Agile team to make and keep commitments, it gives the team focus and stability during the iteration, and it trains the Product Owner to clearly think through what is in the Product Backlog. Due to the short time-boxes, the team should be able to get some reasonable certainty into the planning and requirements and avoid churning during an iteration.
Overtime if you find that the Product Owner keeps needing to change requirements mid-iteration, then perhaps the iteration length is not short enough. Plan iteration durations around how long you can commit to keeping change out of the iteration.