On Mob Programming Part Two

Jan 09, 2024 - Profounder

Management: We still don’t like the idea of everyone working on one thing. It just seems inefficient and expensive!

Is what you’re currently doing working?

How are the old ways treating you?

Are you continuously delivering high-quality value with clear expectations on your ROI(s)?

What is all of this actually costing you?

We can do better. We must do better.

We will be more effective together

As mentioned previously - On Mob Programming: Part One - we delved into rethinking what cost means and how teaming can help reduce cost and bake quality in from the beginning.

If you’d like to dive deeper into any of the following points, please see Woody Zuill’s book on Software Teaming. What follows pulls heavily from the source material with our own thoughts and experiences applied.


The Cost of Hiring

Hiring new people in organizations large and small inevitably leads to long periods of getting them up to speed. They must learn about how the team works and simultaneously understand what the business does. This is potentially a dead period of low value. It’s not always simple and it’s certainly not enjoyable. It is most definitely a waste of time and money if there are better ways of getting new hires up to speed.

What are the costs here? Can you identify them? See them?

How would you go about understanding them? Measuring them? Addressing them?

Do these costs show up on your P&L? Doubtful.

Why is this considered acceptable when there are clearly better ways?

The cost of getting the new hires “up to speed” depends on how large the dumpster fire is and where all the “load bearing” bits are in the code. It also depends on how well your teams actually function together.

What if the new hire sees behind the curtain and bails? How much time did you just waste? Your time. Your money. The time of other workers that were getting them up to speed… Speaking of other workers… What about the cost of pulling on their already valuable time? Time probably spent fighting unnecessary fires created by a dysfunctional system… but that’s a different soapbox.

What about the difficult to quantify and mostly unknown cost of low quality during the new hire’s onboarding period?

Beyond the “up to speed” period, what about the point at which the manager decides the new hire is ready to start contributing on their own? It is more than likely that they still know very little of the business and that most of their onboarding was focused on getting their tools set up, how to deploy code, and probably not much else. The probability that they are going to cause harm or introduce risk is high.

So, left on their own, they aim to please. After all, it’s what we’ve been taught since childhood.

They will no doubt give their “best efforts” and no doubt those efforts will not be at the level of quality they could or should be had the new hire been introduced to the mob from day one. Contributing immediately. Asking questions. Learning. Perhaps their novice curiosity leads to better understanding of something the team hadn’t thought of or revisited.

The benefits are striking.

Bonus Round: Potential hires. You can leverage mobbing as a way to interview and as a way to see how well new hires might work with the team. Immediately. They can get in there and code right away. Your team doesn’t have to step away to conduct interviews. They are still delivering while interviewing and trialing a potential hire.


The Cost of Leaving

the-mob-lives-on

Workers will come and go. The Mob lives on.

What about the costs of workers leaving?

Will the team rally and continue to deliver the same level of quality?

How much knowledge will they lose when that worker - or workers - leave(s)?

Management will certainly expect things to continue on (as is tradition). We’ve got deadlines to meet! Let’s pause here to recall the first point about onboarding, and tie in that bonus round about mob interviewing, interning, and hiring… Progress does not have to stop in this team-based approach. You just have another person hop on the wagon and see how it goes. Again, rethinking the cost savings of this approach, management should be more than happy with it.

Back on topic, when workers leave in the Individual Contributor on a Team model, the following will go along with them:

Some amount of information. Huge amounts of (likely) siloed knowledge. All of their wisdom.

Most firms attempt good ‘ole “knowledge transfer”, usually referred to as “KT”, as if to normalize it even further and reduce the “we’re completely fucked if that person leaves” feeling that creeps in.

We’ll call this the Cost (or Risk) of (Individual) Experience. It is folly to think you can transfer all of that experience from one person another, let alone the rest of the team.

Expect an immeasurable and unknown drop in skill level and quality, assuming it was even a priority to begin with.

People are not machined parts, and they are not replaced in that way. You do not just “hire another Sally or Bob” to replace the Sally or Bob that left. However, if they were a part of the mob, the knowledge, experience, wisdom, etc., is all embedded in the mob.

The only scenario in which you would suffer similar losses to the siloed worker leaving is if the entire mob left. This is far less likely to happen. If it did, you may need to take a deeper look at how you are running your organization and its teams, as this is probably indicative of a greater systemic illness.

The list goes on here, but at least we’re thinking about it now… Impact to team morale (immediate and longer term), impact to culture, and impacts unknown.


