That's what non-US people would call "pizza".
Perhaps "non-US people" is too broad a term.
Delivery guy ain't comin to deliver you a 7 inch diameter pizza (about ~17cm). But when they're dropping off 2+ large pizza then it becomes cost effective.
Plus i'm not ordering a single large pizza and eating it all -- cold breakfast pizza is also good, and will serve me all week.
Two large pizzas feed three to four people if they're all under 30.
When Americans order a pizza, it's typically for a party of 8 people?
(disclaimer: it's my experience. Also, I've only worked for small companies on relatively small projects (a few man-months or man-years), things may be very different in large ones).
So what does it look like? Well, as devs, we have specific feature requirements handed to us with little-to-no prior input, we're always behind schedule so we're never afforded the time and space to do things right, it's always "we'll fix it later". We occassionally have some kind of "our competitor is doing this, we have to do this" piece of work that comes in and shifts all of our roadmap items later of course. No one ever stops to ask whether we're having the impact we anticipated, or whether it's even worth keeping the work.
Combine this with a replatforming-through-new-work effort on the go, you've got a slow mutation from the old platform into an even uglier new platform that doesn't get the right effort applied to it.
But hey, we're "agile", we have mission teams, we have two-pizza teams, we're goal oriented. I mean, we say these things, but in reality it's planned out work, with deadlines, delivered by multiple generic teams named after areas of the customer journey that end up being the center of philosophical debate about whether this bit of work lives with _this team_ or _that team_.
Although I don't think the team size or the number of them is necessarily the problem, the article rings true in my experiences - but it's down to culture of the organisation, more than the topology.
The product owner will create and prioritize the stories in the backlog(plan), the team will discuss and break down a story into actionable and weighted tasks(more planning), then they will fit those tasks into the sprint based on their previous performance(even more planning!)
Following the idea of the iron triangle, with Agile we fix budget and time, but we keep the scope flexible, however, we estimate a scope and refine that along the way.
If you follow an iterative Agile approach like Scrum, given you know your velocity and you have a backlog in good shape, you can work from one milestone to the other.
Agile goes wrong when you don’t get and use good feedback.
You do upfront planning and design, but you only do enough to establish your general course of action. Because good feedback requires context about your goals. If you don’t care where you’re going, then any direction will get you there.
"Signs you’re working in a feature factory" sounds relevant to you. https://news.ycombinator.com/item?id=22335738
Where I work, we happen to have a pretty relaxed management. While they always have a ton of deadlines and always push for more work, they largely don't care about the outcome, so you can just ignore it. Every once in a while something will be actually important, but mostly it's just dumb roadmaps for features that don't add value.
What my team has found helpful is to just ignore those fake tasks, and just create the features we actually believe will be valuable. Hopefully we can leverage our outcomes (and the collected data) to convince management that our way is better. Some day.
> Devs are resources who are paid for by budget that was earned by committing to said roadmap items delivery.
That’s “classical” fixing of all dimensions of the “magic triangle” (scope, budget, time), not agile by any stretch, rather a practice from waterfall management.
I argue that there’s a fourth dimension; quality. How do you see the quality of the teams’ work?
Quality is just a function of the system time to live being fit against the other three constraints. Scope, budget and time. (I'd actually say time is a subset of budget.)
In the case of the book/approach, the problem is that the IT side doesn't match the business side (in terminology, code organization, etc.). The solution is for IT to become more aligned with the rest of the company.
But in the case of your comment and the article, the mismatch seems to work the other way around. Out of some 'two-pizza methodology' or whatever, the business side now has to split up what should be a single problem/domain in a nonsensical collection of different domains.
I might be entirely off here, though. But if I'm not, is this problem perhaps particular to companies where IT is more in charge than in the types of companies where DDD has been a solution?
The two-pizza team concept is also about having a heuristic that tells you when to start looking into how to divide responsibilities between independent teams.
I don't really get what this article is proposing. Never work on projects complicated enough to require lots of engineers and thus coordination? It is not realistic to deliver the complex projects that big companies need to do with a single small team doing everything. It will just never get delivered.
- Enable high-velocity decision making: Defining clear tenets that act as the north start for decision making at team level, and two-way doors thinking.
- Establish how you measure success, and how does relate to the goals of the organisation.
- Achieve team independency is a key factor, and having strong mechanisms such as the "away teams" concept, "communication is terrible" mental model and reducing cognitive overload by relying on platform teams
- Nominating a single-threaded owner for programs and business outcomes.
- Articulate how the organisation works across teams using mechanisms such as bar raisers, OP1/OP2, PR/FAQs, CoEs, WBRs, experiment-driven teams, ...
My company has brought in a lot of Amazon people and ideas, but unfortunately we go this one backwards. "Communication is great." Managers are explicitly encouraged to structure projects to maximize cross-team and cross-org meeting hours.
Looks at Jira and weeps.
The "two-pizza team" is like a squad/section in military organization. It's the sweet spot of having enough people to get things but not too many people so that communication and coordination starts to be a problem.
The point of the article is that if you don't own a problem space you don't own the decision making; you require communication with other entities for their part of the decision. Requiring comms.
Sure, inside the team there is lots of communication, and the business is probably setting the stage on a quarterly scehdule or something along those lines?
I feel that once two teams, no matter how closely related, get the feeling of two different "mandates" (often personified by two managers, sometimes not), it becomes very expensive to keep them aligned. It is probably faster(wrt achieving the end goal) to go with fewer people in one team.
But then actually it's people from multiple totally unrelated teams ignoring each other and taking turns talking at a manager, hoping same manager chooses to hover over someone else for the day and trying to ensure that happens by impressing them with a list of every little piddly thing they did yesterday that no-one on their own team even actually needs or wants to know about.
But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
The military analog is the fire team (3-4 ppl) or the squad (5-14 ppl), depending on how hungry they are and what the current theater demands.
Squads can be assigned multiple discreetly accomplishable objectives. Each squad is assigned to secure a different building on a street, for example.
No one squad is necessarily codependent on the success of the other squads to meet it's own objective, but when you pull back a level, overall organizational success (securing the neighborhood, winning the fight in the city, winning the war) is dependent on the success of all of the squads.
The article argues, and I agree, that as a company grows, it's easy to shift from discrete squads to assembly line squads. Eg data ingestion => data transformation => data delivery. Platoon / company level objectives, not squad level ones.
I have the analogies, but not necessarily and better solutions.
Why it's a bad idea is indeed demonstrated. But why it happens in practice is not just to obey the "small team" mantra. It's also because as organizations and products mature, the law of diminishing returns kicks in: once easy gains have been made, achieving more gains requires tackling more complex problems - either because they are actually more complex in themselves, or because of the environment has become more complex.
> Even though you have multiple small teams, they still need to closely coordinate with each other.
> But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
That complexity actually means that whatever the way you organize, you're going to have more people involved. That's when you need good managers - what I call a good manager is not only competent to manage their own team, they're also good at making their team play in a more global picture without necessarily having a boss telling them to do so.
Another related problem it forgoes discussing is the idea of planning. Once these problems get harder, the need for people to sit down and design a solution grows, sometimes exponentially. Yes, you need good communication, but you also need something to communicate and agree on. How many small teams in big orgs have even a simple design doc to work from?
That's what a competent manager/management is for though.
And perhaps the Product Owner vacuum is filled in the sequel mentioned above.
The other point I was awaiting was documentation. Thank you to the one who at least threw a ransom note into the wiki. My software archaeology project would be impossible otherwise.
Food for thought, at least.
Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
Can someone please explain if I'm thinking of this the right way or not?
Delegating some subset of direct reports seems less like it's about product or technical direction and more about aggregating and filtering management concerns. Presumably the whole team still works on the same thing and plans their work together, it's just that you do half the 1:1s, deal with what you can, and kick things up the chain if you can't.
Looking for some bright minds, agile minds opinions how one should structure and how should Security Team work in an agile organization (100 devs).
Where I agree with the article, for software dev, I am not sure if this will be applicable to Security Teams.
Security Team ideally should deliver "security" of the company, however team cannot do it alone, we rely on other teams (devs for code, devops for infra), employees (phishing) and also need to collaborate a lot.
How would you tackle Security and Security Team in agile organization?
Thanks,
I don't know how your company organizes the security teams, but both at Yahoo and now at GoDaddy the security folks delivered a lot of software. Code scanners, patches rollout, monitoring, etc...
I agree you can't exactly deliver phishing protection, but for example I've seen fake phishing emails being sent by executives, and then the security team measures if employees are taking the bait. You do that every once in a while, measuring if things are improving or not. Maybe there are other angles you can use to approach how you measure the value your team delivers.
You might also think of it not as a team at all, when you are consulting for other teams, you are delivering features as part of that team.
The sponsors in the enterprise client have all moved on.
No one even knows the team was supposed to produce a baby.
This split is eerily similar to Backend, UI, Ops, which is the very thing the author criticized earlier in the post. It sounds like the teams they ended up with just weren't cross-functional teams.
There's another tell, too: "Data-Delivery". What does that even mean? From my perspective, I have zero clue. There's likely a dozen different ways to slice that up into discrete sets of user experiences of features. And then you can organize cross-functional teams around those experiences, like: reliability, visualizations, integrations, etc.
Of course, things aren't always that clean. The real world is much more murky.
You are exactly right! And yet everyone thought they were organized by functions/objectives/OKRs or whatever. The blind spot is what I want to highlight here.
"Data-Delivery" is an anonymization. The team shipped a specific data set that I did not want to name.
two pizza team == organized around OKRs
Whereas the better way to think about it is
two pizza team == cross-functional, lean teams
Seems like an issue around semantics
Small teams that own and are responsible for products. Teams expose any information they need to share via APIs (including data for reports) Teams consume any information they need via other team's APIs.
My experience:
Teams that have 9-12 people on them, all working on different things/products, people external to the team completing some tasks that the team can't do, struggles to prioritize work since there is so many work streams coming into the team, members moving from one team to another, work moving from one team to another
More seriously SAFe is trying to solve a real problem but to actually solve it involves much deeper organizational change because of Conway's law then most people are comfortable with.
I don't think there's any "silver bullets." Humans, are, well...human, and that means there's a lot stuff like emotions, personal motivations, ambition, self-doubt/confidence, team dynamics, etc.
That requires managers that don't just follow buzzwords, but understand the humans they lead, and act as shields between the employees and upper managers that aren't very good at managing humans.
Armies run on their sergeants. The Captains, Majors and Colonels are necessary to implement strategy, and convert into tactics, but if you can't keep your teams trained, focused, and motivated at the sharp end of things, the finest generals in the world won't be able to take on a playground full of toddlers with water pistols.
But then, that's just my experience and opinion. YMMV.
Same thing works for companies. Leadership shapes the company. There is no one-size-fit-all strategy. What works for one company, doesn't work for another. Two pizza team size can work somewhere. Somewhere else something else will. People tend to look for manuals, instructions on how to do things, expecting that someone will write it all down and they just need to do what's written. From time to time, we get to hypes about something (check under microservices for example), everyone use it because it's popular, fancy, buzz word. Without thinking - do we really need this? It's like an epidemic (or pandemic?) of paper pushers, no one wants to take responsibility. To take action. And there is no responsibility if you do things as it's written in the manual, right?
Best methodology is - work with your team. Talk to the team. Know how they breathe. And they will tell you what to do, how to organise them, which methodology to use.
"Take care of your people and they will take care of your business."
The crux of the matter is that as organisations scale up different teams have different "runtime complexity" (if you will).
Scaling up input 2x produces 2x more work for some teams and 100x more work for other teams.
And then we have ourselves the "how do we scale workloads?" discussion on our hands again. If your workload is stateless - you scale it horizontally (more humans).
If you workload is stateful you scale it vertically. I don't know how to scale humans vertically.
> Most developers, especially in larger organizations, complain about meetings,
I would quibble with this though - I think this depends a lot on your manager, your project, and some other things. I've been part of start-ups that have a daily standup that lasted over an hour and involved everyone in the company (~20 people), and the time in my career I had the fewest meetings was when I worked for Dow Jones (not a FAANG, but also not a small company). My experience working for a few different start-ups is that start-ups have as many meetings, they just tend to be more ad-hoc, less formal, and might not always involve a formal Outlook Calendar invitation.
If you have a small team whose members all have a deep understanding of the goal, the strategy for achieving it, where the problems will be, and what trade-offs are possible, then they can achieve a lot with the minimal necessary communication, but you do not get any of that for free just by making small teams - that would just be cargo-culting the issue.
> Before this idea gained popularity, the most common way of organizing teams was in terms of Backend, UI, DBA, Ops etc.. Building any feature required a lot of communication, collaboration, and alignment between all these groups.
I always thought this was called cross-functional and saw the term way before anyone started talking about two pizza/autonomous teams.
I don’t know that necessarily cuts down on “this meeting should’ve been an email”.
And I would often walk past conference rooms to see the TV showing four remote meetings of other two person teams. Which means in that meeting was a ten pizza meeting, IDK if that was the plan.
