Leaving an engineering workshop with smiling faces
There comes a time when two different team of engineers have to join each other to solve a problem. It might be at the start of a new project, or during some migration. A typical indicator is when some group or person has knowledge of systems that another group needs to know. The upcoming task might be so big that it warrants splitting up across multiple people, so getting a helping team onboard with your business requirements and ambitions is pretty important.
At Aftenposten, we’re busy working on a new offering for those living in Oslo. We’ve spent a good few months doing user and market research, along with testing out an MVP, and now we’re ready to start building it for real. Our existing tech stack is built with the help of a central team that maintains the shared aspects so that we can spend more time focusing on delivering product value. The stack is built so that multiple news publications within Norway can use it, so it has a lot of features that we in the Aftenposten product team don’t particularly touch very often. There’s also a lot to integrate with across the rest of Schibsted, like the APIs serving content from our internal CMS.
The secret to any good day of workshoping is planning. I rarely have the full plan in my head when I’m planning, but I’ve spent a good amount of time running workshops and taking facilitation courses. So what I aim for is “what should we get out of this day?”. Typically the answer guides what you should do. If the goal is to get user stories and epics out of the day, then it makes sense to go through sketches and designs, go through user research, etc. Our goal was to gain more knowledge about the technical challenges in implementing user stories that we already had available, so we jumped into the workshop by showing them off, along with the sketches we had. It helps a lot to show something visible - just looking at JSON data or abstract descriptions of tasks tends to convey the message far less effectively. The first of the half the day would be dedicated to group discussions, and the second half to mob programming. We put together some slides prior, with a timeline for the day and necessary background information.
We structured the day roughly around the double diamond methodology, which has been a favourite of mine since I learnt about it, due to the amount of situations it can be applied to. The concept is pretty simple, and breaks down design into four parts: discovery, define, develop, and deliver. In the context of our meetup, discovery was led by going through the history and designs of what we wanted to build, along with some problematic areas that we had question marks over. The goal there was to make sure that everyone knew the scope of the product design, but not to specifically focus on technical challenges. Define was done by group discussions where we broke out into small groups and tried to identify what technical challenges we foresaw with implementation. We didn’t want solutions at this point, just discussions. This is particularly fruitful to discuss with people experienced with the stack, so we made sure we split the most experienced people into different groups. Sometimes a problem can become trivial if someone knows the right route to take. We then did dot-voting to figure out which of the challenges we felt were most problematic, landing on three clear areas that made sense to spend the rest of the day on. An important part of any workday is lunch, so we ate giant slices of pizza before continuing. After lunch we lept right into develop, where again we split into groups to discuss how we might use our stack to solve the 3 top problems we came up. Finally, we spent the rest of the workday attempting to create proof of concepts of how we would solve these problems - we did some self-selection of who worked on what by making one group per problem, ensuring that at least one person from each team was in each group, then presenting our solutions to each other after 1.5 hours of programming.
We ended up with some good demos that helped guide us towards concrete next steps. For example, we managed to see how we might implement searching for things in a relatively straightforward way, and how we might use React in more places than we currently do, with hydration. We made sure to document what we had done, along with things that we should discuss or research further. Our team left in higher spirits than we arrived with, no doubt aided by delicious Polish cusine and socializing with people we don’t get to see often. We’re now more ready for getting deep into programming, knowing what we need to do - and more importantly, who can help us do it.