Discipline Fusion

Content is sourced from https://github.com/robertfmurdock/TeamCoaching/blob/master/DisciplineFusionAssessment.md

Pull requests, edits, and feedback are welcome.

Discipline Fusion Assessment

Here are some tests that one can run in order to determine whether a multidisciplinary team is operating is a “fused” manner.

But first! Let’s get some terms down.

Terms

Team - A group of individual people working together to achieve an outcome.

Project - A set of work that intends to achieve an outcome. A team works on a project.

Product - A valuable artifact, created or maintained by a team. A project may create a product, update a product, or create more than one product.

Discipline - A distinct branch of knowledge used to perform work on a team.

Fusion - The state in which a team is integrating multiple disciplines successfully.

Stories - A discrete slice of work that can be performed. Stories are preferably written from a user’s perspective.

Tests

Access Time

Do all the disciplines integrated on the team have instant access to each other?

Regular Interdisciplinary Contact

Do individuals working within a discipline have meaningful (project-related) encounters with individuals working in other disciplines at least once throughout the day?

Shared Conceptual Model

Do all the disciplines share the business object model and use it to communicate concepts? When the model needs to be updated, do they solicit feedback from the perspective of the other disciplines?

Common Project Story

Can every member of the team tell the story of what the project is, and why we’re doing it?

Implementation Autonomy

Does the team have sufficient authority to make core implementation decisions? Is there a discipline or responsibility that’s been outsourced that regularly causes work to be stopped?

Line of Sight

Do all team members have clear visibility as to what the rest of the team is currently working on, including in other disciplines?

Discipline Elasticity

Can every individual member of the team leave for weeks without causing a hard block?

Personal Collaboration Discretion

Are team members ever penalized for stopping their own story in order to help other team members (regardless of core discipline)?

Comprehensible Work Plan

Do the stories on the project deliver strategic, experimental, or tangible value? Do they communicate to stakeholders what they’re intended to achieve?

Discipline Depth

Are all of the disciplines needed for the project represented with enough depth for the project to be successful?

More Perfect Fusion

After a team has asked and answered all of the questions posed by the tests above, they will probably be looking for ways to improve. This section will consider each of the tests, and make suggestions about how a team can improve.

Improving Access Time

Having fast access to team members is a major factor in team performance and success - the sooner misconceptions can be corrected, debates can be aired, and work converged, the easier it is to give a project a unified, coherent voice. The principle of continuous integration applies to concepts, design, and language just as much as it applied to technical components.

Given this, a common solution for access problems is to co-locate the entire team, and have a norm of working from the co-located space a super-majority of the time. By at least getting people into the same space, you have removed the first barrier of inaccessibility - “out of sight, out of mind”.

This isn’t a cure-all solution. Even in open offices, teams can develop cultures of “invisible walls”, and these can take a number of forms. Some quick examples of invisible walls:

Team members wear headphones for long stretches of time
Team members work too far from each other for a quick ‘across the room’ question
Team members respond negatively to requests for a pop-up collaboration session

The underlying goal here is that we want teams that have a culture where:

It is always ok to ask for help or feedback
It is always ok to respond with “I can’t immediately but is it ok I reach out to you in a few minutes”, or “I think this other team member might be better suited for your question, let’s loop them in”
It is not ok to discourage team members from reaching out, even if becomes a point of stress
It is not ok to ask for assistance in a rude or entitled way, or in any way insensitive to the subject of the request

These suggestions are built from this premise: investing in the team is investing in the project’s success. We will trade personal performance in the moment for overall team performance in the longer term.

Physical co-location isn’t the only way for teams to succeed at “Improving Access Time”. Some teams require a digital “co-location” approach. In order to make this work, this also requires very strong norms. Where a physically co-located team may define “core hours” that people will work on site, a digital “co-located” team may define “core channels” through which a super-majority of team communications must flow.

