Why Your Software Team CAN’T Scale

The best way to organise software development is to do it in small teams of people. If you are building big software, you may need many small teams, and then it still won’t work if these teams need to coordinate their work all the time. So how do you scale up software development, and how do you organise to have many small, autonomous teams. The book Team Topologies is a seminal work in this area, describing a model for how to organise software development based on 4 types of teams.

In this episode, Dave Farley, author of the best selling books Continuous Delivery, CD Pipelines and Modern Software Engineering, looks into how to organise software at scale, and how the Team Topologies model works and helps us to design organisations that can produce better software faster.

-------------------------------------------------------------------------------------

👕 T-SHIRTS

This Discount is only available for Continuous Delivery viewers!

🚨 DON'T FORGET TO USE OUR DISCOUNT CODE AT CHECKOUT: ContinuousDelivery

_____________________________________________________

🎓 CD TRAINING COURSE - "CD: Better Software Faster"
If you want to learn about Continuous Delivery, check out Dave Farley's course where you will learn the 7 Essential CD techniques.
_____________________________________________________

The best way to keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers.

-------------------------------------------------------------------------------------
🔗 LINKS

_____________________________________________________

📚 BOOKS:

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 Dave’s NEW BOOK "Modern Software Engineering" is available here

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.
-------------------------------------------------------------------------------------

CHANNEL SPONSORS:

[grrr_lef]

Yes! An episode focusing on platform teams would be highly appreciated! 😍

[valentyn.kostiuk]

I love Idea of "enabling team". Our development leadership one day decided to go to "zero cloudops touch" goal. And gathered team specifically dedicated to improve our delivery cycle. Before we had quarterly releases or so. After half a year of their work towards faster releases we were able to release on demand. Basically we could do it every single day.
And all of that were done even without technology stack switching or even significant changes to platform.
Needless to say in next half a year most teams employed some approximation to CICD. It was not orthodox with only master branch but nevertheless we were moving with a light speed comparing to previous tempo.
For some people it was very hard transition psychologically but we've managed. 😅
Now when I have to deal with teams having that outdated approach... oof, it sends shivers down the spine.

Great video!

[alfredzo]

Absolutely! A dedicated episode for Platform teams

[RasmusPlauborg]

I think book reviews on core books like this one is very valuable. And more broadly, I think discussing organizational structuring is extremely interesting, as it is often what actually brings companies to their knees trying to develop and maintain their software decades later, at least in my experience.

[marioshobbyhq]

I agree on every single world - organisation and architecture go hand in hand. Team topologies book is one of sacred trio, together with DevOps handbook and accelerate.

[exuberantcoder]

Hey Dave! Been reading your new book - halfway through. Just wanted to say that I really appreciate the knowledge you share, especially on this channel. It's given me some new perspectives and confirmed when I'm on the right track.

[pebaz]

I know you said that you don't normally do detailed book report videos on this channel, but this was by far my favorite episode I've ever seen on your channel! :D

I would love more book report or paper reviews to help reduce *Research Debt* by having an extremely experienced person explain it straightforwardly.

[kebien]

YES. Yes I would be very much interested in a video about platform teams

[michaelgharrington]

One of the most valuable episodes you've done yet Dave. Thanks!

[RudhinMenon]

Thank you, this makes so much sense as I have seen different teams. An episode on why some organizations don’t take source version control not seriously would be nice as well, thanks

[mvdam]

Remarkable to see that Team Topologies is now featured on your channel as I’m working with a client where I’m restructuring their teams, using inspiration from this book. The only hurdle at this point is to gain the autonomy for the teams to become fully stream aligned. Will write an article about it once we have achieved this goal.

[BBdaCosta]

Great video, share work in a team is becoming one of the main difficulties in companies, usually what I see are a team of individuals developers doing as they want, without any form or pattern, which leads to a lot of inconsistencies and communications problems. Now I'm anxious to read this book and apply this concept. Thanks a lot.

[josephbrowning]

As an engineer on a "Platform" team, I'd love to hear your thoughts on the subject.

[bernardleclerc]

Dave, I think that I understand what is meant by "platform teams" ... although I am sure that I would benefit from an episode dedicated to the subject. As always, thank you for the time you dedicate to the channel. It is of immense importance to me and my team to learn from others ... and you're one of them Dave !!

[jimmyhirr]

There are often perverse incentives against small team sizes. Career progression for a manager involves managing larger and larger groups of people. And every employee working for one manager is one that's not working for another manager at the same company. So individual managers have an incentive to get as many people under them as possible: it looks good in performance interviews and job reviews. It also weakens their competition for promotion at the same company.

[jimmyhirr]

You can see many of these concepts (although often with different names) in Large Scale Scrum (LeSS). All teams should ideally be stream aligned, and the role of enabling teams is done on an ad-hoc basis. I do like the concepts in this book, though. It seems like it's more fleshed-out than LeSS.

[szeredaiakos]

We had a team of 3 shitting out 140k lines of code in 6 moths. I alone was responsible for 60 of them. Tho it must be said that all decisions put time to market as the primary goal. Needless to say it became hard to maintain very fast. Except my part, which degraded a bit slower because I was actively pushing against time to market. Which put me in a stressful situation, but it was highly rewarding.

So ... massive pressure and brick wall principles seem to give the best results. Next time I make sure I don't break my principles and increase the stress level instead (also ;earn touch typing).

[ChrisSlinkman]

The concepts of a platform team tends to change depending on who you are talking with (Engineering Manager, Architect, Developer). While this was useful to get a concept of the initial ideas provided in the book discussed, a breakdown of where a platform teams responsibility starts and end would be very helpful.

[treyhay]

I just bought your books and should probably read them first! But I was curious how best to do continuous delivery when you have to test against actual physical devices that can't be fully simulated?!?! Love your content!

[roffel]

4:36

It's really good that they chose two different shapes for the data points. But they could really have avoided red and green. At least that's what's written in the caption - then again it seems to be printed in black, though? Maybe they realised but didn't update the caption?

In either case, I wanted to raise awareness for the topic. I think it was around 10% of the (male) population that have a red-green-colour blindness. If you ever colour your charts, maybe spare a thought for those in your audience with a visual impairment. You're likely to regularly encounter them in your audience without even knowing. ❤