Independence, autonomy, and too many small teams
kislayverma.com
kislayverma.com
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.
> 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.)
If you're not publicly traded and made an announcement about something going live on a certain date, or have a regulatory body that requires something by a certain date, your deadline is just a cost-cutting measure.
Is it in scope for this to be maintainable? To be stable? To have a nice UX?
Scope generally determines feature coverage, not quality or how long we expect to use the system.
"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.
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 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!)
Agile works (when it works) because it treats software as a complex system that is best studied and modified through experimentation after accepting a high initial degree of uncertainty (which is slowly reduced through the creation of knowledge). The only comparable things in business terminology are investment and risk. Each iteration (I hate "sprint") needs to be treated as an investment with some risk percentage of failing completely. Until the money is handled that way, business people will keep expecting to get exactly what they think they're paying for, exactly when they feel they were promised they'd get it.
Me too. It sounds exhausting.
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.
But in a lot of organizations upper management asks middle management when those features will be delivered so they can plan client communications or internal teams around that.
It's my understand that would not be considered agile.
If someone tries to get you to believe something and part of that belief is the active suppression of certain types of thought, and those types of thought are what actually make us intelligent. Then in some regards, agile is trying to make us less intelligent. It might be accidental, it might be unintended, but it is there. Agile attempts to create a social norm where certain thoughts are banned. Yet our ability to anticipate and predict the future is one of our largest defining traits.
There are some aspects of agile that have cult like qualities. I think agile has _improved_ many software teams and projects, esp with how those teams approach planning, but it is still important to be cognizant of thoughts that have been removed from view.
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.
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.
Looks at Jira and weeps.
Our team of four (frontend development for our two main products) has a "team leader" (not included in the team), two "product managers" (one for each product) and a "director of IT" (our actual manager), none of which have a background in software development. They all have a background in our product's domain.
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.
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.
I think that's where you and the other commentator are talking past each other. Amazon tends to have great managers and senior ICs that get the responsibility and technical divide right.
My experiences outside Amazon unfortunately point towards this being hard to get right in the first instance, and really really hard to fix once it has gone wrong.
You can make quick decisions because you don't have to communicate with a large group. You don't have to communicate with a large group because you own your space. You own your space because you have clear external interfaces.
If the external interface needs to change (from your side or the other side), it requires external communication and is probably slow, so you (and the other side) try to get it right the first time and minimize changes.
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.
- 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.
I would love to hear your experience adopting Amazon mechanisms.
Disclaimer: I work at Amazon. I help customers to adopt some of those mechanisms.
Food for thought, at least.
Consciously applying Conway's to identify communication boundaries sounds like a good way to get there.
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
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.
But I can't find the next post in the series which proposes a better alternative. Anyone else had better luck?
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.
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?
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.
Yes, it's a tourist trap meal. We here in Chicago really do like deep-dish pizza, but many of the more famous brands exaggerate the thickness because it seems as though tourists prefer it that way. A typical Chicago resident isn't going to buy one like this more than once every few years, unless they have visitors that insist on it.
You eat it with a fork and knife. Despite the huge amount of cheese and sauce, a good one will have a really crunchy crust and it should be so good that you consider it one of the best parts of the pizza.
The flavor/preparation/ingredients are what make a good Chicago-style pizza and not the thickness. In more residential areas, you'll have pizza shops where the deep dish pizza is no more than 1 inch, which is really what a Chicago resident buys for themselves (but the thin crust is most definitely purchased more frequently).
I think you did the math wrong?
Area is pi x r^2, which for a 16" pizza would be pi x 8^2 = pi x 64, which is right about 200in^2
A few of the pizza places around here offer 20" pizzas, which would be pi x 10^2, or pi x 100 = 314in^2, which is actually big enough to feed a couple people.
That said, whenever I read "two-pizza team" (a term I've never heard before), I assume that means 4-5 people at most.
And a 2 pizza team is the number of people you can feed lunch to with 2 pizzas.
Most people would do 1-2 large slices for a lunch, so 4-8 maybe 10 people is a 2 pizza team.
About the same size range as a rifle squad.
When Americans order a pizza, it's typically for a party of 8 people?
That's logic, that is.
Two large pizzas feed three to four people if they're all under 30.
I'd say 2 pizzas for 6-8 people is totally fine assumption.
Almost all the by-the-slice places I've been to take slices from their large or extra-large pies. The only exception I can think of would be Pinup Pizza on the Las Vegas strip (30 inch diameter pie).
That's what non-US people would call "pizza".
You don't go out to a restaurant and order a "personal salad" or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth).
I get it! It's just a funny idiosyncrasy :)
You sort of do. There is a distinction between salads intended for the table to share, salads intended as a single person;s entree, and salads intended as a single person's accompaniment.
> or even a "personal lasagna" (even though the restaurant obviously makes a whole tray's worth)
If I saw "personal lasagna" on a menu, I would expect something that was baked as a single portion. Otherwise, I would expect a portion cut out of a larger tray. Essentially, "personal" here is a reference to the size of the unit that was prepared and cooked and not merely the serving size.
Same with pizza. I expect a "personal pizza" to be a complete pizza that is reasonable for one person.
Perhaps "non-US people" is too broad a term.
That's really surprising to me, but interesting to hear!
EDIT: well, with the exception of the occasional event/party organizer, but that applies to all foods.
In fact, US pizza chains struggled here until they started localizing and adding more foods to their menus!
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.
(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).
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.
> 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.
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,
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.
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.
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
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.
A 6' tall 160 lb man who does vigorous exercise 5+ times a week needs 2500-3000 calories per day to maintain weight.
So if you're still hungry it's because you didn't eat much else all day. Or you're training like an Olympian. Or you're on your way to getting fat. Or European pizzas are low in calories.