RSA : 1 — Setting Sail
“Coming together is a beginning. Keeping together is progress. Working together is success.”
- Henry Ford
The RSA project is a fantastic opportunity to collaborate and tackle some very big issues. The problems associated with collaboration and big issues are of course, collaboration and the big issues… When we started working, we didn’t know each other, what we saw was a blank canvas, which as every creative knows, is as terrifying a prospect as it is liberating.
One thing we soon established was the need to develop and foster an open and communicative relationship so that we could really be unbounded in our approach to the project. We really felt that the need for this couldn’t be understated as all the normal problems associated with this context would only be compounded by Covid, online working and not having a studio space to work face to face.
Framework — Adapted Scrum
As with any lengthy project, the need for clear definitions of value, managing complexity and iterative problem solving are important. We shared different ideas on how to build a framework that would work and we decided to adapt the commonly used Scrum framework to fit our needs.
Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum itself is a simple framework for effective team collaboration on complex products.
Scrum is simple. It is the opposite of a big collection of interwoven mandatory components. It is not a methodology, it implements the scientific method of empiricism. Scrum replaces a programmed algorithmic approach with a heuristic one, with respect for people and self-organization to deal with unpredictability and solving complex problems. The below graphic represents Scrum in Action as described by Ken Schwaber and Jeff Sutherland in their book Software in 30 Days taking us from planning through software delivery.
The key components of Scrum are:
A Sprint, is a time-box of one month or less during which a “Done”, useable, and potentially releasable project Increment is created.
Sprint Planning answers the following:
- What can be delivered in the Increment resulting from the upcoming Sprint?
- How will the work needed to deliver the Increment be achieved?
The Daily Scrum is a 15-minute time-boxed event to synchronise activities and create a plan for the next 24 hours. The three main questions that we asked ourselves at 9am every morning were:
- What did you do yesterday?
- What are you going to do today?
- What blockers stand in your way?
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the the project direction if needed.
The Sprint Review includes the following elements:
- We look at what items have been “Done” and what has not been “Done”.
- We discuss what went well during the Sprint, what problems it ran into, and how those problems were solved.
- We discuss the project direction as it stands.
- We discuss on what to do next which provides a valuable input for the next planning.
- Review of the timeline.
The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
- What went well in the Sprint
- What could be improved
- What will we commit to improve in the next Sprint
The two main practices that we felt would work well considering the context were Pair design and Asynchronous meetings. They were a bit jerky to begin with, (which had probably more to do with getting to know each other) but soon became a seamless approach to collaborating.
Pair design is the counterintuitive practice of getting more and better UX design done by putting two designers together as thought partners to solve design problems. It’s counterintuitive because you might expect that you could split them up to work in parallel to get double the design done, but for many situations, you’d be wrong.
Pair design is all about two brains on the one problem, at the same time. This doesn’t mean checking in with each other every now and again, or working part time. This methodology is more properly called a feedback relationship.
Within pair design there are two roles — The driver and the navigator, or the generator and the synthesiser. These roles aren’t fixed and good pair design happens when the roles fluidly interchange.
The Driver needs to be something of a maker, able to convey an idea clearly and quickly. The most important aspect is fearless generativity. For this reason, being comfortable drawing and drawing in front of their partner is very important. As most ideas will be half baked they will have to take criticism or input without taking it personally.
The navigator in this role, acts as an analyst, able to test the design ideas as they are generated and keep the bigger picture in mind about what the design needs to do, how the research and feedback should be considered, and the areas where progress needs to be made. The important skill is empathetic skepticism. Navigators verbally inform the driver, and the two of them talk about and weigh up the pros and cons on the fly, so they need to be quick on their feet.
An Async meeting doesn’t need everyone around all the time. Instead, the meeting happens in written form via a shared document. This works really well for remote working, as it helps reduce fatigue caused by excessive amount of time on video calls. Furthermore, it can be advantageous when participants have different working patterns.
Also, they give the opportunity for deeper and more considerate contemplation of the questions and responses. This can mean improved results and engagement, as it empowers those who are considered in their responses.
Neither of us are a big fan of post-it notes, as they seem to be a cliched part of the designer aesthetic. (Not to mention the un-sustainability!) One thing that we have both thoroughly enjoyed about working remotely is how well our new suite of tools integrated with our preferred work flow. We used a variety of tools for different purposes:
Although some may say Notion is the best all-in one workspace, we found that the bells and whistles inhibit, a quick and generative process. Paper is clean and stripped back to the bare essentials which let’s the work become the focus.
We can with Kanban! Trello is very popular in the list making and Kanban organisation world. We used this as our adapted ‘product backlog’ where we kept on top of all the work we had to do.
Post notes are fine as long as they’re digital and I don’t have to constantly pick up reams of hair coated stickies from the ground. Miro is a great workspace for visual collaboration and we both really enjoyed working with it. It’s funny to see your partner reduced to a tiny mouse point buzzing around your work.
Zoom you are great! Even though you might be selling our data to the Chinese, there’s something to be said for the experience.
A less formal way of living in each others ear. It’s like slack, except totally free, which is great but also makes me worry, if it’s it free then you’re the product! We then made a class server where everyone made a little desk so that we could recreate the studio environment.
XD for prototypes and for rapid sketching of ideas, it’s really underrated as a collaborative sketch space which is what we found ourselves using it for.
The real hero in our collaborative journey. I don’t know what we would have done without it. Useful for reminders, meetings, understanding each others schedule and easily setting up zoom interviews (which only made us look more professional).
Even though basic af, google forms is probably the best free survey creator out there. Although if we weren’t poor students, we would use Typeform.
Facebook is a great place to find groups of a certain cohort. We found many interview leads and survey respondents this way.