Working with teams in larger enterprises who are trying to adopt an agile way of working often throws up some interesting challenges, where a team who are trying to change their way of working must interface with the organization around them. In this situation, ideally there are strong and proactive management, who use their empowered position to protect the team, acting as a buffer inside which the team can do whatever works for them. In the worst case, a weak person in this position can have the opposite effect, magnifying the problems the team face by turning the agile values of transparency and honesty against the team and creating a nightmare situation. In these teams, it is very common for productivity to be surprisingly low, and teams are often not sure where to look.
As is almost always the case, a good approach is to use the most valuable tools in the agile toolbox – retrospectives and action on them – to turn the tide. The team may feel they know what the issues are – frighteningly often things like “too many meetings” or “meetings breaking up the day” come up. A useful exercise to gain some insight and data is to have the team track their time and, and as a team identify where things are disruptive and add no value. The scrum master or management can then act on this on the team’s behalf by using their empowered position to push back on external obligations, and by encouraging the team’s internal communications to be more effective.
One way of doing this that can work nicely is to use Lego bricks to build up a picture of the day – use different colors for the categories of where time goes, working in appropriately sized increments (perhaps half an hour). For example green might represent useful sprint work, blue might represent useful sprint-related meetings, orange might mean work that is not useful to the task at hand (perhaps responding to an outage), and red could be meetings that don’t help with the current goal. The team should add whatever categories are relevant to their situation. If physical Lego blocks aren’t a viable option a quick spreadsheet with colored cells, or simply a list of the day’s activities does the same job.
Crucially, this information is absolutely not for managers, and it’s not to track who’s doing what; it is for the team to use to identify and resolve problems of disruption.
A key aspect of how an agile team operate is that they have autonomy and ownership of how they work, and the right to change things and improve their situation. Once a team have identified a problem, it is the job of servant leadership to help the team to solve the problem. This most commonly means intervening to defend the team from external constraints and demands. Wherever possible though, the best outcome is to empower the team to solve issues for themselves.
Let’s say we have a team who identify that they are spending too much of their time with interruptions – people are needing things from members of the team, and go to them directly to ask. That person wants to help, but in doing so is forced to context-switch, and loses where they are in their current task. For developers in particular this is a big deal, especially if the task at hand is complex. There are many possible ways to remedy this problem, such as encouraging all non-urgent queries to go through a point-man (perhaps the scrum master!), who triages these enquiries answering as many as they can before dispatching the others in a way that is less disruptive. Another way could be to use pairing more widely – in a pair, if one member is disrupted, the other acts as an anchor, staying focused and helping catch the partner up when they return.
If a team identify “too many meetings” as an issue, it might be a sign that the team feel they are being told what to do. A healthy team will communicate quite naturally, and not really need to be told to do so. Meetings in a healthy environment become a tool to use only when more formalized scheduling is needed – such as when an external party is involved. The scrum master here can insert themselves as a step in booking meetings with the team, making sure every meeting is useful (it has a clear agenda and desired outcomes in advance), needed (the outcomes can’t be achieved any other way), has the right people in the room to reach those outcomes (not too many, such as people who aren’t involved, or too few, such as a lack of people empowered to make an actual decision), and at a time that is appropriate. It can be surprising how setting up this fairly basic barrier can remove almost all of the worst kinds of meetings and making the remaining ones more focused and effective.
In many cases a team will spend far too much time on non-sprint work, especially if technical debt has been allowed to accumulate and there are outages that the team must respond to. This normally arises when a team haven’t been allowed to set their own pace and level of quality, and have been pushed to deliver features in an unsustainable way. The remedy here, as painful as it may be for management to swallow, is to allow the team to manage their own backlog, prioritizing removal of the pain points in the system. If the team are able to do this – without pressure or interference – the result should be a short term reduction in feature delivery while debt is tackled, resulting in a boost afterwards as the team are no longer dealing with these ad-hoc problems. The best way to prevent this from working is for management to meddle in the recovery, setting “deadlines”, telling the team what to fix or how to fix it, or insisting on “just this one feature”.
Ultimately though, while it is useful as a delivery lead or scrum master to have a toolbox of possible remedies, the best results come from empowering the team to own their improvement process. If the team are struggling, it is ok to provide nudges and assistance, offering things that have worked in other teams with similar issues, but it must be the team that decide on the way forward that they want.