Here are some additional patterns to consider when Scaling.
For now, consider that I am using a narrow definition of scaling, to mean only, collocated teams working together on one product in a fairly tight way.
1. Upfront Work.
To over-simplify, if we create any product, we plan, we build, we release. That is the simplest pattern.
And, often, especially with 'greenfield' products, we have to do some 'upfront work' along with the planning. This is true even with one Team. I call that work I-A-D. Infrastructure, Architecture, and Design. There are many names for it, and the exact nature of the work can vary a lot depending on the nature of the product. And god knows, there are lots and lots and lots of variations for how people are doing this work currently.
There is so much to say about I-A-D. Let me say only a few things here, today.
One, we must keep it small, but which now I mean mainly small in duration. It is so easy to 'take-off' 6 months to do a perfect architecture, as an example.
Two, it must be tested incrementally. All knowledge work should be tested quickly after the knowledge is created. And re-tested and re-tested.
Three, as we scale, we must accept that, ceteris paribus, we usually need more of it than with a
smaller effort. Or an effort with fewer people. It, for example, has to be documented somewhat more.
Four, we want 'everyone' in the 3 scaling teams to know 'everything' about the I-A-D. Well, as soon as I say that, you see our dilemma. Getting all 21 people on the same page about the I-A-D is a 'knowledge management' nightmare. But, as soon as we have scaling, that's what we want. So, using common sense, we do things to help the knowledge appropriately spread throughout the Group (the 3 Teams).
Ok, for today I feel I have said enough. Good people, with common sense, can execute on those ideas. But it is true that many of us need more detailed patterns, even for only 3 teams. More on that later.
2. Coordination of Sprint start and end dates
In general, it appears to be a good pattern to have all Teams in a scaled group start and end their sprints on the same day (or days).
Why? Well, they have to be coordinated together. In part, this means that they must receive feedback together. And then use this feedback together.
Yes, I entirely understand that this pattern, as much as it helps, also presents problems. How do you actually do it? What is the same person needs to be in 3 meetings at the same time? Etc, etc. Still, it seems to be the better pattern.
Both in theory and in practice. If it makes you feel better, think of it this way: this pattern sucks the
least.
3. Changes to Sprint Planning Meeting
As soon as you scale, you want all 3 Teams in your Group to be at one Sprint Planning Meeting. But then you have roughly 25-30 people in one meeting, and a meeting that size always sucks.
So, what to do?
Clearly (from experience) you cannot have each Team working alone, in their own Sprint Planning Meeting with no 'outside' influences. Also, clearly, having a whole day meeting with 25-30 people is very very hard.
The usual solution is to compromise. That is, spend part of the day as a Group. And part in individual Teams. I like starting as a whole Group. And ending as a whole Group. And maybe a middle whole Group meeting where you review the stories selected for each Team.
4. Changes to Sprint Review
As soon as we scale, and we want to have the Sprint Reviews for each Team on the same day, someone says: "How can we do that? We need the same people, or many of the same people in every Sprint Review?" Which usually is a correct observation.
So, we use common sense. There are many similar answers, but I'll suggest what my colleague Catherine Louis calls the Science Fair approach. You probably did this as a kid. Each kid or team had a table in a large room, maybe the cafeteria. And all the parents would file in over 2 hours, and the judges too, and look at each of the 'exhibits' or 'experiments'. And go back and forth.
And that is the idea.
So, each Team continuously demos its features. At a separate table. And the CPO (chief product owner) and the POs (the product owner for each of the 3 teams) and the BSHs (the business stakeholders for all 3 teams) all move from table to table, trying to see what has been done, how it fits together (or doesn't), and deciding how to give the best feedback.
And in fact, team members also shuttle amongst the tables, trying to see what has been done by our Team and the other Teams, and how it all fits together and what it 'means'.
As you can see, doing this well requires some skill and experience. And you can imagine the self-organization that also takes place each time. And in ways that cannot be predicted. People will see issues and identify inter-relationships that could not have been anticipated beforehand.
In any case, hard as it is (and in some ways, it is easy), we recommend the Science Fair approach. It takes somewhat longer, but it pays dividends.
We also recommend that each Team have a short 'review' discussion. And that the whole Group have a 'review' discussion. Probably a short Group review at the beginning, and then again, at the end, to review the overall feedback and its implications.
If only scaling were simpler! For that matter, people! You know, if we could only get rid of those pesky customers, things would get a lot better real quick!
That reminds me of the most important advice about scaling: KISS. Or, as Einstein perfectly expressed it: "All things should be made as simple as possible, and not simpler."
For now, consider that I am using a narrow definition of scaling, to mean only, collocated teams working together on one product in a fairly tight way.
1. Upfront Work.
To over-simplify, if we create any product, we plan, we build, we release. That is the simplest pattern.
And, often, especially with 'greenfield' products, we have to do some 'upfront work' along with the planning. This is true even with one Team. I call that work I-A-D. Infrastructure, Architecture, and Design. There are many names for it, and the exact nature of the work can vary a lot depending on the nature of the product. And god knows, there are lots and lots and lots of variations for how people are doing this work currently.
There is so much to say about I-A-D. Let me say only a few things here, today.
One, we must keep it small, but which now I mean mainly small in duration. It is so easy to 'take-off' 6 months to do a perfect architecture, as an example.
Two, it must be tested incrementally. All knowledge work should be tested quickly after the knowledge is created. And re-tested and re-tested.
Three, as we scale, we must accept that, ceteris paribus, we usually need more of it than with a
smaller effort. Or an effort with fewer people. It, for example, has to be documented somewhat more.
Four, we want 'everyone' in the 3 scaling teams to know 'everything' about the I-A-D. Well, as soon as I say that, you see our dilemma. Getting all 21 people on the same page about the I-A-D is a 'knowledge management' nightmare. But, as soon as we have scaling, that's what we want. So, using common sense, we do things to help the knowledge appropriately spread throughout the Group (the 3 Teams).
Ok, for today I feel I have said enough. Good people, with common sense, can execute on those ideas. But it is true that many of us need more detailed patterns, even for only 3 teams. More on that later.
2. Coordination of Sprint start and end dates
In general, it appears to be a good pattern to have all Teams in a scaled group start and end their sprints on the same day (or days).
Why? Well, they have to be coordinated together. In part, this means that they must receive feedback together. And then use this feedback together.
Yes, I entirely understand that this pattern, as much as it helps, also presents problems. How do you actually do it? What is the same person needs to be in 3 meetings at the same time? Etc, etc. Still, it seems to be the better pattern.
Both in theory and in practice. If it makes you feel better, think of it this way: this pattern sucks the
least.
3. Changes to Sprint Planning Meeting
As soon as you scale, you want all 3 Teams in your Group to be at one Sprint Planning Meeting. But then you have roughly 25-30 people in one meeting, and a meeting that size always sucks.
So, what to do?
Clearly (from experience) you cannot have each Team working alone, in their own Sprint Planning Meeting with no 'outside' influences. Also, clearly, having a whole day meeting with 25-30 people is very very hard.
The usual solution is to compromise. That is, spend part of the day as a Group. And part in individual Teams. I like starting as a whole Group. And ending as a whole Group. And maybe a middle whole Group meeting where you review the stories selected for each Team.
4. Changes to Sprint Review
As soon as we scale, and we want to have the Sprint Reviews for each Team on the same day, someone says: "How can we do that? We need the same people, or many of the same people in every Sprint Review?" Which usually is a correct observation.
So, we use common sense. There are many similar answers, but I'll suggest what my colleague Catherine Louis calls the Science Fair approach. You probably did this as a kid. Each kid or team had a table in a large room, maybe the cafeteria. And all the parents would file in over 2 hours, and the judges too, and look at each of the 'exhibits' or 'experiments'. And go back and forth.
And that is the idea.
So, each Team continuously demos its features. At a separate table. And the CPO (chief product owner) and the POs (the product owner for each of the 3 teams) and the BSHs (the business stakeholders for all 3 teams) all move from table to table, trying to see what has been done, how it fits together (or doesn't), and deciding how to give the best feedback.
And in fact, team members also shuttle amongst the tables, trying to see what has been done by our Team and the other Teams, and how it all fits together and what it 'means'.
As you can see, doing this well requires some skill and experience. And you can imagine the self-organization that also takes place each time. And in ways that cannot be predicted. People will see issues and identify inter-relationships that could not have been anticipated beforehand.
In any case, hard as it is (and in some ways, it is easy), we recommend the Science Fair approach. It takes somewhat longer, but it pays dividends.
We also recommend that each Team have a short 'review' discussion. And that the whole Group have a 'review' discussion. Probably a short Group review at the beginning, and then again, at the end, to review the overall feedback and its implications.
If only scaling were simpler! For that matter, people! You know, if we could only get rid of those pesky customers, things would get a lot better real quick!
That reminds me of the most important advice about scaling: KISS. Or, as Einstein perfectly expressed it: "All things should be made as simple as possible, and not simpler."
No comments:
Post a Comment