Recently the Waste Permitting Service reached the end of its first phase; to deliver an application process for standard rules waste permits. As we moved on to our next phase; supporting bespoke permits, we were keen to shorten the time between starting research on a feature and starting delivering it. We discussed numerous solutions to this in our retrospective, but the whole team backed the idea of trying out mob development.
Mob development is the idea of getting the whole team working on a single item in tandem. This would usually mean the whole team sat together in a room, all working on a single computer. Unfortunately we didn’t have a dedicated room, and part of the team were still working on getting the service live, but we were still keen to give the concept a go. Here’s how we got on…
Day 1
We had a bit of a mixed start to our mob development. Everyone was really enthusiastic to give it a try, but our team tend to be quite dispersed on Mondays, and the people who were in our main location had a variety of meetings booked. As we would quickly learn, off project commitments would be the bane of mob development.
When we did get everyone together we sat down to share our collective knowledge on bespoke permits and to sketch out some possible solutions. This also highlighted a bit of a divide in the team. How much design and prototyping can you do without a good handle on user needs? Eventually we agreed to try some designing and prototyping in order to use those prototypes to learn about user needs.
Day 2
At this point the mob started to split up a little bit. Our developer and one of our designers worked together on the prototype kit, whilst the rest of the team split up to do various research and analysis tasks. It was possible the mob would fall apart before it had really begun, although it still felt like we were swarming (all working separately on the same item) on bespoke permits.
The team also discussed the question of 'What does it take to get the mob to form?'. We didn’t really have a great answer aside from having the delivery manager stand up and form the mob. This wasn’t sustainable as the delivery manager wouldn’t always be around, but there was general agreement that it was the only answer we had.
Day 3
Our third day started in the way the first two should have done. We agreed an approach to our mob development, and agreed a set of goals for the day.
Our overall approach was to define hypotheses about bespoke permit applications, develop prototypes to test these hypotheses and then do research to validate them. We’d already done various bits of this process, but not in the right order, so we started filling in the gaps.
By the end of the day we had a clickable powerpoint prototype, two different prototype flows, and had done some research on the prototype flows. This was the most successful day of the mob so far.
Day 4
Once again we set our goals for the day, however it was clear by this point that we were heading very much towards swarming rather than mobbing. The various members of the group went off to take on different tasks such as research, analysis or prototype development. Whilst there was some pairing on prototyping and research, we never got more than two people working on a single task. Having said that it was another productive day and we completed all but one of our goals by the end of it.
One thing that did strike me on the fourth day was that as we moved away from a mob towards being a swarm we steadily collected more goals. Even though we didn’t set goals on the first day, we really all did work together to complete one aim. By day 3 we had three goals for the day and by day 4 we had five. Whether this reflected us getting more done by working in parallel, or us just lacking focus was hard to say.
Day 5
The fifth day brought the biggest challenge. Most of the team work from home on Fridays and so anything approaching actual mob development was always going to be a stretch. An agreed 09:30am planning session on Slack lacked any real engagement and so the team went about their day as they normally would.
With it being increasingly difficult to get the team to work together on a limited number of goals we decided to call a halt to our trial. We’d continue with our designers and researchers preparing for bespoke applications but the rest of the team would go back to other work the team had on.
Why the mob didn't take hold
Having completed a week long trial of mob development everyone was satisfied that we should call a halt to it. However we were also keen to understand why an idea that people were enthusiastic about, and has worked well for others, didn’t work out for us.
We weren’t at the right place
From the start there was a level of discomfort in the team about developing prototypes or doing too much analysis without having a better understanding of user needs. There was also a feeling that the nature of research made it a hard thing for a mob to work on. So perhaps we should have waited until the research was done before starting the mob.
We didn’t have the right people
Working in continuously as a group, as opposed to having periods of working individually, is tiring and certain people are attracted to this way of working more than others (see Quiet). Several of the members of our team are more comfortable getting to grips with problems alone, before collaborating to solve them. This meant that working in groups for long periods of the day was ineffective for them. While it may be possible and effective to get everyone working in a more constantly collaborative way, it may also be incredibly stressful getting to that point.
It was too big a change in our ways of working
Up until now we’ve been following a fairly strict Kanban approach, that takes pieces of work through the phases of research, design, development and testing. Whilst there is lots of collaboration, particularly at the interfaces, generally it is a single person's role to lead on getting a task through a phase. By jumping straight to mob development we were moving to the opposite extreme in terms of collaboration. This may be why we kept falling back on swarming as an intermediate step.
We didn’t really do mob development
Mob development involves getting everyone involved in completing a story work round a computer. In reality we did have everyone working on a single story, but not necessarily at the same computer together. Our way of working was more a hybrid of mob development and swarming. Maybe if we’d followed one approach a bit more clearly we might have had more luck.
It wasn’t all a waste
By giving mob development a go we learnt a lot about how we worked as a team. Even though we decided not to continue with it we progressed more on bespoke permitting than we had in previous weeks. We shared a lot more knowledge with a wider portion of the team, and progressed our understanding very quickly.
Our current process results in lots of work in flight, and can leave a task parked for long periods before the next person in the queue can pick it up. Hopefully our experiment with mobbing will result in us collaborating more closely and having fewer items in our pipeline that are completed more quickly. There is also some enthusiasm for giving the approach another go, perhaps when we’re a bit better set up for it. So you might just be hearing more on this subject in the future.
