On October 7, 2014
With No Comments
Whilst at MYOB, we ran a very successful UX and UI swarm in Avalon Beach. We did this as we needed to get offsite to break some of the corporate habits the business had inherited over the years.
So what’s a Swarm? A swarm is an intense gathering of the core people (who get stuff done) on a project, with a view to getting through large amounts of work in a short amount of time.
Now, granted Swarms can be seen to be disruptive to the flow of a project, especially if it’s done in the middle of sprints as it was at MYOB. But when done right, can catapult you into pole project position. Ah look at that, a little bit of alliteration.
At MYOB, I’d been looking for an opportunity to execute this idea, but the thoughts of going to source a location, get all the supplies, move the team up there, get approval and budget etc. was a little bit off-putting. But I knew that my friends at Domain had recently done something up in Avalon, and was blown away by what they had achieved in such a short space of time, in a great location that was not too far from the city (50 minutes north) at Avalon Beach, that had a decent wiFI set up.
So rather than go looking for somewhere, I managed to get the name of the house from Damon at Fairfax, and rented it directly. This saved us a massive amount of time and effort “searching” for a suitable abode!
Before we left, I created a shopping list of items we knew were going to need. These included:
- 20 X Post-it books
- 3 X A2 sketch pads
- 20 X Sharpies
- 1 X Blu-Tac pack
- 1 X Box of tricks with markers
- 1 X 27″ iMac
- 4 X Power-Boards
- 1 X Apple TV for HDMI presentations
- 1 X Telstra Broadband wiFI
Arriving at Avalon
The success of this Swarm was down to one thing – allowing for organic collaboration amongst the team. Giving people the room they needed to work as effectively as they could. This was going to take a strong team effort, and no one person was going to make or break it.
So before we did anything, we defined each persons role in the Swarm and also defined what our achievable goal was for the 3 days and 3 nights away. You need to do this. You need to set an end-goal. Once we did that, we worked back on what we could realistically achieve by the end of each day.
Forming small teams
Once we knew where we were going, we split the groups into teams. We had 9 people in total with us, including the Product Owner. So we split into 2 teams/streams of work. Each team consisted of:
- 1 x Business Analyst
- 1 X User Experience Consultant
- 1 X Project Manager
Basic Daily Structure
- Morning Session
- Pre-Lunch Session
- Post lunch Session
- Afternoon Session
- Evening Session
On day 1, we were still really uncovering things. By the end of the day, we had still managed to get through quite a bit of work, but our goal of achieving a designed prototype to validate with users was beginning to elude us. But not to be too disheartened, we celebrated the success of getting through what was still a big amount of work. We stopped working at around 9pm, had a big BBQ and downed some well earned beers.
Following on from the mini-success of the first day, we started as we left off from the previous day. But in hindsight, we should have changed things up a little bit, and each moved onto a new stream of work. I guess a certain amount of complacency started to kick in, and the problems or hurdles that we faced in the office started to emerge. This was the slowest day of the 3 1/2 days that we were away, and if I felt the goal was eluding me after Day 1, I started to feel it a little bit more after Day 2. But in saying that, we still managed to get through a decent amount of work. But one thing started to happen, that hadn’t happened before – the teams started to click.
The structure we had in place was working, but it wasn’t really allowing for a successful flow of work. Each of the “sessions” was in effect a sprint, but the time block was too long. Meaning that after 2-3 hours the teams would present back to the other team members, and if we had suggestions for improvements it would always involve rework. In any other circumstance this would probably be deemed fine or part of the process, but when you’re in a swarm, these inefficiencies are massively magnified.
So, what did we do? We reduced the “sprints” to 1-hour. After the hour, we have a review of the work, and provide feedback. By doing this, we removed the chance of the team going down routes of inefficiencies. We were able to raise problems, and solve problems in real time. Once we did this, something amazing started to happen. Communication went through the roof, and we were producing work that was tangible and solution driven. The best part of this was, everyone was involved, and was group-collaboration at its fullest. Everyone felt a sense of ownership.
By the end of Day 3, we’d managed to get through probably the same amount of work as Day 1 and Day 2 combined. By moving to 1-hour sprints, we worked at the fullest capacity. It was demanding, but really really enjoyable. Would I suggest running all 3 days with 1-hour sprints in place? I’m not so sure.
Days 1 and 2 were like intense research sessions in hindsight, and by having that time, we were able to nail Day 3 with the 1-hour sprints.
Everything clicked. Literally, like prototype we created (sorry bad joke!), and was successfully presented back to the Senior Stakeholders on the Friday. It was a great exercise in team building, and a great opportunity to show just how effective successful collaboration can be when done right.
Special thanks to the amazing UX/UI team at MYOB Sydney, Kapil and Phil, and the great Rob Cameron for their stellar effort at the Avalon Swarm.
Check them out on Dribbble.
Roy Arrellano – UI Designer
Arlen McCarthy – UX Designer
Matt Hurley – UX Designer
Peter O’Dwyer – UI Designer
Joshua Kelly – Front-end development ninja