This question seems like it has been surfacing more lately, perhaps because agile (Scrum) adoptions are increasing. This happens to involve one of those timeless qualities of an agile organization: continuous improvement.
Asking a team what it means for them to be agile and guiding them back to the Agile Manifesto is helpful in these situations. As one of the principles states: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
The wording of this principle clearly states “At regular intervals.” Regular does not mean irregular, for a reason. With agile, we want to establish a cadence in everything that we do. The goal is to create tight feedback loops to learn from, whether those loops concern learning about design and quality of the software being built, business functionality, or team effectiveness.
It is always best to perform a retrospective when information is fresh in peoples’ minds. Important details will be forgotten the further removed people become from what they are reflecting on.
Equally important, learning loops should be as small as possible to accelerate and amplify learning. When it comes to increasing the effectiveness of the team, this doesn’t imply that a team needs to make big changes every Sprint; the cumulative effect of many small changes can have a big impact.
The retrospective is an opportunity for the team to stop, reflect and learn. It is a key mechanism designed into Scrum to support continuous improvement, a difficult concept to implement in actual practice for many non-agile organizations. Improvement in non-agile settings comes in fits and starts, generally showing up as centrally-mandated practices and added to an already bloated development process designed to cover any and all scenarios.
Aren’t autonomous teams in control of their work? Isn’t agile about respecting people and teams?
The answer to both questions is, “Yes,” but we can’t apply them out of context. If we ignore some values or principles of the Agile Manifesto, then we’re being selectively agile, not fully agile. And we’re playing with fire.
Continuous improvement is an important component of the agile value proposition. With agile, we want to approach work in different ways. We’re looking to strip away the nonessential overhead while retaining a simple, direct, effective approach to work that involves combining traditional tasks and functions to accelerate delivery – with quality. If we want to eliminate that overhead that most organizations believe is necessary (today), we need something to balance their concerns.
Continuous improvement via retrospectives provides the assurance that agile teams are concerned with their productivity and effectiveness. Retrospectives balance concerns about agile and provide the means by which agile implementations increase effectiveness over existing approaches – which is what we need to demonstrate. Otherwise all we’re doing is changing, not improving. With autonomy comes responsibility.
This is where respect comes into play. In an agile context respect isn’t about being nice. It’s about providing people the opportunity to grow and develop so that they can reach their full potential. It’s about using respectful inquiry, systems thinking and mental models to explore and improve as individuals, teams, and an organization as a whole.
This is not easy! We’re asking people to change mindsets and behaviors, to implement new practices and cross traditional functional roles and boundaries. People need the space to experiment and reflect on the new experiences that these experiments provide so that they evolve as an agile individual and teammate.
Skip the retrospective at your own peril.
Dev Lunch as a Power Tool
6 hours ago