Task assignment is a team anti-pattern
"The way a team plays as a whole determines its success. You may have the greatest bunch of individual stars in the world, but if they don't play together, the club won't be worth a dime."
Assigning tasks to individuals might feel like the most natural thing in the world, but in reality, when you are trying to create a highly functioning team, it might be doing more harm than good. This is true even when tasks are self-assigned by team members, and certainly true when tasks are imposed upon individuals by managers. Here’s why.
Having one individual responsible for a task takes responsibility away from the team and instead focuses on the individual. This can be damaging in a number of ways, not least that the individual is under more pressure to deliver. Short termist management might think this encourages productivity, but the internal pressure this generates can be a short cut to burnout. The focus needs to be on collective responsibility: it’s the responsibility of the team to release something, not the responsibility of the individual.
This issue is compounded if the team’s work in progress limit is too high. If there are nine team members, and nine things currently in progress, then in the best case each person will have nine things to do, and in the worst case one person will have all nine things to do and the other eight people will be sitting around waiting for them to finish, putting enormous pressure on those who are the bottleneck. The more items of work that are currently in progress, the more than a focus on assignment will bite you.
Assignment promotes a command and control attitude. Sometimes, each member of a “team” is actually being managed individually and has their own stream of work. This can produce output in certain cases, but the individuals being managed are not a team: they’re a collection of individuals who might happen to sit together.
Individual assignment can create silos of information. If one person is responsible for a task, and everyone has their own tasks or types of work, then it’s harder to work as a team: the knowledge is held only with a few people, rather than across everyone. Pairing dramatically helps break these silos down.
Assignment can also give rise to the hero anti-pattern: where a few people are responsibility for the success of the entire team, and they end up pulling an all-nighter just to get the release out the door. The hero culture might seem appealing to short-sighted managers, but when eventually the hero inevitably fails to deliver, hero culture quickly turns to blame culture.
How to shift this culture?
-
Reduce your team’s work in progress limit. Insist they don’t start anything else until the team finishes what’s in progress, and that they go to pair with those who are still working on tasks, even if it’s not their normal discipline.
-
Stop giving people things to do. At the very least, ensure that the team are choosing their own tasks from a list rather than being managed individually.
-
Stop tracking assignment. Don’t record on the task who is working on it. Simply track what’s being worked on by talking about it each standup meeting.
-
Avoid the trap of buck-passing. If you’re not careful, giving a weaker team collective responsibility means that they pass the buck. The thinking goes: “if I’m not individually responsible then I’m not responsible at all.” The antidote is team accountability: praise the entire team for their successes and ensure they all investigate the reasons for failure together. This includes the product owner and the user experience people - they are all part of the team.
Does task assignment cause problems for you? What silos could be broken down by having more of a team assignment focus?
Share
More articles
Why you can scale agile with the right attitudes
The more I work with teams, the more I think agile at any scale lives or dies based on attitudes of people in the organisation, rather than the scale at which you are attempting to do it.
Software development is hard, and it’s harder the greater the scale as Rachel’s post eloquently argues. However, I don’t think the scale is always the limiting factor here.
I’ve seen small teams with such a lack of trust that they burden themselves with suffocating process, and larger organisations with so much trust that they’re able to operate at the speed of organisations a quarter of their size.
As organisations get bigger, the trust required gets greater. If the trust exists, teams are able to remain independent and don’t get burdened with process.
If you need to work at one thing to make your large organisation more agile, work on building trust between teams, and between teams and management. Try small wins, quick feedback, and constant celebration. Decentralise decisions, give people ownership in their areas, and act like they’re as good as you know they are.
If middle and upper management could be persuaded to give up control and provide leadership instead, your scale matters much less than you might think.
Read moreWhy BDD works solo, and why that matters for everyone
“The monotony and solitude of a quiet life stimulates the creative mind.”
– Albert Einstein
It’s possible to play chess and many other games completely solo, without anyone else to play against.
Incredibly, our minds are able to take on the role of both players in a competitive match. Our brains allow us to place ourselves in the opposing player’s shoes. Even more impressively, we are able to hide certain information from our own decision making process – such as what we’re planning to do next turn. We can analyse this incomplete set of information and play a move based solely on that, even if it’s sub-optimal.
BDD can be done solo
Using Behaviour-driven Development (BDD) on our own is much the same as playing a game against ourselves.
Instead of playing the opposing role, we take on the role of the stakeholder. We put ourselves in the shoes of the person paying for or commissioning the project. Because the BDD practice of writing gherkin-style features forces us to think in plain English, we jettison the role of programmer for a moment, and drift in the non-technical solution thought-space.
Why is this important? It’s a valuable exercise for a couple of reasons:
-
We gain a fresh perspective on what we are doing. By taking our heads out of the code and putting ourselves into the role of the stakeholder, we are able to see the wood for the trees and get perspective on the code we’re writing right now. It might be interesting code to write, but does it matter?
-
We gain a fresh perspective on the stresses of others. Every developer should take the opportunity to be a stakeholder once in a while. It’s very helpful to see what life it like on the other side of the estimation table. If all the members on a team are able empathise with the constraints and pressures our colleagues from different disciplines have, our team will run much more smoothly.
BDD solo is why BDD matters in the first place
Sometimes we confuse the concepts behind BDD with the tools used to practice BDD, like 3 amigo meetings, story breakdown and Cucumber.
BDD isn’t about the tools we use, it’s about the communication in the team. It’s about having the right conversations at the right times, hammering things out together, airing and refining thoughts and ideas, beating out ambiguity and forging common goals. This is why it matters.
If it was just about the tools, BDD would have been lost in the noise years ago, and BDD solo would be an expensive overhead. Why add another layer of tool complexity if it’s just us?
However, because BDD is about the concepts, not the tools, BDD works just fine solo: the process of deliberately stepping outside our developer role and thinking through our project from a product perspective gains us insight and understanding. This works no matter what tools, languages, frameworks or practices we may prefer.
When we’re solo, we dispense with a lot of the tools we don’t need. We don’t need to schedule a 3 amigo meeting with ourselves, for example. We’re left with a very pure form of BDD, set free from the needed constraints of multi-person teams.
Then we can begin to understand which of the common practices of BDD are only there to work around problems and can be discarded as needed, and which are truly foundational.
Try it out
Try using BDD on a personal project. Play the product owner, and write some Gherkin-style features. Pretend you can’t code. Really think about your problem without thinking about exactly how you’re going to solve it.
Whilst doing this, reflect on what practices you really need, and which you don’t. Which tools are less useful on your own? Which are more useful?
If you feel we’re just wasting time, I’d challenge us to think about what that’s telling us about our own ‘standard’ agile practice. How much of it is truly making us more agile, and how much of it is simply getting in the way?
Read moreHow to decide whether a tool is right for you
We are only at the beginning of our journey in building software. Our discipline is barely a few decades old. We have only a very little experience in how to correctly write code and a limited range of tools and skills to do it with. We should be actively looking for new tools, not wasting our time either promoting our toolset exclusively or disparaging the toolsets of others.
Tools are tools
Test-driven development has been one of those tools that has proved useful for many people over a number of years. Do I use it? Yes, much of the time.
Using a refactoring IDE has also proved useful to many people over a number of years, especially in certain languages. Do I use one? No. Does that mean it’s not a useful tool to others? No, of course not.
The ability to decouple code to promote changeability is also a great tool to have in your toolbox. Do I try and do this? Yes, wherever I can, and I’m always trying to get better at it.
There are many more. The insight as to when to refactor, not just how, is an incredibly valuable skill to have. The understanding that all code is built for someone and we should ensure we talk to them about what they want is powerful. Being able to check into source control without touching the network is a real speed boost, and gives me a detailed history of progress.
The recent TDD storm
So why do we get so hung up on one particular tool? When something works for us, we’re compelled to proclaim it’s the One True Way and that it’ll work for every problem and solve every headache. This is a grevious error, but in avoiding it, we can make the opposite one: when we find a tool’s limitations, we discard it completely and move on, proclaiming it useless for all.
DHH has a point. Don’t listen to the people who say there’s only one way to do a job, and that we should use any tool for everything.
Gary Bernhardt has a point. Test speeds do matter - the faster the better. Fast tests are a powerful tool.
Uncle Bob has a point. It’s not just about fast tests: separating concerns in order to promote changeability in code is a useful skill to learn.
Tom Stuart has a point. TDD is a useful tool because it gives you another client for your code, encouraging us to think harder about what it’s doing.
Seb Rose has a point. We need to learn how to use TDD (or indeed any tool) well before giving up on it.
Cory House has a point. People display their own biases in their opinions and we should learn from them all.
How to decide whether a software tool is right for you
It doesn’t matter whether it’s TDD, Vim, Git, Refactoring, OO, Functional programming, JavaScript, RubyMotion, etc. Follow the following advice repeatedly, substituting your own values:
If you haven’t tried tool X, give it a go. Many have found it helpful in areas Y and Z. Some have also found it applicable in areas A and B, but your mileage may vary. Some don’t get on with it, and a few hate it and say no-one should use it. Learn it properly before making any final decision about its usefulness to yourself and others. This will take <an amount of days/months/years> to do. Continue using it as long as it’s helpful to you.
There are as yet very few absolutes with software tools - we’re still way too primitive in our discipline for many of those. Let’s learn how to use as many tools and skills as possible, and use the right ones for the job. Let’s not decry the tools, skills and techniques of others if they are useful to them: let’s instead spend our energy actively seeking new skills and tools to further our discipline.
Read more4 questions to discover if you're *really* agile...
Here’s a challenge: how many of these questions are are true for your team? (Be honest.)
-
Does our team value processes and tools (i.e. our task tracker, source control program, our agile process, our meeting cadence, etc) over conversations between team members?
-
Does our team attempt to document everything (perhaps through long comprehensive ticket descriptions, or massively detailed cucumber features) before focusing on working software?
-
Does our team think about about SLAs, response times and formal release procedures before shipping something and having a conversation with the customer about it?
-
Is following the plan that you agreed in sprint planning more important than changing it in response to a customer?
If our projects sound like this, we’re doing exactly the opposite of the agile manifesto.
The anti-agile manifesto
Processes and tools over individuals and interactions
Comprehensive documentation over working software
Contract negotiation over customer collaboration
Following a plan over responding to change
Read both versions through. Which one sounds most like your project?
Read moreMake Cucumber features more readable with this one weird trick
“Sorry I’ve written such a long letter; I didn’t have time to write a short one.”
If you’ve got an issue with your customers not reading your feature files, then try this: it’ll help ensure their eyes stop glazing over.
As I travel around coaching teams doing BDD, a common problem I see with Gherkin features is that they are nigh on unreadable except by the people that wrote them… and even then, the writers often have trouble explaining what they mean.
This often happens when non-technical stakeholders have little to no involvement in writing features, leaving technical people free to be as obscure as they like. It’s easy to write an obscure feature: it takes a lot less effort to ramble and choose the first words that come to mind, rather than crafting carefully considered prose. The pain comes later: an obscure feature is imprecise, error-prone and unmaintainable, as the effort required to understand it will stop others from maintaining it.
How I help people simplify their features
When asked to review the language of a preamble, I read the feature out loud, and then ask the writer of the feature what it means.
A deep breath often follows. “Ok, this is the one where…” The writer will explain the feature clearly and concisely using completely different words to what is actually written in the feature. They use great contextual information that’s missing from the written preamble, and work to ensure I really understand what’s going on.
Once I’ve got a good response that I can understand, I ask the writer to replace the preamble with exactly what they just said.
It’s never exactly what they said (natural language is different to spoken language, after all) but it’s always better than what they had before.
Sometimes, when asked what the feature means, the writer will give a short hesitant explanation, and then proceed to read out the preamble again. My response is normally: “yes, but what does it mean?” Occasionally I have to ask five or six times until I get a considered, clear response.
This also works for scenarios, scenario descriptions, tag names, etc.
Why this works
Sometimes it’s easy for us to get so wrapped up in the detail of the features that we’re writing that we’re unable to see the wood for the trees. Our features read much more like computer code than they do plain natural language.
Features are communication tools first and foremost, and leveraging different ways of communicating while writing them will help to ensure they’re as carefully considered as possible.
(This works for natural prose, too. if you write a blog, documentation or even just emails to colleagues, taking a moment to read your text out loud will tell you in an instant whether it makes sense.)
A challenge
Pick a feature on your project, and read it out loud. If it makes no sense, explain what the feature does to a colleague and ask them to write it down for you. If it reads awkwardly and could be improved, take ten minutes to do so. Your future readers will thank you for it.
Read more