In my last post I briefly described three primitives that I felt could form the basis in planning and guiding retrospective activities:

cohesion

vector

waste

This post will focus on the cohesion primitive and is based on cohesion’s essential question: How well is the team working together?

Cohesion is all about the people of the project.

Who is the “team”?

Knowing the boundary marker of “team” is very important when considering cohesion. A failure to include the right people within the boundary can lead to incorrect measures of cohesion - we need to see it as more than the “project team” defined by a budget, a project plan, or an office space.

I’d mentioned that determining the scope of “team” is a pigs and chickens thing. In terms of retrospective activities, it can be useful to scope the team boundary to include not just the “folks working on the project every day” but to also bring in key stakeholders - those whose actions impact the project and/or are impacted by it.

I also enjoyed a comment made by Dave Snowden at a workshop - “critics are often people who care” (paraphrased). We often seek out people who agree with us - it just feels easier. However, we must know where the shadows fall. By ignoring certain people/groups in analysing cohesion we can be laying the ground for tension - sometimes so great that the project is dead and we don’t know it yet. I return to the need for non-binary discussions - people can respond from a black hat perspective (cautionary) but draw out other facets (positives, facts, opportunities, feelings) rather than put them in a dark corner.

Reflecting on cohesion

I’ll present here a set of questions that we could use to reflect on the cohesion primitive.

How do team members communicate?

I’ve worked with teams that talk and work almost all day long but it’s not always noisy - some teams have a steady group chat in systems like Slack. However, the question raised here is more than just about the channel - it’s a very broad “how”:

Are the conversations informal and flowing or regimented and stilted?

Do ideas get tossed around and openly discussed?

Who talks? Who doesn’t? Why?

What unspoken statement is being made through body language?

Which communication tools are being used?

In terms of retrospectives, the day-to-day chatter of team work is an ad-hoc reflection machine. Whilst some methodologies arrange a retrospective at the end of some pre-defined period, you often find that people can’t always think of input items at the time of the meeting.

You’re likely to find that the daily rhythm is actually playing these out and, by listening to them, you’re hearing the live performance and not the “best of” compilation.

How often do team members communicate?

I’ve always liked Alistair Cockburn’s notion of osmotic communication. A team that’s “humming along” likely has high cohesion. Discussions are occuring when they need to across the people they need to. Watch teams that have a lot of part-time members and it really hits you that the lack of cohesion is a deadweight loss on the effort. Team boundaries that are too narrow can drag cohesion down as well - a key user that isn’t seen as part of the team may be exactly the person needed in the discussion.

Project methods and organisational structures can lean heavily towards highly formal - regimented even - communication events. This is especially the case for environments that are highly risk-averse or lack trust. Expecting to maintain cohesion in such environments can lead to disappointment - members start to feel that it’s not worth contributing because they’ll just be told what to do anyway.

Do team members feel confident to raise a concern?

We’d all like to think we work in an objective environment where the best solution wins out. Reality has illustrated to me that this isn’t the case in most teams/organisations. Each individual arrives at work with a background that has built the person who stands before you and a set of goals that move them forward. We’re often told to be rational agents but we’re a sum of our parts and some things are too complex to completely evaluate - we satisfice all the time.

So when an idea is raised, how well is it discussed and, importantly, are alternate views provided and considered? That’s a measure of the quality and the quantity of cohesion within the team. We want the right people contributing in a positive way.

A lack of questioning the status quo may not indicate harmony - it may indicate issues such as Groupthink, dominant sub-groups, or bullying within the team. These issues can be hard to detect so it can be useful to have 1:1 reflections with individuals to help garner trust.

Do people want to be there?

I’m serious - do the team members tell you, explicitly or implictly, that they would rather be elsewhere. I worked in a project where the number of sick days just blew out - people had no motivation to even turn up. I’d almost say that a team can’t be cohesive if they don’t want to be there but that’d be wrong. Rather, you’ll find they become the wrong type of cohesive through bonding over a shared misery.

Conclusion

Reflecting on cohesion asks us to look at the people around us and how they interact. I’ve been a person all my life :) and I enjoy working with other people - especially in cohesive environments with lots of purpose - it just feels like we focus on important things and not trivial annoyances.

Low cohesion is a direct contributor to waste. I’m still working through how to frame cohesion in terms of vector but if feels like cohesion measure how happy the kids are in the back seat of vector’s driving holiday plans. I’ll cover these in a later post.

Some resources

The list below highlights some of the resources that tie into cohesion:

Lately, I’ve been trying to work out a set of “primitives” for retrospectives that can apply to a range of project approaches, IT systems and organisational cultures. The idea is to have baseline concepts (primitives) that can be used to guide thought and discussion. To aid my thinking I decided to present the early thought model here so as to formalise the idea and seek feedback.

Retrospectives are not solely an agile concept and don’t even need to be formally held. You may run a retrospective with the project team every n days/weeks or as a personal reflection with your morning coffee. I’d like to lay out and develop some areas for such consideration.
I’ve come up with three primitives:

cohesion

vector

waste

My feeling is that these three interconnected concepts have utility to teams working on delivering an IT system. You may talk any combination of scrum, waterfall, microservices, legacy, cloud and so on but I think those three primitives are core to the work you do. I’ll delve (briefly) into these in the coming sections and would enjoy your critique via comments to this post. For each primitive I’ll also provide an essential question as the organising focus.

Cohesion

Essential question: How well is the team working together?
This is a people question and it’s vital. The people in a project and how they interact will determine its outcome. How you define “team” is dependent on many things but it’s a pigs and chickens thing - you should primarily include those who have skin in the game in your evaluation but be careful of ignoring the chickens.

Vector

Essential question: How well are we moving in the right direction?
Vectors have magnitude and direction and projects should too. However you describe “scope” (magnitude) you need to make sure you have the right amount - too much and you get crushed. How well you’re tracking (direction) is also important. Some projects are based on a set of deliverables so you evaluate how well the work is going in terms of meeting those deliverables within the agreed timeframe. Other projects are time & material based so you evaluate them in terms of how well they’re meeting client expectations. In both cases your project’s vector is important but is evaluated in different ways.

Waste

Essential question: What gets in our way?Waste reduction is very much from the Lean playbook but is broadly applicable. Analysis of this primitive asks us to look at formal and informal contexts that soak up time and resources without providing any real return on the outcome. Some things get in the way that we can remediate. Some things seem annoying but are critical. Take security penetration testing for example - having to wait for a centralised security team to run the test suite may be wasteful if the project team could run it themselves on-demand. You should still run the test but need to determine if the process can be improved.

Using the primitives

It’s important that the primitives aren’t seen as negatives and are evaluated from different angles. Non binary approaches such as the thinking hats are useful here. You’re seeking to improve, not to blame.

Each primitive is also abstract so you need to determine how they attend to the work at hand. For example, “where do we experience waste?” is not a very useful question. Instead, a project experiencing a lot of system failures (a waste) might ask if their delivery pipeline needs a tune-up.
The team/individual would consider each primitive using the well-trod questions:

What are we doing well?

What have we improved on?

What needs improving?

It’s important to note areas for improvement and track progress in resolving them. Naturally, the team can’t solve everything so prioritisation is the key. It’s also important to celebrate not just the delivered units of work but also the improved work processes.

Conclusion

I’ve outlined three retrospective primitives and how they can be considered. I’m still thinking through possible additions. I also recognise that there’s a coupling across those that I have listed. For example, low cohesion is wasteful as information isn’t flowing through the team.
I’d enjoy your feedback.