Most companies do a number of things to help ensure that people are aligned to a common goal. This typically starts with our company vision, passes through departmental missions and/or OKRs to individual team missions and/or OKRs, to an individual’s personal objectives. It might not always be perfect, but for the most part everybody is heading in the same direction with the same vision.

It’s not enough for teams to simply be aligned though; they should be a cohesive unit that is greater than the sum of its parts, with everybody working as one. The problem is that, as Boromir would say:
One does not simply align to become a cohesive unit

Unlike a production line, where individual tasks are completely isolated to other parts of the line, Software Development is a highly collaborative and iterative process with inputs from a number of different sources.

Despite the accepted importance of collaboration, many teams revert to ‘mini-waterfall’, where development is a distinct sequential process that looks something like this:

Analysis -> Design -> Implement -> Test -> Review -> Document

Another common problem is a desire to break a user story into tasks at the point of planning and the focus then becomes solely on the individual tasks. In itself, tasks are not a problem and they can be a good thing, the risk though, is that it results in individuals being assigned to “their tasks” which they “do” before passing it to somebody else to “review” or “test”. So while the story may arguably be getting completed in parallel by a number of people, the team is still working on their own tasks for which there is a sequential flow. They’re aligned, but they aren’t working together.

This can feel like a productive way of working, and for some teams it might well be – every team is different after all – but for many the feeling of productivity and progress will be an illusion brought on by the lack of interruptions (or “collaboration” as others might call it). It’s like driving a different route home because you get stopped at fewer traffic lights – moving faster doesn’t automatically mean reaching your destination faster – you could be on a much longer route.

Becoming cohesive and truly working together on things isn’t something that can be achieved through a series of prescribed steps; different teams have different challenges, different personalities and different dynamics. There are however some steps that I believe can help lead teams down the right path:

  • Breaking stories down to tasks is fine if it helps you to plan, but don’t track individual task cards in Jira (just note each task on the story card). Force yourselves to communicate with each other to understand what has been done and who is doing what.
  • Limit work in progress – but not for the “traditional” reasons of reducing inventory or reducing context switching. Try to get as many people as possible working on as few stories as possible so that there’s as much skill and experience trying to accomplish each individual story. Individual productivity may drop at first, but as the team works together and increasingly understands each other’s strengths, productivity and quality will increase noticeably, and generally morghosale will increase with it.
  • When demoing work at the review, have a system where you draw names over who demos what. This helps ensure that everybody is aware of what is going on. It doesn’t necessarily mean people work together, but from my own experience it could be a step to get things going in the right direction.