That is to say, rather than having a room with a shared audio space where people can overhear each other, the team may have a chat channel where all project discussions occur, in a public space, so that there are opportunities for incidental overhearing. It is very important to minimize the number of channels the team operates through, because additional channels can easily create the same “invisible wall” problems that physical co-location has. And of course, nurturing the culture of being “available and interruptable” is just as important on a digitally co-located team as it is on a physically co-located team.

### Improving Regular Interdisciplinary Contact

Its not uncommon for team members working within specific disciplines to begin to cluster together, both physically and socially. There are a number of natural causes for this behavior, and it shouldn’t be considered negative unto itself - those discipline-specific relationships are the most important on a team, because they help ensure that the discipline as a whole shares a common vision.

That said, when these clusters “harden”, the team as a whole becomes less unified, and rather than sharing a common language and customs, the clusters develop their own independent languages.

The goal of improving regular interdisciplinary contact is to create space where team members from each discipline can interact regularly and predictably, giving them opportunities to reinforce shared language, customs, and goals. This also helps share knowledge of the strengths of the team.

Some tools that have been employed to improve and encourage contact are:

Scheduled Stand up meetings

A stand up meeting is a short meeting (5-10 minutes for typical size teams, max 15 for large teams) to temperature-check what’s going on. A stand up meeting should include at-least every member of the team, and should have some unscheduled time available afterward for follow-up conversations. Stand up meetings where there are non-participants may not be delivering the intended value - if someone attends a stand up, they should participate, whether or not their current work is considered ‘relevant’ to the group. This is because the essence of a stand up meeting is discovering the unexpectedly relevant, and thus habits of self censorship are to be avoided. By the same token though, this is why deep dives and explorations are inappropriate for stand up and should be expressed in other meetings / rituals.

Story Acceptance Contact

Another way to reinforce meaningful interdisciplinary contact is to make part of the team agreement that “representatives of the other discipline(s)” are required to declare a story “complete”. In this way, all work that is completed has to be described and understood by at least one other discipline, thus reinforcing a common understanding. Various flavors of this can be used depending on the shape of the project.

Periodic Role Swap

Another technique that can be used is to periodically move someone who works in one discipline to a different discipline. While they will have to be a junior member for the duration of the swap, this will give them the beginning of an insider understanding of what the discipline does, and the tools they use to perform the work. Of course, this should only be done to the degree it can be without adversely affecting the performance of the team.

Strategic Collaboration

Oftentimes, core design decisions for the product will need input from all the relevant disciplines. To ensure that all points of view are represented, create a planning cadence such that representatives of each discipline can assist in creating the story plan. Sometimes this kind of work is singular enough that it is appropriately written as a story to be executed by multiple disciplines together-as-one. It is very easy to accidentally ‘freeze’ a discipline out by assuming their motives, so addressing this problem is important.

Improving Shared Conceptual Model

Operating as a unified team hinges on creating and nurturing a common project-related language. Each project evolves a series of concepts and nouns that describe its landscape. These will frequently relate to describing a process that the project is intending to improve in some way. This set of terms and relationships is a conceptual object model, more commonly known as a business object model, and must be easy to comprehend for the users of the product. It is important for the object model to be well curated because it ultimately becomes the language of the product. Properly understood, this model is and must be a shared artifact that all disciplines use in order to execute work - because the model is fundamentally abstract (it should be easily regenerated with a white board and a marker), versions of it will appear in all artifacts related to the project. For example, the model will be expressed in:

Value Stories (at the absolute highest level)
User Stories
Product mock-ups
User interviews
Software user interfaces
Hardware user interfaces
Source code
And even more.

It’s fairly easy for disciplines to fall out of sync on their understanding of the the object model. For example, the design group’s understanding of the users can easily run far ahead of the software development group. Or, a converse example, the software development group may have to modify the model because some of the relationships were too loosely defined, and they failed to test those changes back against the design group’s understanding. Given enough time and weak communication, small differences in the model’s understanding can lead to inconsistencies in the product that have a high user impact. They can also sour a collaborate relationship between disciplines into a negative adversarial one.

