A short piece on multi-disciplinary teams
Preventing cross-functional teams from becoming dysfunctional teams
Multi-disciplinary (or cross-functional) teams are generally regarded as fundamental to the ambition of delivering valuable product increments — but this concept is often misunderstood.
The intention is to bring together a small team who are able to deliver against an agreed product goal. In order to do this, the team must contain all the skills required to autonomously deliver the required functionality. This may, for example, include user experience, development and testing. But crucially, the work does not necessarily travel through each discipline sequentially. If anything, it’s often best to start discussions with the minimal technical solution and then gauge how viable (or not) this is in terms of the user experience. This ensures that the discussion begins from a position of feasibility and that creativity and usability can emerge from all team members.
But essentially, the team works collaboratively against the objective represented by the user story. This ensures the minimization of waste (designs, wireframes, test plans, etc) and handoffs between the disciplines.
In order for this process to be effective, the user stories must be written in a way that allows each story to be addressed collaboratively. Thankfully, writing stories from the user’s perspective allows this to happen. Users don’t see (nor should they care about) your wireframes, designs or test plans. Their only interaction will be with the working software the team delivers. One sure-fire way to break this process is to write stories from some other party’s perspective. If a story begins with “As a technical architect…” the solution might be an API which, in isolation, delivers no value to your users. It has to be combined with another user story, creating a dependency which can result in cascading delays; increasing amounts of work in progress; and is perhaps more difficult to test and automate.
By framing stories from a user’s perspective the team are also encouraged to take shared responsibility for the story’s success. As opposed to the accuracy of a wireframe, the detail of a test plan or beauty of a design — each of which may or may not contribute to the performance of the resulting working software.
But if stories are delivered without necessarily creating designs, wireframes, etc then how do we ensure consistency and efficiency across the product or service? This is where ‘guardrails’ can help. These are principles, guidelines, rules and even templates that each discipline ensures the software adheres to.
So, from a User Experience standpoint these are likely to be the Experience Principles which might include “Encourage scrolling”, “Don’t ask unnecessary questions”, etc. The creative design equivalent is usually a Style Guide, which may be ‘emergent’, in that it is an output of the development process. Similarly a Component Library could ‘emerge’ from the Front End development. When combined the Style Guide and Component Library not only ensure consistency, but also enable the reuse of code and concepts. And where a new solution or treatment is required and agreed upon by the team, it is added to these documents, which continue their evolution. From a technical perspective there will also be coding standards to adhere to and more holistically the agreed accessibility standards the software will support.
Collaboratively agreeing these guardrails and then making them explicit allows the multi-disciplined team to focus their energy on what matters — solving the user’s problems and meeting their needs.
.
