Project-orientation causes focus on individual utilisation, which is a key contributor to bad culture

In project orientation there is a desire to ensure that each member of a software team is allocated work, and is fully accountable to their own work.  We call this “individual work assignment”.  The belief is that by assigning work items to individuals, the individual is more “accountable” for their work, and it’s obvious if they are not doing their job.

I even heard one person recently say “Each ticket is never worked on by more than one person. Right?”

This is the antithesis of team culture.  It prevents people from working together to do problem-solving together.  Even worse, it encourages people to kick back once they have completed their work and leave others to their own devices.

This individual-assignment problem prevents cross-fertilisation of skills, knowledge and experience.  We WANT individuals to pair up and work together via collaboration.  We want cross-functional team members to pair up, not just the engineers.  Through pairing and sharing, teams build bonds to support each other.  Through pairing and sharing we build redundancy - if someone goes on leave, then someone else can cover for them if there’s an issue they know how to solve.

If you want accountability, then focus on team accountability - build a team where individuals support each other to achieve outcomes and deliver outputs.

So how do you solve it?

You propose an alternative (to the person assigning individual work items) -

“Let’s try this experiment.  Let’s allow the team to decide who works on which items, and let’s make it clear that all items must be completed (by the end of the Sprint, etc).  More importantly, let’s foster support and team culture by saying ‘The team must get through these items, even if the whole team has to stay back late one or more nights to get the work done.’”

Get buy-in from the team.  Get buy-in from the person pushing for individual work assignment.

Try that for a couple of Sprints, or 1 month if you’re not doing Sprints.  At the end, ask the team if that was better.  Why / Why not?  What could be improved?  What support does the team need to make this model work?

The goal here is to empower teams so as to build Resilience and Empathy.

Anyone can drive better outcomes and greater autonomy in software teams. Learning how starts here. Agile Delivery Leads can foster this Continuous Improvement Mindset.