One of the biggest bottlenecks in the delivery software changes can be the hand over between teams; whether this is passing a change to a test team to validate the release or handing a release over to the operations team to deploy.

The reasons these handovers become bottlenecks are:

  • The other teams might not be able to work on your change immediately due to their own priorities
  • The other team needs to get up to speed with the change, possibly in the form of some hand over
  • Problems or queries might come back to the development team who have moved on to the next piece of work, so may not be in a position to help straight away

The solution is to have a single delivery team responsible for the whole product from inception through to it being turned off and give that team the expertise to do it. This means bringing in the roles that traditionally would have been in their own team, for example, the sort of roles that might make up a delivery team could be:

  • Business analysts
  • Software developers
  • Quality assurance specialists
  • Operational engineers
  • User experience experts

When the team contains all the capabilities required to deliver a feature then the communication can happen quickly as everyone in the team is always working towards the same sprint goal.

It’s worth noting that the term “role” was deliberately used instead of people, individuals or team members. It is feasible and expected that members of the delivery team would fulfill multiple roles, particularly for smaller teams/products. It is also extremely useful if multiple people can fulfill each required role as this means that the team can continue to be productive despite a member of the team being absent. In fact it can reduce the bottlenecks even further, for example, if one of the software developers is happy picking up some of the user experience work then it can ease the load on the UX expert and that doesn’t prevent the expert reviewing the work to ensure consistency in design.

When everyone involved in delivery is working in the same team then they will be involved in the backlog grooming, sprint planning and daily standups so they are aware for the work that is coming up and can work together to deliver it, whether it’s a minor tweak to the UI or something that requires some new infrastructure.

Now that the delivery team own the whole product lifecycle they become aware of everything involved in the delivery and hosting of their software, this naturally leads to ongoing improvement to quality. For example, in the past it would be an operational engineer who gets called at 3am to deal with an application that’s fallen over, they would be trawling through logs trying to find the problem. However, they don’t know what the application is supposed to do, if they’re lucky they’ve had a handover from the developers, but would they have documented every failure scenario? What about all those log statements; are they relevant to the issue or does the application log that all the time? Or perhaps it’s not an issue that even warrants being woken up in the middle of the night?

If the person that is woken up at 3am has helped develop and deliver that application they’re going to know a lot more about what might cause a failure and is more likely to be able to resolve it quickly. More importantly, they can make sure that anything to improve it is worked on as soon as possible… they don’t want to be woken up again.