The project kicked off not in a meeting room or on a whiteboard, but on-site with the users. A core team including the product owner, a business analyst, and a developer went to investigate who the target audience was, how they do their daily work, and which of their problems with the existing solution could be solved by our product.
Throughout the project, we used all sorts of maps to visualize the information we gathered. This helped product and engineering collaborate on understanding the problem space in a more scalable and sustainable way.
After our initial research, we needed to shape the project and identify the best options to pursue. Senior leadership shared their priorities with us in a workshop. Over the course of 2.5 days, we gradually aligned on the scope of the project, discarded some potential approaches, and collaboratively identified the most valuable one for the business.
Most developer teams have a strong focus on solving technical problems. In addition to developers and a product owner, our team was also joined by two UX-designers and a business analyst. That meant we had enough capacity to do both the development work and the required ongoing research to deeply explore the user problems.
The team decided collaboratively what kinds of meetings we should have, how much we wanted to work remotely vs. in the office, and which framework we wanted to use. The most useful exercise here was to discuss our roles and responsibilities. We shared what core skills and secondary skills everyone brought to the team, and what our expectations were of one another’s roles. Immediately, this created a collaborative spirit.
We stayed in touch with the future users of our product in numerous ways, remote and in-person. We enabled analytics and metrics for our application from day one. Releasing a beta version of the app allowed us to get immediate feedback and to identify functionalities that needed improvement.
As we moved from the old system to our new solution, re-thinking a lot of user journeys and changing the architectural approach involved a lot of risks. To mitigate that, we identified the most frequent user journeys and covered those in the new tool first. We created a transition strategy that kept the number of construction sites low.
We extended the developers’ Kanban board to the product team and called it the "Experiment Board". Our UX people, business analyst, and product owner used it to collect ideas, validate them and eventually move them to an analysis and design stage before they were transferred to the production backlog. Visualizing this work proved beneficial in many ways, allowing us to discuss ideas early with developers while also providing transparency and clarity for stakeholders and management.
Besides pair programming with developers, we also paired across roles to solve certain tasks. This helped us appreciate different perspectives, share knowledge, and quickly find the most feasible solutions instead of being blocked due to long back-and-forth discussions.
With the pairing approach, the roles and responsibilities discussions, and the team composition, we were able to create a trusting environment where people felt free to try something new. We actively tried to work on things that were outside our core skills. Everybody felt responsible for the overall outcome and not just their individual contribution.
We got to know each other. We talked to each other. We put our egos aside. And that way we created a social network. This built the empathy, approachability, and trust that allowed us to support each other in not only work and but also in non-work matters when the pandemic hit and we transitioned to being fully remote.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.