Last week we travelled to Dusseldorf, Germany, to lock ourselves in a room with our client Canyon and development partners Wysiwyg for a three day development sprint. Our single shared goal was to create a working alpha prototype that could be shared and tested with a closed group of Canyon customers the following week. It was the first time all three teams had co-located an co-created together on a project so it was an interesting collaboration experiment that we were super keen to try out.
In this post we’ll share our top tips for collaborative development sprints based on what we learnt along the way.
“Nothing is more effective than walking over to a colleague, showing some work, discussing, sketching, exchanging ideas, understanding facial expressions and body language, and reaching a resolution on a thorny topic.” — Lean UX by Jeff Gothelf
#1 – The core team
Having the right people in the room during the sprint is key to it’s success. Not everyone in the team will be working solid on the prototype at all times so it’s a good idea for everyone to bring other work that they can be getting on with during down time, whilst still being prepared to drop that and jump back in when questions arise and their expertise is needed. The client is likely to have the most down time out of everyone but the knowledge they hold of their own systems and processes is invaluable to the team so don’t be tempted to leave them out. Be sure to set expectations in advance so that team members know what to bring.
From Common Good:
Product Manager, Lead UX Designer, Designer
Front-end and Software Developers, SAP data specialists, Project Manager
Software Developer and Technical Team Leader
#2 – Start with a show & tell
Spend the first hour very briefly re-capping on the work that has been done so far so that everyone starts on the same page. It’s a good idea to share everything with the core team in advance so that show and tell doesn’t take up too much of the actual work time. It should be more about refreshing everyones memory rather than presenting information for the first time which will slow things down.
We talked through a low-fidelity prototype we’d created as an output from a four week design phase involving research, design sprints, prototyping and concept testing. Wysiwyg showed us the web environment they had set up ready for the sprint and an initial rough attempt at building the pages using existing web components, and Canyon shared and API they had created to give us access to their data.
#3 – Not too much project management
The management style and structure was deliberately casual and responsive which gave everyone in the team autonomy over how the sprint was run. We found that this approach breeds natural conversation, discussion and sketching to overcome challenges as they arise. Start and end each day with a quick team stand up to collectively review where everyone is up to. We ended up with a very rough Kanban like wall of tasks, outstanding questions and test ideas. Not too much project management gives everyone responsibility so aim to be flexible and not too rigid.
#4 – Problem solve in smaller groups
Throughout the sprint unforeseen edge case scenarios and challenges came up where we needed to evolve elements of the experience design. The majority of issues only became obvious once we could see the prototype with real data and content and in its actual environment.
Instead of trying to predict all of the scenarios upfront in isolation, it’s best to solve problems with the people who hold the knowledge. Resist the urge to do too much prep in advance, and try not to solve as a large group instead break off in smaller groups of three or four people to speed up decision making.
“The goal is to release a product. Once it’s released, users won’t interact with the wireframes or requirements document as part of the product. They will interact with the product itself. So, try to spend less time on your design artifacts.” — Anthony Viviano
#5 – Take time out
After all the hard work during the days we rewarded ourselves by exploring the beautiful Dusseldorf riverside and old-town in the evenings. It’s good to have some time away from the sprint to clear your head and come back with fresh eyes the following day. Team lunches also helped us to get to know the team better outside of a working environment. Remember to give your head some time out to avoid early burn out.
Why did we take this approach?
- We wanted to create something that worked with real data that we could test, fast.
- Our client, development partners and us are based in three different global locations across Germany and the UK, making timely communication a challenge.
- We wanted to put all our effort into the actual product rather than creating extensive design specifications (that eventually end up in the bin). Lean UX = less waste.
- We believe that conversations are more effective than documentation.
Face to face collaboration is awesome!
We’d love to hear how you get on. Drop us an email firstname.lastname@example.org