The Cost of Single Points of Failure

Engineers love to talk about how to avoid single points of failure in software systems.

Shouldn’t management think more about the bus factor of software teams?

The business (including software consulting firms in this) tries to squeeze out every bit of “productivity” they can from the Individual Contributor. Without deeper understanding it seems to make sense from a basic cost accounting perspective.

But what happens when - not if - that individual makes mistakes?

If they are the hero with all of the knowhow, then they are the only one who can fix the problem. A problem that they most likely created. Under conditions most likely created by short-sighted management that believes in an encourages such heroism. If they are the only ones that can work on the esoteric parts of the software then there is even more risk, and cost, to consider.

Let’s reflect on this more deeply.

Not only are they the “only one that can work on it”, but because of this, they are inevitably going to work on it alone.

If they created the defect by working on it alone, do we really think that having them work on it alone again is somehow going to improve the system? This alone may be one of the main reasons you should practice pair programming at a minimum if not mob programming.

There is no simpler example than this. Code reviews don’t fix this. Remember, inspection is too late. The quality is already there.

Teamwork fixes this. Scratch that. Teamwork prevents this.

Be proactive, not reactive. Create better systems for your teams and achieve more effective and valuable results.

To follow on the above, because management loves talking about productivity and utilization… What exactly is the rest of the team supposed to do in the above scenario?

Act as cheerleaders fawning over the hero yet again?

Go work on “other things” and create even more problems and introduce red herrings while the hero is inside the burning building?

Stop the madness. Stop the foolishness.

Think about cost more deeply.

If the team is a team, let them work together like one.


The Cost of Late Integration

Continuous Integration should be considered a standard practice at software organizations of any size or shape - from startups to enterprise.

Note: We generally don’t like the term “best practice”, but that’s for another series of posts.

While there have been a number of posts along the lines of “GitFlow Considered Harmful” (we don’t disagree), what most of them offer up isn’t exactly much better. They usually create yet another fabricated branching model that creates code distance.

Instead, we are big proponents of tried-and-true Trunk Based Development as it dovetails nicely with Continuous Integration practices.

Without delving any deeper into the above topics, it is and has been known for decades now that the cost of integrating code later only increases the time it takes to deliver and exacerbates the time and cost of fixing defects.

cost-of-change

Waterfall jokes aside, it would be nice to see this chart reimagined with Software Teaming and how much the curve flattens.

If we’re utilizing a software teaming or mob-based approach, we see the following:

Continuous code review effectively eliminates typos and simple errors in the code at the time it is written. It also encourages open conversation between the developers, analysts, business, testers, users, and anyone else on the team. This leads to inherent quality and no wait time when questions arise.

Continuously integrating our changes means that the software is always in a releasable state and enables other practices, e.g. Continuous Deployment and Delivery.

We avoid the absolute nightmare of “merge hell” that comes with integrating innumerable feature branches trying to piece together a release. This is bonkers. Focus on one thing. Implement it as a team and ship it. If a defect still slipped through, it’s quick and easy to fix it and move on. Remember: real agility.

The biggest benefit may be that the Users are receiving value on a continuous basis - all day every day. In a mob setting, they can actually see it and contribute to its definition and development removing anything unexpected once things are in the wild.

We reduce the number (and cost) of defects because we’re all working together and focused on the deliverable. Short of saying it will eliminate defects entirely, as it will substantially reduce them, we can most assuredly say that the cost of fixing them and time to fix them is greatly reduced as is the stress on the team.

Instead of fire drills and blaming individuals, the team shares ownership since they delivered it together and they resolve it together - reinforcing the lesson(s) learned as yet another bonus.

Note: Other practices such as feature flagging, branch by abstraction, dark launching, et al., should also be considered but are beyond the scope of this article.


Parting Thoughts

Yes, context is king and as mentioned in Part One, we will acknowledge again that this is no panacea or silver bullet. Rather, it is an effective way of working that should be considered and properly understood before it is dismissed with the same ignorance that pair programming and TDD are dismissed.

There are many more topics and reasons we could delve into specific to Mob Programming - and we will. These are but a few of the many things to consider when thinking more deeply about cost and justifying the practice.

Hopefully this post shed some light on how Mob Programming will save on cost in the long term, introduce quality from the beginning where it belongs, and lead to healthier, happier humans doing their best as a team.

If any of the above points ring true with your organization or team(s), let us know and we’ll be more than happy to help.