So what to do? How does a team get better at this? A few suggestions follow.

Gathering together a workable (and disciplinarily diverse) subset of the team, and brainstorm to think of all the “nouns” associated with the project. Depending on the depth of the domain, this may take a good amount of time, so it’s probably good to timebox each session to about an hour. This is a good time to do some preliminary grooming - if two terms mean the same thing, see if the group can cull one of them. The nouns may be referred to as “business objects”, “domain objects”, or “entities”. After coming up with an initial list of nouns, the next step is to start illustrating the natural relationships between these entities. The goal is to force the relationships to be strict, and thus clear. In order to bring some of that rigor, make sure that the quantities of the relationship are expressed - for example, a “kitchen” can have “n” plates; a “plate” can hold zero or one “dishes”. This numerical relationship can help clarify how a team may be using the term slightly differently.

You’ll want to run these exercises periodically with your team (in various configurations). Over time, the team should be able to illustrate the entities and the relationships in a very short amount of time, and terms that were once controversial should become normed.

There are follow up exercises that will help test and exercise this domain model as well, including storytelling (using the model to describe a user’s way of interacting with the model), event-storming (formalizing how actors interact with the domain model by formalizing events and commands used in the user’s story), and deeper product visioning (exploring the “what will have to change about this model in two years” problem).

### Improving Common Project Story

If your team is having trouble telling the story of the project, the problem usually starts at the top. Every project has one or two people who effectively are responsible for owning the project - they are responsible for the investment in the project and thus must know the underlying reason for the investment. If the person perceived to be the “owner” in this sense does not fulfill both of these responsibilities, then it is probably time to find the true “owner”, or find a way to bring those responsibilities to the expected owner.

But knowing the product owner is just the beginning. In theory, the person acting in this role should be able to give you a high level version of “why the project exists”. Usually, the first versions of this story will either be hyper brief, or, more commonly, excessively scattered. An engaged product owner will often have so many ideas about the potential of the product that listening to them explain it can confuse the listener.

To help find the story, work with the product owner to find the center tent-pole value. What is the core feature that gets them excited? And, as a follow on, what are the kind of people the project is intended to help? And do they know people in that category personally? Broadly speaking, you should be able to summarize the whole project as “we’re going to help PERSON do TASK…” followed by a description of how the project will improve or make possible the task at hand. Every project has one of these at its center, though it is normal and appropriate to have other derivative projects with their own statements in the periphery. While these stories are relevant, it’s important to ensure that the main story of the project centers around one core piece of value. Because if the center does not hold, then the other stories will have to shift as well.

Getting a short and strong version of this story into the heads of the team is the next step. Generally, it should be impossible to overdo this. Building versions of the story into natural team rituals can go a long way here. Some examples:

recapping the story at the beginning of any iteration review
Using a micro version of the story as a stand-up sign-off
In any story card review meeting, always rhetorically justify the story card by connecting it to the big story.
Putting versions of the story on physical artifacts in the team space, with iconography reinforcing it
setting aside regular all-hands meetings to recap and Q+A on how the work connects to the story

None of these techniques are mandatory - they’re all just tools to help socialize and communicate that high level story. At the point where they feel onerous or oppressive because the team already knows the story, switch or remove the tool you’re using. If they feel painful because the team does not believe that story, then there’s a deeper problem at hand and your team has probably entered into the proverbial “death march”. Dealing with that situation is outside the scope of this paper, but is worthy of further discussion.

*NOTE Feels like this section needs to use the term persona somewhere

### Improving Implementation Autonomy

Its a common story - week after week, stories are blocked because of a handful of things your team feels powerless to change. And the longer it goes on, the less invested in the success of the project your team gets - how could they be invested, when the work they do can be rendered meaningless in an instant. Worse still, the teams knows that all the blame for when the product has problems or fails will fall square on their shoulders, despite their best efforts.

