In Scrum, precise language is essential, as anything less contributes to a lack of transparency. When implementing Scrum, there might be pressure to adapt terminologies and their meanings to fit the hosting organization. Scrum terms can be twisted to align with existing structures. The consequence is an alteration in how we conceptualize agile change, constrained by the organization's weight.
Nevertheless, we are always subject to organizational influence, and no matter how rigorous or cautious we are, we cannot entirely shield ourselves from its effects. An effort we can make is to exercise small corrections quickly and frequently before bad practices become entrenched. Here are 20 of these "small things" that we might be tempted to say or silently agree with and that might be better to avoid:
1 - "Sprint Backlog"
Avoid describing the "Sprint Backlog" as a "commitment." It is a "plan" or "estimate" of the work to be done to achieve the sprint goal. It's better to use these terms. Remember that team members commit to goals, not forecasts.
2 - "Story Points"
Avoid language that suggests Story Points are "delivered" or somehow represent value or a way to estimate value. Story Points help a team estimate how much work they think they can take on. In agile practice, value is only found in the delivered work increment.
3 - "Ideal Velocity"
Avoid talking about "ideal velocity" when making forecasts. Instead, speak of an ideal value that can be delivered in the current sprint and future sprints. Remember, an agile team is not comprised of "Story Point accountants" but developers.
4 - "Sprint Goals"
Avoid referring to "Sprint Goals" when these supposed goals haven't been planned and accepted by the team. If they are trial sprint goals, then call them that.
5 - "Sprint and Special Sprints"
Avoid calling different stages of work production "Sprints" if they are not within a time box and do not produce a feature increment. "Special sprints" like "sprint zero," "integration sprint," or "test sprint" are actually stages or phases. If necessary, it's fine, but let's be honest and call them by their names without devaluing agile reference terms.
6 - "Demo"
Avoid describing a sprint review as a "demo." A demonstration of the work done can be part of a sprint review. However, the main objective of a sprint review is to consider the work done and the work remaining, inspect and adapt the Product Backlog.
7 - "Kanban"
Avoid talking about a "Kanban" unless the board you're referring to is explicitly linked to a flow system description. If your board ultimately functions more like a "to-do list," call it that.
8 - "Definition of Done"
Avoid calling acceptance criteria the "Definition of Done" (DoD). Acceptance criteria are part of the DoD for some Product Backlog items, but the DoD, which attests to the overall quality of the delivered product, goes beyond that.
9 - "Team"
Avoid talking about a "team" unless there is clear evidence that the assembly of people you're referring to collaborates directly and continuously daily. If people work in silos that are independent of each other and occasionally come together for a project, it's better to speak of a "working group" engaged around a common production.
10 - "Tools-support VS Practice"
Avoid referring to an agile initiative by talking about its tool support. Turning to an agile practice is not on the same level as "having Jira" or "using TFS," regardless of the technology used.
11 - "DevOps"
Avoid talking about "DevOps" as if it were distinct from an agile practice or a change in the working culture. If you're referring to technical practices like automation or continuous integration or deployment, prefer using those terms.
12 - "Technical Debt"
Avoid using the term "technical debt" if you haven't defined a strategy to resolve it or if the risk it represents is neither controlled nor correctly defined. In this case, it's better to talk about a "black box."
13 - "Release Plan"
Avoid the term "Release Plan" when some sprints are not intended to be part of a release. What you have is, in fact, a non-release plan. In Scrum, each sprint should produce a value increment, no matter how small. The decision to proceed with a release or not should be made based on Just-In-Time adherence. A real release plan should highlight what is likely to be delivered, not whether a release will occur or not.
14 - "Bugs and Defects"
Avoid talking about "bugs" or "defects" as if they were separate from the rest of the work to be done. They should be included in the work remaining and, therefore, planned and budgeted accordingly. The urgency of the repair and/or the speed at which it must be done should not hinder transparency.
15 - "Fixed Scope"
Avoid talking about a "fixed scope" when a Product Backlog is constantly being refined, and new options may emerge. It is better to consider that each sprint is an opportunity to deliver valuable elements for the customer, likely to teach them important things.
16 - "Envoyer en test"
Avoid the language effect that involves saying "send to testing," which suggests expecting something other than a pulled flow. Agile and Lean practices are based on pulled flow, which carries the concepts of effective work management responding to clear signals.
17 - "Distributed Teams"
Avoid referring to "distributed teams." A team that is not co-located is a "non-co-located" or "remote" team. Give it that name and be transparent and open about the difficulties and inefficiencies of teamwork that may likely arise from such a model.
18 - "Meaning of the Term "Being Agile""
Avoid using the expression "being agile" as a euphemism for "being reactive" or doing work "faster and cheaper." An agile team is a team that has total control over its work in progress and the tasks it decides to undertake. The savings will come from the team's ability to practice continuous improvement, grow in its capacity to assess velocity empirically, and reduce waste.
19 - "Agile at Scale"
Avoid talking about "agile at scale" when the transformation of the organization must still be conducted for even a single team to effectively adopt an agile way of working.
20 - "Collaborators = ressources"
Finally, avoid the tendency to dehumanize collaborators by referring to them as "resources" or even "man-days." If you conceptualize people as inanimate objects, you'll get less from them than they have to offer. Collaborators are human beings with creative and innovative potential; treat them as such.
I thank the author Ian Mitchell for allowing me to adapt his article, also available in its original version.
Now that you know a bit more about "How to Speak Agile?" feel free to check our previous articles to understand our conception of agility at ANEO and ensure you haven't fallen into the trap of the most commonly encountered absurdities!
