Embedded Files
First published on Scrum.org, 13 December 2017 (syndicated).
"See it all. See it fairly. Be truthful, be sensible and be careful with language" - Henry GrunwaldIn Scrum we care about the precise and considered use of language, since any obfuscation reduces transparency. When we try to implement Scrum, we can sometimes find that the pressure is on to change Scrum terms and their meaning, so that change may be "configured" or "customized" to fit the organization. Scrum terms of reference can become bent and twisted around those existing contours, and the way we even think about agile change can be tugged at and constrained by organizational gravity. The result of acquiescing to such pressure is that little change may actually happen, and there is surprise and disappointment amongst stakeholders when the expected benefits do not materialize.
We are nevertheless subject to those forces of organizational gravity, and no matter how rigorous or careful we try to be, we cannot entirely insulate ourselves from its effects. An important discipline we must therefore learn is to exert small corrections, early and often, before they build up and we face a crash. Here are twenty small things which you might be tempted to say or to silently agree with, and which are perhaps rather better to avoid.
Avoid describing a Sprint Backlog as a “commitment”. It’s a “plan” or “forecast” of work for meeting a Sprint Goal. Use those words instead. Remember that team members ought to commit to goals, not to forecasts.
Avoid language which suggests Story Points are “delivered”, or in some way constitute value or otherwise proxy for value. The purpose of story pointing is to help a team forecast how much work it believes it can take on. In agile practice, value is only to be found in the delivered increment itself.
Avoid talking about an “ideal velocity” when making forecasts. Instead, talk about the ideal value which can be released in current and future Sprints. Remember that an agile team does not consist of story point accountants. Speak of the work done in terms of innovation accounting instead.
Avoid talking about “Sprint Goals” when those supposed goals have not yet been planned and agreed by the team. If they are tentative Sprint Goals, call them that. During refinement, discuss how well they might align to features and Minimum Viable Products.
Avoid describing stages of work as “Sprints” unless they are time-boxed and produce an increment of functionality, however small it may be. “Special” sprints like “sprint zero”, “integration sprint”, “testing sprint” and so on are coded terms for stages or phases. If stages or phases are to be used, call them so honestly, and avoid devaluing agile terms of reference.
Avoid describing a Sprint Review as a “Show and Tell” or “Demo”. A demonstration of work might very well form part of a Sprint Review. However, the essential purpose is to consider the work which has been done and which remains to be done, and to inspect and adapt the Product Backlog.
Avoid talking about a “Kanban” unless there is evidence of a closed economy of work. If there is merely evidence of a “to-do” list, call it that.
Avoid describing Acceptance Criteria as the “Definition of Done”. They may represent a certain level of “Done” for certain Product Backlog items, but the Definition of Done, as an assertion of release quality, properly refers to the entire increment.
Avoid referring to a collection of people as a “team” unless there is evidence of their collaboration and teamwork. If those people are working in silos which are largely independent of each other, then there may instead be evidence of a “workgroup” engaged in craft production.
Avoid referring to an agile initiative in terms of its supporting tools. Achieving agile practice is not the same thing as “having Jira” or “using TFS” or indeed any other technology.
Avoid talking about "DevOps" as though it were distinct from agile practice and cultural change. If you are referring to technical practices such as automation or continuous integration and deployment, use those terms instead.
Avoid talking about “technical debt” when there is no plan to pay the accrued deficit back, or the liability incurred thus far is unmanaged and unknown. If they are in truth unquantified losses, call them that.
Avoid talking about a “Release Plan” if certain Sprints are not planned to result in a release at all. What you actually have is a plan for not releasing. In Scrum, each Sprint must yield an increment of value however small it may be. The decision to release or not to release ought to be made on a Just in Time basis. A true Release Plan should outline what is likely to be delivered, to whom and when...not if a release will happen.
Avoid talking about “bugs” or “defects” as if they are separate from other work which remains to be done. They must still be accounted for as work remaining, and planned and budgeted for. The urgency of the repair and the speed with which it is expedited does not obviate the need for this quality of transparency.
Avoid talking about “fixed scope” when a Product Backlog is subject to ongoing refinement, and distinct options might yet emerge. Instead, talk about each Sprint as the opportunity to deliver something of value from which useful things can be learned.
Avoid language such as “push to test” which suggests that anything other than a pull-driven flow of work is expected. Agile and lean practice is founded on pull, including the timely and efficient handling of work in response to clear demand signals.
Avoid referring to “distributed” teams. A team which is not co-located is a dislocated team. Call it that, and be transparent and open about the challenges and inefficiencies concerning teamwork which are likely to arise from such a model.
Avoid using the expression “being agile” as a euphemism for “being reactive” or doing work “faster and cheaper”. An agile team exhibits full control over its work in progress and the work it chooses to take on. Any economies will be found in the team’s ability to inspect and adapt, to evaluate outcomes empirically, and to reduce waste.
Avoid talking about “agile scaling” when the de-scaling of enterprise functions will be needed before even one team can achieve an agile way of working.
Avoid dehumanizing employees as “resources” or “work packages”. If you contextualize people as inanimate objects, you will get less than the person has to offer. Employees are human beings with creative and innovative potential. Value them accordingly.
Page updated
Google Sites
Report abuse