Our approach: Minimum Viable Practices
Translating this vision into action requires aligning behaviors with the values and needs of the team. On our team, we made these explicit by brainstorming and voting on principles, as well as drafting a team charter. This enabled us to continually ask ourselves what practices we needed to add or change to enable our vision and to actively collaborate in the design space.
We recognized that forming new habits requires deliberate effort, so we always tried to think of any new practice as a "Minimum Viable Practice". A Minimum Viable Practice is the simplest thing we can do to get the learning we need, with the smallest possible group of participants required to derive that learning. We used real-time feedback and retrospectives in order to improve our practices and to ensure their purposes were still valid. At worst, we just lost 30 minutes to one hour of time trying something we promptly discarded. At best, we learned something valuable and iterated for next time.
By using Minimum Viable Practices that aimed to solve real issues we were facing, we didn’t waste time on ineffective new practices. Our team was always game to try different experiments, because the activities were always timeboxed and outcome-oriented.
Examples of cross-functional practices
What you’ll find in the Design as Team Guidebook guide are over 20 practices of cross-functional collaboration and some of the values and principles that motivated us. We hope these examples give you some ideas for how to translate strategy into tactics for problem-solving.
Here are a couple of examples of how we paired:
Design and Tech Debt Audit
Most teams are familiar with the concept of technical debt, but fewer teams are tracking design debt. Design debt is the set of usability issues relating to whether content is perceivable, operable, understandable, robust, and consistent. At best, it’s a slightly irritating quirk of the UI; and at worst, it can actively prevent users from completing their objectives. The accumulation of design debt can erode user confidence in the system, or worse, in themselves, for not being able to figure out how to move past the issue.
The developers on our team were already quite practiced at managing technical debt from previous experiences, so the effort to introduce a new dimension to an existing habit was fairly low. Developers, quality analysts, and designers would capture both technical debt and design debt as they observed them, and as a group would regularly review and prioritize the collected items based on their understanding of effort and impact.
Paired Solution Exploration
Like many teams at ThoughtWorks, we were accustomed to the idea of “pairing” as inclusive of other roles and activities besides just programming. A common pair was a designer and developer, and the activity depended on who was driving the exploration.
For example, designers and developers sketched together to quickly brainstorm design options while bringing technical feasibility into view. Developers and designers coded together, validated during implementation, and were empowered to make trade-offs on the fly as constraints were discovered. These types of explorations increased empathy between team members for technical and design viewpoints, and fostered a shared ownership of the user experience.
Use our Design as a Team index grid to identify the best pairing techniques for your team.