How To Build Big Software With Small Agile Teams

How do you scale-up and solve the problems of big software? Big companies creating big software are always trying to figure out how to build it better and faster by “Scaling Up”. There are some really tough problems at the heart of this? How do we scale up software development and keep small agile teams? The principles of software engineering are really at the heart of this - Continuous Delivery, deployment pipelines and autonomy, are what scales in the fastest-growing, most successful companies in the world. So what does that take?

In this episode, Dave Farley explores the trade-off at the heart of scaling-up and describes useful techniques to allow you to scale your big software projects.

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

🎓 CD TRAINING COURSES 🎓
If you want to learn Continuous Delivery and DevOps skills, check out Dave Farley's courses

📚 BOOKS:

📖 Dave’s NEW BOOK "Modern Software Engineering" is now available on
In this book, Dave brings together his ideas and proven techniques to describe a durable, coherent and foundational approach to effective software development, for programmers, managers and technical leads, at all levels of experience.

📖 "Continuous Delivery Pipelines" by Dave Farley

📖 The original award-winning "Continuous Delivery" book by Dave Farley and Jez Humble

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

[timhouse]

How great to have this so clearly presented. I've spent years blending the elements to build the machine without a vocabulary to describe what I was trying to achieve. This channel is my "find of the year" (so far).

[massivescaleconsulting]

Farley is so phenomenal at articulating common sense in a digestible way. The hard part is getting your organization to buy into these core critical concepts - allow more autonomy of your teams to own their own designs, allow repeat work across teams, and allow different teams to work on the same problem with different solutions. They seem costly at face value, yet result in such higher velocity, quality, and most importantly, empowerment and joy of work.

[christophjahn]

One thing that truly stands out for me about this channel, is the discussions in the comments. That is something very rarely seen on YouTube (not that the majority of content lends well to it anyway). Let's keep it flowing :-)

[heifs]

I knew this video was going to be great when I saw you were wearing a shirt from the USCSS NOSTROMO
Clearly a man of culture, great content
Keep it up!

[orange-vlcybpd]

Once in the university i was taught the concept of orthogonality which greatly helped me thinking about decoupled architectures. Orthogonality simply means that when you move up or down some X axis, it should never force change to the Y axis and vice versa.

[jimhumelsine]

One of the best videos of the series so far.

[Gerfervonbob]

It’s interesting to me how universal these sorts of concepts are. I’m not a software developer and I was only watching this video out of curiosity. I have Military leadership training and experience and many of the concepts you’ve explained is directly relatable to command and control and small unit leadership. One of the major features of western/NATO militaries is small unit autonomy. The idea being that a commander back at HQ does not have the same clear situational awareness that a company or platoon commander does in the field. Instead of commanders in the field having to wait for permission to move or act they’re given the autonomy and even encouraged to take initiative since speed and action is critical in combat. To facilitate this there is the concept of “Commander’s Intent” which sounds a lot like what you described in “Bounded-Contexts”. Before an operation you’re briefed on what overall goal or objective is so in the field when a frontline leader uses their autonomy, they do so within the framework of the commanders intent and allow continuous movement to completing their objectives without micromanagement from above.

[emadabushofa]

I love this channel, it's super informative

[georged]

Thank you for yet another very interesting video! This is the best software engineering channel that I have found so far!

I understand the need to let the teams develop at their own pace but I don't understand why large projects are any different than small ones. Why is the development cycle not exactly the same? Collect requirements. Code each requirement in turn in the form of a set of tests. Write production code to satisfy each test. Refactor to keep the code base clean. Repeat these steps until the project is complete. The only differences I see between a large project and a smaller one is that the iteration cycle is longer for the large one (because it is operating on whole modules instead of individual procedures), more people are working in parallel, and the requirements and hence the tests are more general.


What am I misunderstanding?

[amirbolouri]

Thank you very much, dear David for all of your kindness
my exact question and ambiguity that for example i want to post one specific object to another service so how can i abstract it? how can i told another service to post (insert or save) this object for example have some specific fields such as name family image and etc? how can abstract this? this way is wrong that front end developer in another service that call my service to post say to me not exactly this field? in surface my opinion is to use DTOs in my api contacts but this fields are also need to contract between services so when i want to change a bit on these fields i have to change in related services that consume it. this coupling is ok? i overcome on this coupling only with contract testing? or can i improve it?
amir bolouri

[amitev]

I really enjoy listening to such experienced professionals. So many interesting things to learn. Cheers!

[MaitreJedi]

Really good! Maybe a video about this already exist on the channel, but who is in charge of the strategy for the whole solution / software and coordinating all the pieces? Is this person also in charge to give visibility to management without teams having to know what management think or want. Finally, how message about requirements are pass to each teams. Is there a human interface playing this role, abstracting everything that is going on to the team but passing messages about requirements / efficient strategy that other teams have tried / etc… In other words, as for systems, when communications are necessary, is an interface should be use to abstract as much noises as possible?

[bagopila]

It's one of the great videos I have seen so far. Please keep posting videos.

[davemasters]

Another brilliant video.

What's your take on applying "DRY" on tools/processes?

For example, not sharing code between teams, but insisting that all teams use the same CI/CD tools (even the same instance) and insisting all teams adopt the same workflows?

[creadisc]

Man if this was my software engineering class it would have saved me years of useless struggle...

[NeoChromer]

Hi, @Continuous Delivery, Could you please make a video going in depth with Remote teams? Or how can remote teams improve process?

CUrrently I'm facing the challange where I feel like I'm a Freelancerr, however our team of 3 works with a team of 5 which are located in the US (and we are in the UK) but we kinda have some hiccups in communication and planning.

Is there a good solution for this?

[joshheralal]

I'm glad I discovered this channel.

[REDACTD]

Anyone who has been in a management position will tell you that it's much "better" to work with a small team over a larger one. I'd imagine most feel that it takes a special kind of person to manage a large group. From my experience it's simply because it's easier to get less people on the same-page than more.

Factors like how the group feels about one another or the morale of your team directly impacts how well they will work together as a single unit. When you have a bunch of odd-balls, gotta identify their strengths and weaknesses and kind of individually dictate each role to best fit the worker.

One can imagine two kinds of people here:
1) The straight edge engineer guy (who I've always imagined should look like the guy from that move "Falling Down")
-or-
2) That hippy guy with long hair and jeans ( who often exhibits a superiority complex due to being over qualified )

You can't manage these two kinds of employees the same. And, odds are they will not get along well together in the lunch room. You need to personally know each individual - so that one can identify the best way to manage.

Managers tend to make plans based on preconceived ideals of employees. They are thought of as "Employees" not individual people with different skills. In other words: Employee_X should be capable of X_Y_Z. But in the real world, we all know every employee is not worth the same, even if they make the same money.

Nice shirt by the way :)

[seamusmcdonnell]

Theses that chap who said "Small is beutiful" EF Schumacher
There is a college called Schumacher College in Dartington, Devonshire who hold that at heart.

[Sydra.]

Super useful advice for future IT leaders.