Recently, the Information Services team, who have been working to deliver Court-finder and Tribunals Decisions Database (both available in public Beta) have re-invigorated their Agile approach in order to improve delivery of their products. As a result of the changes we've made, team delivery has improved, team focus has been strengthened and team members drawn closer together. We’ve created a winning team.
Here’s what we’ve done over the past three weeks:
Splitting the teams:
First of all, we split the team. Now we don’t think of ourselves as being ‘Info Services’; instead, we have a Court-finder and Tribunals Decisions team, and we dedicate developer and technical resource to each service for every sprint.
This was because we had too many new people on one team, too soon. Although often thought of as necessary to reach project deadlines, the result of adding a lot of new people to a team is poor communication on tasks and difficulties in working together, adapting to new styles etc.
Splitting the team meant that the separate teams were smaller. They could communicate more easily, and what they were working on was more visible. Similarly, they were able to streamline their work, and eliminate waste, duplication or inefficiency. Further, it reduced context switching substantially.
Reducing our Sprint Schedules:
We’ve also reduced our sprint schedules from 2 weeks to 1 one week. Although traditionally resisted by most developer teams as it creates the impression of greater overheads, one-week sprints allow you to plan and re-plan faster, to learn quicker, and deliver more regularly. It shouldn’t lead to greater overheads, because a retrospective for a two-week sprint should be longer than for a one-week-er.
The main benefits that we found for reducing sprints to one week was that it was easier to concentrate on delivering a smaller number of tasks, and planning capacity for those tasks. Planning for two weeks can be time-consuming, and over-whelming; smaller sprints create the impression of fast progress, and more being delivered. It’s biggest benefit is the focus on delivering at the end of the week, right from day one.
Stand-up discipline:
Stands-ups are important, and they have to be disciplined. We time-box ours strictly in order to create focus. They don’t exceed 15mins, and if possible, we reduce the time they take further.
We also ensure that what we are focused on delivering value to the customer. We do this by disciplining how we talk at the stand-up – see our visual note (below) on how we present what we’ve done and what we’re doing. Finally, we’ve re-orientated the board so that it now reads right-to-left; this is so that we focus on finishing the things that we’ve started, rather than starting new things from the backlog without delivering them.
Making it visible:
The way we work is all about making things visible. We’ve transferred our project board to the new whiteboards so that we can make what we’re working on more visible. We make it clear who’s doing what by in a day by sticking our avatar on the story we’re achieving. This also helps to improve communication and visibility at standups.
We also commit the top three actions we agreed as a team from the retrospective (as voted by the team) to the sprint backlog, so that we ensure that we are working on our learnings.
Each sprint we also focus on a sprint goal so that we have a clear focus to the value we deliver for the customer – the goal’s displayed at the top of the board.
Finally, we make the velocity as clear as possible. The team can clearly see the size of the beast that it’s committed to delivering, and how close they’re to delivering it. By showing their previous velocity, they know how they’re doing against last sprint, and as the two teams work closely together, they become slightly competitive.
Planning, planning, planning:
A successful sprint depends upon successful planning. For us, planning is a interplay of the product owner, the delivery manager and the team.
The product owner, Dani, prioritises what she needs delivering each sprint in order to achieve her product vision. The team works through the prioritised backlog, letting the product manager explain the stories they are committing to,; the team then size the stories relative to one another. The delivery manager ensures the team does not over or under-commit. As a rule we commit only 80% of what we think we can achieve. The delivery manager also ensures that the stories are properly clarified, asking whether we need to draw out the tasks necessary to deliver a more complex story, or whether one that the team is struggling with needs breaking down into multiple stories.
When the team is happy that they have reached their commitment levels they do not add anything more to the backlog for that sprint. This takes some serious discipline when the odd bug comes up, but this causes teams to fail to deliver or be over-worked. We also do not plan for people are not present at the planning. Only they can say what their capacity is. Anything extra achieved in the sprint is a bonus
By committing as a team to a reasonable commitment at the start of every sprint, the team is able to take ownership of its delivery goals.
Regular Demos:
Giving the team the opportunity to regularly demo what they have built at the end of each sprint or every other sprint to external stakeholders, or simply to the Product Owner, means that they and the business have oversight of the improvements that they are making. It also gives them an objective to work towards for the end of the sprint, which can be quite motivating come Thursday!
Cookies:
Finally, a good supply of cookies has been found to be necessary to keep our Tribunals Decisions devs, Jairo and Hrishi. Keeping Stuart happy at Dev Ops is still something we’re working on, and deserves a blog post of its own once we work it out.
Leave a comment