muddy the waters (sometimes on purpose) to leave themselves room to maneuver later. Alert: Team members, if you do not get anything else out of this three part series, understand this. Sometimes, Product Owners will intentionally leave acceptance criteria vague so that they can maneuver within the sprint review meeting. This can get really tricky if your Product Owner is also your boss. Do you call them out on it? What happens if you do? What happens if you don't? It's really safe to assume that most Product Owners are just more skilled at negotiating than most team members. We see this all the time with our politicians. Most politicians would say that we're winning the war on drugs, but fail to answer questions about what their acceptance criteria for success really are.
Empowerment and Productivity
And though both the Product Owner and ScrumMaster help facilitate productivity for the team, what truly empowers Scrum teams to outperform traditional teams is self-organization. The fact is when individuals are vested with more responsibility, they almost always respond by rising to meet the challenge. In Colleen Frye's recent article in Tech Target, "How Teams Transition to Agile Development Methodologies," the author concludes that all of the organizations interviewed for the story had undergone Scrum transformations observed the same result: self-management leads to ownership. Intuit's Basab Dattaray, an engineering manager for the Turbo Tax group who was interviewed for the article, explains, "With Scrum, team members take responsibility and ownership...We don't have anyone hounding people." When team members rely on one another to deliver their share of the work, it yields team members who are engaged in their work and willing to take ownership of the problems they face. When a team is full of such inspired team members, productivity is nearly assured.
However, Scrum's unique potential for productivity occurs over time, as a team has a chance to establish a rhythm and gradually improve itself. Key to this is the retrospective meeting, which occurs at the end of each sprint. When a sprint concludes, the team and the ScrumMaster get together to assess the previous work cadence and discuss what went well, what didn't, and what could be improved for next time. This is an informal and candid opportunity for the team to evaluate its own performance-often without the Product Owner present-and adapt its processes for improvement. The team can enter a state of flow, sometimes called the ‘zone' in sporting events.
Now, any team that worked together over time would naturally develop camaraderie among its members and function at a higher level than, say, a newly formed team. However, retrospective meetings, Scrum's mechanism for incremental team improvement, provide teams with a dedicated time to focus on how it can do its job better. By keeping performance at the front of the team members' minds, Scrum's iterative and incremental lifecycle encourages teams to evolve. Just as features are added to products every sprint, a team accrues skills and experience as its members learn how to best work together. Scrum uses its own metric, called velocity, to gauge how many story points a team can accomplish within a given sprint. The best Scrum teams-those that evolve to perform at higher levels-can demonstrate their increased thresholds for productivity through a velocity that steadily climbs over time.
In addition to the "definition of done" pitfall outlined above, there are numerous other anti-patterns of which teams should be wary. Although Scrum provides team members with the freedom to choose how they do work (my teams do work on things as they see fit. Very rarely do