Responsibility is a two way street - if the team is going to be blamed for a problem, then they need the power to address the problem. When a team finds itself in the aforementioned situation, consider clarifying the powers that the team needs in order to eliminate the underlying issue. If there are things the team feels it is not allowed to change, then the team must acquire the authority to change these things. The process of doing so will look different organization to organization, but if this power/blame discrepancy is not addressed, it will be a source of decay in the team until the project ends. Consolidating this power should actually be a higher priority than technical work to fix or work around any problems (within reason - do not allow your customers to suffer). This is because there will always be another patch or emergency work-around, but a team unable to deal with root causes may make things work with intermediate fixes, and foster deep long term problems.

Having gathered the authority to make changes, the team will need to consider some high level options:

Are there alternate vendors for the feature provided by the blocking resources? What are the costs of switching?
Would the team be better served by providing the feature itself (by absorbing the existing system, or by building a new one)?
Can the feature be eliminated entirely?

Note that all of these questions should apply to any kind of externalized functionality - be it interface design, hardware design, software integrations, or QA. Some of these can be disciplines that have the option of being folded into the team… but keep in mind the effort required to properly fuse. It is good and appropriate for things that have clearly defined independent scope to be outsourced… right up until it becomes critical for the project and/or an unreliable resource. By critical, I merely mean that trying to separate the design of a project from the implementation of a project into two teams is fundamentally inappropriate because, at their core, they are the same project and the team composition should reflect that. A more appropriate example of outsourcing might be having a team that provides a SSO product, that may integrate into a different product. Because SSO is merely a feature of the different product, it has a coherent demarcation between the two systems, which allows more independence and substitutability (using other SSO vendors, for example).

### Improving Line of Sight

By “line of sight”, we don’t simply mean that team members can easily see each other - we mean that the team has meaningful visibility into the work that is currently being done, and how it is going. Therefore when speaking of software teams, merely being able to see the team in person actually does not get very far in solving the problem of knowing what’s going on, though it does help with getting a read on how its going - for example, you can tell that people are agitated, or frustrated, or happy and productive fairly easily. Teams generally use some version of a “project board” in order to help solve the “visibility into what people are doing” problem. The core idea of the board being to represent visually the work that is currently being performed by the team. In order to make such a tool possible, it requires a team agreement regarding the following:

How many states of a story will be represented? e.g. “in-progress”, “Complete”.
What do these states mean?
Who will update the state of stories as they change?
Where will it be positioned such that it delivers the intended value?

By implication, this means that in order to provide “line of sight”, each discipline’s work must be represented on the project board in a comprehensible fashion. Sometimes this can be challenging! Oftentimes disciplines that are new or underdeveloped will not be able to represent their work as stories very clearly; they will need to practice to find a flow that works for them. But the rewards are clear - teams that can rapidly and truthfully see what’s happening.

Now, just because a team has a project board does not mean that they’ve successfully implemented it. Some issues that can plague a project board and cause it to substantially drop in value:

The project board is in a location that is rarely trafficked by the team, and thus people rarely look at it incidentally.
The team is undisciplined in keeping the board up to date, and thus it actually provides a false indication of the current work of the team.
The stories are unclear, and therefore mislead the reader as to what is happening
The board is not big, visible, simply, or persistent enough to “read well” as an overview

Seem familiar? These kind of problems tend to be “forgettable” problems… they’re frequently not painful enough to remember to address or attempt to fix them. Because of that nature, teams can operate for a long time with dysfunctional or low-value project boards and they can easily fall into the trap of “this is just how we do it”. Because the project board is fundamentally a communication tool for the project, its should be owned by the team’s “delivery” discipline, and thus they should regularly test that its producing the intended results - “line of sight”.

