Words matter. Language matters. Single words can evoke a whole set of connotations and feelings. In the Agile space, the word “waterfall” certainly does that. Every language domain, such as an organization or field of practice, has these words or phrases that have a very specific meaning understood by everyone who’s part of that group. Sometimes they’re neutral, sometimes positive and sometimes they’re just taboo — words you better avoid due to the bad aftertaste or overwhelmingly negative connotations. In a different context or domain, the same word may be completely innocent and neutral — just ask hikers about waterfalls. (In one organization I worked for, you should never mention “productivity”; otherwise, you’d immediately be confronted with visceral reactions and backlash!)

For me, I recently developed an aversion to the use of the word “assign” while working with an Agile team. Its meaning is somewhat innocent on the surface: “to allocate (a job or duty)” or “give work to”. But when I heard it being used, it brought back memories of hierarchical organizations and Taylorism in action: A manager or superior gives a specific item of work to an inferior, a direct report, with the expectation that the work be completed within a short or even pre-determined timeframe while holding that person accountable for completing it in accordance with certain standards.

This thinking makes the hair on the back of my neck stand up. At this point, we should have moved past this. On Scrum teams, we have a prioritized backlog the team pulls work from at sprint planning. The team members self-organize around that work and determine how it should be done and who should be involved based on skill set, availability, as well as interest. Kanban teams pull from the “ready queue” given availability and room within WIP limits. True, there’s still work to be done and business priorities, but nobody assigns anything. It’s assumed that the people closest to the work are in the best position to determine how it should be done and by whom.

So when team members ask that work be assigned to them, e.g. by the Product Owner or the Scrum Master, there’s certainly no ill intent, but it’s showing that either the person doesn’t understand the Agile mindset (yet) or that the team hasn’t fully embraced our new way of working and still employs thinking where hierarchy rules and work must be given to employees (“resources”) by superiors.

Are you seeing this on your team? What should you do? Here are some ideas:

  • Don’t go with the flow and just “assign” work.
  • Emphasize that there’s a prioritized backlog to pull from.
  • Ask questions such as “What do you think we should work on next?”, “Which story do you have the right skill set to pick up?”, or “What’s the top story in our backlog right now?”
  • Encourage the team to self-organize around the work. Don’t get too involved in the “who” and “how”; focus on the “what”. Ask “How do you guys want to tackle this item?”
  • Reinforce that everyone on the team is equal. There are no hierarchies. 
  • Once the team has organized around a work item, ask questions, if necessary, but don’t overrule their decisions.
  • Encourage experimentation and allow the team to fail if needed.

I’m hoping we can agree that the word “assign” really has no good use in an Agile organization. Rather focus on prioritization of work and let the teams pull and organize around it. Even at higher levels in a scaled structure, such as SAFe, the word does not serve a good purpose. Release trains might be allocated to certain applications or strategic objectives and they have backlogs, but there’s still no “assigning” going on.

So please stay away from this word as it embodies anti-patterns and outdated thinking we’re trying to get away from. Instead, coach the team and make it safe for them to engage in self-organization.

What other loaded “anti” words or phases have you come across? Are there ones in your organization that are just too loaded with negative meaning to use?