Management commits real money to support a development team and expects real commitments from the team in return. In fact, if management wants the benefits of an Agile team, they need to commit to more than just budget (see “10 True Commitments Agile Teams Need from Management”). But what sort of commitments should management expect from an Agile team? Unfortunately, managers and business stakeholders still generally demand that teams deliver “fixed-scope milestones by specific dates” and have great difficulty grasping why such commitments are invariably unrealistic and self-destructive.
Instead, to lead teams to reliably produce real value, management should expect Agile teams to make the following commitments to themselves as well as to their management and stakeholders. Given that management has made good on all their commitments, the team can reasonably make these true commitments as well, not the cheats described below that we too often see.
1. Deliver and Deploy Frequently
Deliver working software updates every sprint and deploy into production frequently (every 2-3 sprints). Beginning teams may need a little ramp up interval, but neither validation nor value occurs until software works and is in operation. Note that the promised dates are firm but the scope of each delivery will “flex” as needed to meet the date despite contingencies.
Cheat: A delivery is made, but doesn’t really meet the agreed upon Definition of Done. The production release was “ready” but didn’t actually happen on the promised date because earlier pre-release deployments weren’t realistic enough to reveal all the procedural issues, logistical issues, conflicting events, etc.
2. Done by Definition
Assert items are done only when meeting Definition of Done (DoD) criteria.
Cheat: “Done” with coding and maybe unit testing but not actually integrated, peer-reviewed, fully tested, corrected to address known bugs, or other agreed upon criteria. The release “works for us,” but is not actually compatible with aspects of the current production environment.
3. Produce Quality
Act to minimize the risk of poor quality and actually deliver.
Cheat: We haven’t seen many bugs yet so we’re not worried about them–of course, we haven’t spent much time testing because we’re too busy cranking out features. Code coverage for automated tests is poor, and the few tests we do conduct are cursory. We don’t discuss design, pair program, or otherwise peer review. As long as it builds and seems to be working, we just keep on coding.
4. Swarm to Priority
Discuss the best order to work stories within the sprint and reinforce or adjust those priorities during standups. Work the Sprint Board “from right to left,” collectively focusing on finishing open stories before starting another.
Cheat: That task you need help with is not really my forte, it will be more efficient if I get the next story started instead. These three particular stories all involve some of the same code modules—best if I do all three simultaneously so I “don’t have to open the patient more than once.” In fact, it’s confusing coordinating multiple people on one story, let’s all just work on our own separate stories.
5. Honestly and Capably Advise
Provide good-faith assessments of story cost and risk to the Product Owner; constructively critique backlog priorities and individual stories; propose further story splitting (or combining) where it makes sense. Fairly measure and represent team performance and capability.
Cheat: Plan to achieve your full velocity in new stories regardless of what bugs you also plan to fix, or how much coordination you need to have with other groups. Don’t account for backlog grooming, and in fact, minimize effort on grooming by only having 1 or 2 team members participate.
6. Practice to Standard, with Intention
Negotiate with management and other project stakeholders the bounds of reasonable Agile practice in your organization. As needed, earn trust for greater autonomy by practicing within those guidelines, executing each practice to achieve its expected intent.
Cheat: We can check off on every practice, so we’re compliant. For that matter, the Agile Manifesto says the team should have autonomy so we should just make our own rules because we’re Agile.
7. Diligently Strive to Improve
Match your organization’s practice standard, then improve on it, your product, and your team’s performance. Take appropriate measurements, analyze root causes of problems, invest team capacity in accomplishing improvement actions, and honestly evaluate the results.
Cheat: Spend your efforts hashing over organizational constraints rather than identifying and implementing improvements. Declare improvements by acclamation without including necessary actions in the sprint backlog. Don’t review the results at the next retrospective. Avoid all measurements, and hide any that you do collect.
8. Dedicate to a Sprint Goal
Negotiate reasonable goals in good faith, attend to the goal throughout sprint, and act consistently with the expectation of achieving those goals (see “Sprint Commitments”).
Cheat: Because we only “forecast” in Scrum, if we keep missing our sprint goal—no problem—we just roll unfinished stories over to the next sprint. That way we don’t stress out thinking too much about requirement or design issues during backlog grooming or sprint planning. Also, we gauge improvements by “how they feel” since velocity flails about randomly.