Are you Agile or Chaotic
lessons
Flexibility is good
Resistance to distraction is good
Balance between the two is best
Occasionally I’m presented with a situation in which a stakeholder (usually the Product Owner) comes to the team mid-iteration and wants to change the design or the scope of a User Story the team is working on. When the team rejects the changes and opts to put them into a separate User Story to be prioritized and committed to later, the stakeholder will often say something to the effect of, “As an Agile Team, shouldn’t you be flexible to changes?”
When I heard this statement for the first time I was conflicted, because at the surface it seems like a reasonable argument, but I knew these changes were disruptive to the team’s productivity. The answer to that question is inherently yes, as an Agile Team, we should be flexible to changes.
However, the term “flexible” implies that it is not altogether formless and at some point, there is some resistance to the pressure being applied. A rubber band is flexible, not formless, and at some point it begins to resist the pressure being applied to it. If that pressure is perpetually increased, at some point its flexibility is overwhelmed and the rubber band breaks. If the rubber band was formless, never gave resistance, and constantly succumbed to the pressure, it would be a useless tool and wouldn’t get anything done.
Like a rubber band, if an Agile Team were to never resist pressures such as changing design or scope, it would have a tough time getting very much done. Also, once the team applies resistance, if pressure is perpetually increased, the team will break or enter chaos. Changes are welcome and encouraged; chaos is not. To accuse a team of not being Agile if they resist disruption would be misguided. The flexibility of an Agile Team lies in short iterations, cross-functionality, and product owner ownership of the backlog.
Short Iterations
Arguably the most valuable part of Agile is the encouragement of frequent feedback and quick pivots. Inspecting and adapting allows organizations to quickly adjust to a changing industry and shifting priorities. In the age of an insatiable desire for the “next thing,” it is vital for organizations to be able to pivot their products and iterate quickly to stay competitive. This is a driving force of Agile.
Organizations that are truly Agile, and their customers, don’t need to wait very long for the “next thing.” Depending on the framework, that could be as often as multiple times a day, and usually isn’t longer than 2–3 weeks. Even the frequency of delivery is flexible; so if the business requires more frequent iterations to stay competitive, that might be a viable option as well.
Cross-functionality
The concept of having a cross-functional team allows for a lot of flexibility in the types of commitments an Agile Team takes into an iteration. If a team is comprised of people with one skill set, that severely limits the variety of work they can accept and thus inherently limits their flexibility. The product owner will need to spend much more time planning the order and priority of user stories on the product backlog, because work outside of that skill set will take much longer for the team to deliver.
A cross-functional team can easily adapt to any variety of product backlog. Thus, planning road maps for the product and changing the priority of user stories at the last minute is significantly easier on the product owner and team.
Product Owner Ownership of the Backlogs
Because the product owner owns the backlogs, that person is free to choose to prioritize the user stories in any order. This is a lot of flexibility and is a huge improvement over more traditional approaches.
Ultimately, because of this ownership, it is OK for them to change some priorities within an iteration, and even pull in a user story or two. If this happens, however, it is the team’s responsibility to recommit to that iteration. That means that while the product owner can add user stories to the iteration, the team may drop out other user stories as a result. Therein lies the check-and-balance characteristic of a truly Agile organization.
In short, it is permissible to adjust which user stories are in an iteration, but it is not OK to change the design or scope of a user story that is already underway. The reason being that it quickly becomes overwhelmingly difficult for the team to keep track of the changes, particularly what and how to test the user story. I have seen this happen numerous times, and it risks the integrity of the product, potentially leading to serious problems down the road.
In certain situations, it might make sense for the product owner to abandon the feature altogether because priorities have changed so drastically or the feature has become irrelevant. That, of course, would imply that the changes would have been so large that they were unacceptable anyway.
In conclusion, if you’re a stakeholder, allow the team to occasionally resist and do not cause chaos. If you’re part of a team, resist changes to design or scope of a user story mid-iteration, but also explain to the stakeholder why you are resisting. Most things run more smoothly when there is open communication and compromise from both sides.
Lead Happy!