But work visualization isn’t everything. Teams are made up of humans, and humans have other dimensions than is represented on a story. Another tool that is typically engaged in order to improve “line of sight” is creating a “stand-up meeting” ritual.

The “stand-up” ritual is a flexible ritual created to achieve the following goals:

To create a touch-point in the work day in which the whole team can take a breath and see each other face to face.
To create a space where less-dominant voices and personalities are able to participate without having to fight for their time.
To get a flavor of what everyone’s doing and how they feel about it without drowning in details
To organically discover unanticipated connections, in the way that only making a human connection can
To create a welcoming space where visitors can learn about the team and meaningfully participate themselves, giving them an honest taste of what its like to be on the team.
To give people an opportunity to be reminded of other team members they may need to have a discussion with (and the time in which to do so)
To do all of this with as little disruption to the work day as possible, ideally doing the whole thing in less than 15 minutes.

Where the project board is the concrete source-of-truth for what the team is doing, the stand-up meeting is there to connect to who the team is. An active listener will be able to learn a lot of practical information from a healthy stand-up about what the team is struggling with, they will probably be able to guess the roles people are playing on the team, and for the most part they should have heard the names of the team.

Stand-up is like any ritual though, and without paying attention it can deliver a lot less than its intended value. Some common problems:

Team members feel the need to detail absolutely everything that happened since the last stand-up. This usually happens because team members are confusing a stand-up meeting with a “status meeting”. If this is happening frequently, its possible that the project board isn’t fulfilling its role as representing the true state of what’s going on with the team. This can also be an indication that team members believe that they will be judged harshly if they do not demonstrate “business”. Improving clarity of how progression works should alleviate this concern.
Team members “filibuster” and monopolize the time. This can be a difficult problem to unwind, and hopefully some minor direct suggestions can alleviate this issue. Sometimes this can be persistent, and more innovative techniques can be tried. Its worth recounting that the underlying reason that the “stand-up” meeting is titled as such is because “standing-up” was intended to be a natural timer… people stand up, and after about ten minutes of that they want to sit down and end the meeting. Some teams have added additional parameters (after discovering this soft incentive was not quite enough) - they added a “stand-up token” that firmly established the “only the person with the token is allowed to talk” (a very empowering technique to make sure everyone gets their time)… and they made the “stand-up token” heavy. By making the token heavy, they signalled to the speaker that things should move faster. While these techniques clearly can’t work for all teams, that spirit of innovation is to be encouraged.
Stand-up is an unwelcoming environment, and guests/outsiders are discouraged from participating. This can be a tough nut to crack, because it speaks to the team’s culture and the purpose of the meeting. Leadership is key here - make sure the team understands why stand-up is important and distinct from other team rituals and processes. Make an effort to regularly include someone unexpected in stand-up to teach the team that being straightforward and welcoming is important.
Stand-up does not start until xyz person has arrived Because stand up is not intended to be mechanically necessary, it is inappropriate for a stand-up to be cancelled because specific people will not be in attendance. It is also inappropriate to wait for more than a minute to get started. The meeting style should be clear and simple enough that every member of the team can run it. Of course, if team members do not attend stand-up or disrespect the ritual by showing up dramatically late, then the team will have to coach those members on etiquette. Consider setting an alarm to get stand-up moving, so that the nature of the ritual will be de-personalized and feel more immediate.
Stand-up needs a predetermined leader. This really is counter to the intent of the ritual. When it happens, it can tend to evolve from teams with remote members - having a shot caller can make it easier to deal with remote participants. If this is happening, experiment with rotating the “master of ceremonies” role each stand-up. You can also experiment with ways to eliminate the role entirely (passing a virtual token, for example). The more a predetermined leader is necessary though, the more likely the meeting will devolve into a status meeting.

### Improving Discipline Elasticity ### Improving Personal Collaboration Discretion ### Improving Comprehensible Work Plan ### Improving Discipline Depth

RoB Murdock