The ambiguity of team work

We had one job

Imagine there is a group of individuals, building a product.

Not a "legacy", not a "greenfield".

Something in between. (what does it mean legacy, anyway?)

They follow agile practices - stand ups, retros, grooming sessions, planning sessions, and so on.

You can feel the scrum in the air.

Cross-functional team, they say - three software engineers, a QA engineer, an architect and a product owner.

They have a backlog, a sprint goal, and a definition of done.

They have a product vision, a roadmap, and a strategy.

Everything.

A new feature wildly appears!

One day, the product owner comes to the team with a new feature request.

It was in the 5 year plan, but it was not supposed to be developed now.

The team is excited, they start to discuss the feature.

And they started.

Pete took DLS, Bob took BCS, Jim took the new UI and Users Service, and Mike started to prepare the UI tests, according to specs prepared by Alex and Paul.

Everyone got busy pretty quickly.

If we joined their standups, oh boy, we would hear buzzing!

Buzzing, reviewing and...Waiting?

As the sprint progressed, PRs started emerge and waited to get reviewed.

Pete finished part of the DLS but was waiting for Jim to finish the UI, so he could integrate his changes.

Bob pretty quickly started drowning with BCS and eventually got a call to review Jim's PR in Users Service, as Jim wasn't sure about the changes he made.

Turned out that there was a part of BCS that wasn't according to the diagrams prepared by Alex which needed clarification between Bob and Alex.

UI was almost ready but Pete was still waiting for Jim to finish the last part of the UI, so he could integrate his changes.

Mike prepared the UI test cases and was waiting for the UI to be ready.

Paul was waiting for the feature to be ready, so he could show it to the stakeholders.

After clarifyinig the BCS part, Bob could revisit some design issues he found during his "coding" session (coding? you might be interested in The ambiguity of code).

PR in Users Service was almost forgotten, as Jim was still struggling with the UI but turned out that there a technical debt inside, and it seemed a good moment to clean it up.

Paul wasn't happy about it, especially that there was not much progress in the sprint.

Jim was a bit hesitant about the UI, as he wasn't sure if it was according to the specs prepared by Alex and Paul.

There was a path in the workflow that made UI pretty unusable so it required some re-thinking.

And then Bob got sick.

BCS - anyone?

Bob was sick, so Pete was asked by Alex to take care of BCS.

Pete resisted as he didn't have DLS finished and still he was waiting for the UI to make proper integration.

Alex was a bit frustrated, as he didn't expect that Bob would get sick.

Paul wanted to prioritize the UI, as it was the most important part of the feature.

And prioritize BCS as it was almost finished, according to Bob, before he got sick.

Paul and Alex had a discussion about the priorities, and they decided that Jim should finish the UI first and Pete should take care of BCS, as he is waiting for UI to be finished by Jim.

Mike was still waiting but got asked to test BCS as soon as possible.

"Wait, what does it mean not according to the specs?"

Well, as BCS got finished, it turned out that there was a part of the service that was not according to the specs prepared by Alex.

Pete was a bit surprised as he did everything according to what they agreed on at the beginning.

Paul got mad as he wanted to show the feature to the stakeholders and now it seems that BCS requires major rework as it does not work according to the specs.

Mike was eager for testing but he eventually understood that his test cases are not valid anymore.

And UI design changed which required UI to be changed as well.

"It will took 4 days to prepare new test cases", Mike said.

Paul decided to ask a principal software engineer, from another team, to help with the BCS.

Tim, a principal software engineer immediately jumped into BCS, without asking much questions.

"Alex told me everything I need to know", he said.

THE PR

Tim asked Pete to review his PR, as he worked with BCS already.

231 files changed.

It took 3 full days of reviewing - during that time there was no movement in UI, in Users Service.

But there was a lot of discussions about SOLID, variable naming, programming styles, object orientation, and so on.

Tim was a bit surprised as he thought that the PR was pretty straightforward.

Pete got a bit angry as he couldn't finish DLS - he even had a crazy thought to jump into UI code and do fixes but he wasn't skilled with Next.js or whatever meta or teta framework they had.

"You are a senior dev, come one, you can do it", Paul said.

Time was running and Pete decided to put "LGTM" on the PR.

Finally, BCS got merged, woohoo!

Tim got back to his team, as he was borrowed for a few days.

Thanks to this waiting time, Mike prepared some test scenarios for BCS and started testing.

