Why Your Software Team CAN’T Scale
Вставка
- Опубліковано 7 чер 2022
- 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
Do you like the t-shirts that I wear in my videos? YOU CAN SAVE £2 ON EACH ORDER from Qwertee via this link ➡️ bit.ly/3yUwvYC.
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.
➡️ bit.ly/CDBSWF
_____________________________________________________
You can get a FREE Advice Guide from Dave Farley about "Pair Programming Patterns" when you sign up to our CD Mail List ➡️ www.subscribepage.com/cd-pair...
The best way to keep up to date with the latest discussions, free "How To..." guides, events, online courses and exclusive offers.
-------------------------------------------------------------------------------------
🔗 LINKS
Team Topologies Website ➡️ teamtopologies.com
Dunbar's Number ➡️ en.wikipedia.org/wiki/Dunbar%...
Emily Webber on “Social Group Sizes & Impact of Dunbars Number” ➡️ emilywebber.co.uk/social-grou...
Conway’s Law ➡️ en.wikipedia.org/wiki/Conway%...
LMAX Disruptor ➡️ lmax-exchange.github.io/disru...
_____________________________________________________
📚 BOOKS:
📖 "Continuous Delivery Pipelines" by Dave Farley
paperback ➡️ amzn.to/3gIULlA
ebook version ➡️ leanpub.com/cd-pipelines
📖 Dave’s NEW BOOK "Modern Software Engineering" is available here
➡️ amzn.to/3DwdwT3
📖 The original, award-winning "Continuous Delivery" book by Dave Farley and Jez Humble ➡️ amzn.to/2WxRYmx
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:
Equal Experts is a product software development consultancy with a network of over 1,000 experienced technology consultants globally. They increase the pace of innovation by using modern software engineering practices that embrace Continuous Delivery, Security, and Operability from the outset ➡️ bit.ly/3ASy8n0
Octopus are the makers of Octopus Deploy the single place for your team to manage releases, automate deployments, and automate the runbooks that keep your software operating. ➡️ octopus.com/
SpecFlow Behavior Driven Development for .NET SpecFlow helps teams bind automation to feature files and share the resulting examples as Living Documentation across the team and stakeholders. ➡️ go.specflow.org/dave_farley - Наука та технологія
Learn how to work as a highly functional software development team with helpful tips in my FREE guide to "Organising SW Dev Teams" which you can get here ➡ www.subscribepage.com/organise-teams-guide
Yes! An episode focusing on platform teams would be highly appreciated! 😍
Absolutely! A dedicated episode for Platform teams
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.
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.
YES. Yes I would be very much interested in a video about platform teams
One of the most valuable episodes you've done yet Dave. Thanks!
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!
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.
One of the best yet Dave thanks.
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
Great video! Besides the communications overhead in larger teams, I also wonder how much the defect rate is a function of code familiarity - with a smaller team, there's a higher probability that a given developer has worked on or is even familiar with a given piece of code, so they're more likely to know the nuances and "gotchas" inherent in working with that code. I'd imagine this is especially true in teams that practice pair programming, and perhaps to a lesser degree with other review processes like pull requests.
It also strikes me that what is often described as a "DevOps role" is really "DevOps enablement". Certainly in the company I work for, the "DevOps team" are the people who build and maintain a set of consistent tools (such as automated build pipelines) to which stream-aligned teams have access without requiring them to go as in-depth on the intricacies of building and maintaining those sorts of tools.
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.
You're very welcome!
Great episode thanks Dave. I agree with your minimum team size of 4 although I have seen teams of 2 be extremely effective at times too. I doubt it warrants its own episode but I was wondering what would you suggest as a good team structure in a small startup that is trying to build several different things at once (rightly or wrongly) and experiment and learn fast? Anything you've seen work well in this situation in the past? Thanks a lot!
As an engineer on a "Platform" team, I'd love to hear your thoughts on the subject.
Nice video Dave!!
Great episode dear Dave thanks a lot
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.
There's no reason for that. There's since long ago proper engineering practices in place for software development. Architecting, design, requirements elicitation.
Don't listen to those "flexible" people telling you don't need it. Yes, you do, we all do. Is for our own peace of mind. Sucks to work without those.
Superb video - thank you, Dave!
Thanks Matt, and thanks to you and Manuel for a great book.
Excellent video
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.
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.
I wish you success in getting the teams fully stream-aligned. I'd be interested in seeing your article reporting the results!
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 !!
I'm glad you find my videos useful - thanks for watching!
Thanks for another great video Dave! Yes, please do a video on how to design effective platforms, the market need it :)
Thanks for the suggestions about doing a video on Platform teams. I think its a good idea! I will put my thinking cap on...
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.
Love it!
Hi David! I'm in charge of a platform team and I'll appreciate it a lot to get your opinion and advice about that.
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).
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.
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!
Well, you simulate them! 😉 Tesla do it for their cars, and SpaceX for their space-ships (as well as many others). If you take this approach to its logical conclusion if changes how you design the HW (for the better) to make it more 'testable'. The problem that makes HW difficult to test in nearly always down to concurrency, so limit the way that the concurrency leaks into the SW to make the SW more deterministic. It's a complex topic, but ultimately all HW talks to SW as a stream of bytes through a port, so it is possible to simulate.
Even if this only gets you part of the way, that still means that you can do a more thorough job of testing the SW for that part.
Plus one for platform team topic.
Keeping teams responsible for every part of the product should be taught more. Too often, I see teams claim to be Agile but yet they have separate roles for people. Some are coders and others will test the code. This anti-pattern of throwing the code over the fence to have someone deal with the testing of it is a bad idea.
We need to have developers write tests and the code. TDD works best for this. We do need to make sure that the tests are reasonable by having others review it.
Golden words but that's generally not the case. Actually, that's rarely the case.
Where I work we have T-shaped engineers, where some are more focused on dev and some are more focused on writing automated integration tests, but anyone can write anything. All code commits include unit tests, but on top of this the integration tests are intentionally written by someone else so that they don't make the same assumptions and have no knowledge of the implementation. All of these engineers are in the same team, work closely together, and there is no wall to throw code over.
Agile (or Scrum or whatever people call it) is more of a problem than a solution in this scenario
Thanks!
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. ❤
Great video
Very very interesting topic and book
I'd love to see a video focused on platform teams.
Re platform team video, yes please. I’ve created a platform team and they’re focusing on the pipeline, architecture and environment automation. They’re creating a huge amount of value but I’d love to know if there’s something I can be doing better. WRT Team Topologies, I’ll dust it off (metaphorically speaking, it’s on Kndle) and work through it. Thanks for the prod!
Thanks for the suggestions about doing a video on Platform teams. I think its a good idea! I will put my thinking cap on...
Best SWE content ever, thank you 🙇
Hello, Dave. Thanks for the video.
What do you think about Price's Law, could it be a part of the reason why the scaling doesn't work well?
I don't know, from my own experience it seems that as orgs grow, the best people spend more and more of their time fixing mistakes rather than doing new things, which is a big problem. Not sure if this is related to Price's law or not, which says that a small number of people have a disproportionate impact on results "10% of people produce 50% of results"
I'll appreciate dedicated platfom team episode :)
Thanks for the suggestions about doing a video on Platform teams. I think its a good idea! I will put my thinking cap on...
As a member of a platform team, I would love have a dedicated episode!
Thanks for the suggestions about doing a video on Platform teams. I think its a good idea! I will put my thinking cap on...
Hey! I don't like to dig into code (Java, Spring, etc.), but I like to read about concepts, approaches and architecture. Maybe you can suggest a direction where you can work with concepts, but not dig into the code?
The problem with this is that there are people who can work with concepts, approaches and architecture AND dig into the code. So you would have to convince a company to hire you to work on just the architecture when there are plenty of people who can work on both the architecture and the code.
What's your opinion on a stream aligned team with multiple hand overs within the team?
For example ux creating big upfront designs then passing them to mobile app devs, then to BE Devs and finally to manual testers.
I dunno if it's semantics but you could class each role within the stream aligned team to be its own team.
From your description, I think that is what you have, multiple, tech-function-aligned, teams. Sorry, but I think this is a common anti-pattern.
@@ContinuousDelivery Yeah that makes sense, thank you.
Off Topic: I took the T-Shirt deal, but it is 2 EUR off per order not per Shirt!
On Topic: once again a great video!
Apologies for any misunderstanding. Yes, it is £2 or 2Eur off per order. You can do as many orders as you like and get the discount off each - but it may not make sense with postage costs.
@@ContinuousDelivery seeing that all their other deals are only 2€ off per order, I guess that is just a given fact.
It is still an acceptable deal though.
To jump to sub-topics:
Intro (start) ua-cam.com/video/pw686Oyeqmw/v-deo.html
Fun t-shirts: ua-cam.com/video/pw686Oyeqmw/v-deo.html
About the book, Team Topologies: ua-cam.com/video/pw686Oyeqmw/v-deo.html
The aim for this episode: ua-cam.com/video/pw686Oyeqmw/v-deo.html
Team size: ua-cam.com/video/pw686Oyeqmw/v-deo.html
The Dunbar Number: ua-cam.com/video/pw686Oyeqmw/v-deo.html
How we structure and Conway's Law: ua-cam.com/video/pw686Oyeqmw/v-deo.html
Common anti-pattern -- lack of team autonomy: ua-cam.com/video/pw686Oyeqmw/v-deo.html
List of expected capabilities of an autonomous team: ua-cam.com/video/pw686Oyeqmw/v-deo.html
3 other types of teams: ua-cam.com/video/pw686Oyeqmw/v-deo.html
The Platform Team: ua-cam.com/video/pw686Oyeqmw/v-deo.html
Summary: ua-cam.com/video/pw686Oyeqmw/v-deo.html
The study about team size is discussable. It is a correlation but not a causality probably. Teams of 20+ are probably more likely to be outsourcing teams with less qualified people than teams of 5, that could explain also the difference.
If you actually go to people who study statistics, Andrew Gelman for example, but there are others, none of them support the statistical methods used in these studies to derive the conculsions.
These publications are for academic software engineers using methods that only their field accepts.
And if you look at their other qualifications, it's not so surprising either. Fred Brooks managed a project at IBM which was a total disaster, Kent Beck was at a project at Chrysler that was the basis for his XP methodology which, if you ask the company that paid him, was not successful. Dave here has some experience building software at a software exchange in London.
But look, I'm far from the most well-known software engineer, but at my previous job at a Brazilian bank, I was at a credit card software project that reached around 3 million accounts, and the automation I ran aproved more than 1 billion BRL in credit. If I wanted to go around showing my resume citing studies with weird statistical inference and telling people how to manage teams, according to the standards of this field, I am completely qualified.
There is no manager in the world that would agree with paying an enabling team. Nowadays managers think that a software dev should be a dev, a tester, a PO, an innovator, a rockstar, an open minded dude that proactively reacts when decisions endanger the project. Someone that does everything with boy scout rule. It's the dev's fault that he was not convincing enough, if the project fails in any way. And all these must be done in a sprint, with less than 13 story points otherwise it's unacceptable for 2 weeks, too out of the ordinary sprint velocity, which is calculated when the least is known about a feature. Agile should be reconsidered. Scrum should be buried.
Edit: I believe in team topologies! :)
"There is no manager in the world...", "Agile should be reconsidered"... okay, calm down :) Team Topologies has been written based on what works in the real world. I have worked in at least three companies where we had enablement teams and followed the models suggested in the book and it worked really well. My current company is also adopting that model. I am working in the Developer Experience team. I think you must have worked with some crappy managers (not uncommon) that have seriously burned you out, and that's a shame. Also, Agile is not Scrum. You can work in agile ways without sprints and story points. In fact, it's advisable, in my opinion, that teams do so. It's not Agile that needs to be reconsidered; what needs to be fixed is the "Agile theatre" in so many companies.
💯this! Agile theatre. as practiced by most companies and most orgs that claim to practice Scrum, is not the same thing as agile practice, and is certainly a long way from my preferred approach of Continuous Delivery. Enabling teams are common, and normal, in good orgs.
Yes please add platform team video
Platfom teams video please!
Platform teams providing supporting modules and features to stream-aligned teams, such that these teams can build their platforms on their own, is my understanding in this regard. If thats the case, I'd like to have an episode on that so speak with my boundaries at work as I think we use the platform team to just throw change requests over the fence, sitting as developers their waiting for the rollout, which is not the best case in my opinion. If thats not your understanding of platform teams, I'd still appreciate the episode to have a new perspective and speak with my boundaries at work about it. ;)
Platform teams and YAGNI Problem would be interesting topic
Thanks for the suggestion - I think that could be a good topic for a future video.
You may find this video helpful on the topic of YAGNI - ua-cam.com/video/8GONv6jJsG0/v-deo.html
Platforms are kind of weird to me. An episode on the topic would be great.
Thanks for the suggestions about doing a video on Platform teams. I think its a good idea! I will put my thinking cap on...
Gold
Haven't they got a kind of like a bigger like button or something on YT?
I think you found it, thanks 😎
Great content once again Dave, its always good to get your viewpoint. Is there anyone else out here that you think is worth following? Anyone else have any suggestions of youtubers that are worth a subscribe?
I think I have worked you out, you take something that is one sentence (and obvious to anyone who ever coded a single line) and then you make it into a 20 minute video.
I wish you had used a less off-putting title. Anyone who needs this info is already thinking their team structure is good and their team is scaling 'as well as could be expected' and they dont want another person telling them its not.
First
so long you are going to promote weak books ( like the Team Topologies ) I will downvote your videos. Also, I would greatly appreciate it if you started your videos with your content instead of ads. Thank you.