Jim continued the UI work, and Pete still waited to finish DLS, so he started thinking about taking something next from the backlog.

BCS - Buggy Custom Software?

Well, something wasn't according to the latest specs by Alex, as Mike reported after doing his QA part.

"Seems like Tim misunderstood some things...", Mike mumbled.

"You should fix it, Pete", Paul said.

"Guys, I finished the UI part so Pete can integrate DLS", Jim mentioned.

"Well, it might take some days...", Pete commented.

"What?! I thought you are familiar with code as you did a code review.", Paul counter-commented.

"Team work"

Does it sound famililar, dear Reader?

All people were busy, all people were working.

Each day, they "reported" their progress.

Seemed that everyone was pretty productive.

PRs, reviews, discussions, meetings, coding, testing, designing.

But the feature was not ready.

Why so?

Could we name this group of individuals a "team"?

No doubt that each of the people progressed with their tasks.

This looked as a highly collaborative environment, wasn't it?

The ambiguity of team work

It's about heads, not hands.

It's about understanding, not just doing.

As very smart people noticed already, typing is not a programming bottleneck.

With the advancement of technology as automated typists, like LLMs and friends, the impact of "this problem" decreased (a bit).

Similar to "the system isn't just a sum of it parts", the sum of the work done in isolation does not equal the work done in collaboration, when it comes to knowledge work

Superposition of isolated increments does not give the superposition of increments done in the collaborative way.

Crucial aspects is when this superposition happens - skilled and brilliant minds should work together and let the collective knowledge emerge during the collaborative time.

How often do we see PRs with more than 50 files, heck, 20 files, that just capture the snapshot of the context that someone created during the work in isolation?

There was the thought process which yielded understanding/knowledge, and eventually got represented "in the code" (what am I talking about? Please check The ambiguity of code and The ambiguity of application).

Syntactic checks, rambling about SOLID or something similar - LGTM is almost there.

Typically, we have abundance of code but scarcity of understanding.

Is it really true that we are able to build even the 1/10 of another person's understanding by just reading the code, even if we get a "clarifying call"?

Heads, not hands

A single letter makes a huge difference here.

As we saw in this tiny tale, queues and waiting time were a "subtle" consequence that emerged from this style of product development.

Someone agrees upon something here, someone else changes the assumptions there - quickly things get out of sync.

Cross-functional teams might not mean over-specialization - the flow of the knowledge, between "heads", contributes to the flow of the work (will it?).

"Damian, are you nuts? Working like this all the time?", you might wonder, dear Reader.

I like to say that there are some dangerous words in the world, like "always", "never", "everytime", "all" and so on.

I don't believe it is possible to work like this all the time.

There are things that should be done in isolation but at least they could be discussed together.

I am not an expert to tell anyone what to work but I firmly believe that it greatly matters on the context in which each of us operates.

If you do a next level CRUD app when there is almost no complexity - does it make sense to sit together, always?

Maybe not.

What if we work on the core functionality that spans, within team's ownership boundaries, across the whole system?

Wouldn't it make sense to collaborate on it in real-time (virtually or on-site)?

How much knowledge might be lost if we decompose work on entire feature?

As we discussed some time ago, The law of eventual composition still applies and question is if one can compose "knowledge gaps"?

Integration problems never cease to exist (I used dangerous word, buckle up) but what if we could reduce them or even get rid of them by working together?

Overmind, "the head"

Of course I didn't come up with those ideas and observations by myself.

I stand on the shoulders of giants, like Conway's Law, The Goal and The Software Teaming, and just want to share my thoughts and personal observations.

I read somewhere the following quote, it was something like: "when two people are working together, in fact there are three people: the third "person" is the overmind".

This "overmind" is the collective knowledge that emerges during the collaboration.

Isolation does not give same kind of experience.

Even though we might be able to "mimic" the experience by working "collaboratively" with LLMs and friends, this "overmind" won't happen to materialize itself, invisibly.

Overmind - overhead?

If you ask me, dear Reader, whether we should always pursue this kind of working - my answer is going to be simple: Well, I can't really say, but yes.

Hail to the King of Kings - the context.

One need to be aware that it requires changing attitude, it has its costs (e.g. psychological, like letting of the ego) and for sure will impact perception of the work itself too.

What benefits do you see, dear Reader?

What are potential downsides?

And remember: