Yep, that's pretty close. There are some considerations with teams-of-teams. Infrastructure, suppliers, scheduling, production support, release procedures, etc. There is also a bit of organization and dynamic scaling necessary: you don't want a program backlog with 4 thousand items on it. That's unworkable.
Usually it helps if you stay with fixed iterations instead of Kanban and do program planning all at once (Yes, 150 people all in the same room working out the next couple of sprints. Fun to watch and participate in!)
Other kinds of tooling issues become bigger in a large group, like how to integrate separate physical pieces, how many branches to have in your CM tool, how technical drawings will be cataloged, etc. But none of it is super hard, and lots of other folks have already gone down this road. The important thing is not to over-constrain your development environment just to make yourself feel safer.
The biggest obstacle to running a larger group like this is dealing with the parts that are counter-intuitive. It just seems natural with 100 folks that you'd have a detailed charge-code breakdown, for instance. Or that 100% capacity is something you want to achieve. There are a few more gotchas like this, but if people are open-minded, it can mean a huge increase both in performance and happiness.
The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better.
Note I didn't say you couldn't go total kanban at large scale, just that there was a trade-off involved with each path.
The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better.
I mostly don't work with organisations of that size, but the technique I hear people use to get around that coordination issue is to have events that happen on a regular cadence, but don't have them tied to delivery in the same way sprints are.
So you have stories flowing but also schedule fortnightly planning meetings (or whatever) on top.
This fits with my experiences on smaller kanban style projects where we have regular cadences for non-flow things like usability testing, backlog grooming, etc.
[Edit: Which is what the OP folk are doing "The ideas on this board are reviewed once a week during our Inbox Review meeting"]
It's worth noting that when we were in our last "building a big new product" push over a year (for our Helpdesk product) we were doing sprints because we had harder deadlines to work within. Having said that we still hated the overhead required to properly plan a sprint so even if we were in that phase again I'm not sure that we'd go back to sprints.
Yep, that's how to do it. You can have certainly have cadences without sprints.
The interesting thing here is that the same problem arises at a larger scale as it does on at the team level: architecture. Not how pieces of the software is put together, but the architecture of the existing and future business environment.
So, for example, a large project might include hardware, software, embedded software, offshore testing, multiple vendors, fixed demo dates, fixed regulatory dates, and so on. You can certainly manage all these cadences separately, but for most folks sprints of a week or two in length give you fixed reference points to then optimize around.
Of course, it's easy to think up a scenario with a pretty simple business environment, say the next version of Google+. In that case, Kanban probably would work a lot better. Do the simplest thing you can, but no simpler.
I find that business architectural issues can be difficult for the teams to grasp. The Scrum guys have preached sliding stories under the door to the team for so long, there's an entrenched mindset that things like that aren't the team's problem. (Not everybody, but many folks think this)
Counter-intuitively, by fixing the planning and delivery times, you can simply the cadence discussion. It all has to fit somehow in this list of dates. It also makes it easier to simplify or add complexity to the business architecture without having to worry so much about impacts.
You might think: why not just go kanban with one fixed planning cadence? Kind of the best of both worlds. Technically this would be awesome. You run into some communication and messaging problems though. If your message is "It's kind of like Scrum only bigger" then you can send out for Scrum training and explain how it all works. People will take the training and then ask questions like "who is the product owner" which aren't perfect but at least they're in the right direction. But if all you have is a bunch of boards and hand-waving, it's very difficult to get everybody to have some kind of mental model on what's happening. It's just too much (unless you already have established some previous Agile practice). Folks have to have some sort of working mental model of how things are supposed to work. Going from something like RUP to full-bore program-level Kanban in a complex business environment is just too far. My opinion only, for what it's worth. Perhaps in the next few years we'll see people tackle this. One of the things we don't talk about enough is that we struggle quite a bit with teams doing Agile, much less programs. It's simple concepts, but application is a bear.
You can certainly manage all these cadences separately, but for most folks sprints of a week or two in length give you fixed reference points to then optimize around.
Curiously what I've been hearing from folk in this situation is that it's the separation of the cadences that they see as an advantage. With the large teams they were finding there was just "too much stuff" happening at a single point and it became impossible to manage. Moving to a kanban style, and moving the various end-of-sprint rituals and spreading them out into their own cadences helped enormously - but I would imagine that it would be very context dependent.
The other thing I find useful about the kanban style is when the cadences of some work doesn't match up well with the sprint cadence. For example the more generative UX work (user interviews, etc.) doesn't always naturally fit into that 1/2 week cycle. Sprint-ahead/-behind is an abomination in my eyes - so having separate cadences helps a lot there.
Going from something like RUP to full-bore program-level Kanban in a complex business environment is just too far
Heh. With RUP you can probably find enough things in method composer to evolve it into something kanban-ish ;-)
Personally I'm not a fan of the big-bang rollout of new processes. Never seems to work well. And having folks who can actually understand "It's kind of like Scrum only bigger" means you've already got folk with a fairly sophisticated knowledge (assuming that they actually understand Scrum that is...)
One of the things we don't talk about enough is that we struggle quite a bit with teams doing Agile, much less programs. It's simple concepts, but application is a bear.
Seems that it's pretty much all I talk about - probably why I keep getting sucked into coaching roles away from more fun thing :-)
We reach a point of dimishing returns really quickly just talking about situations. I can share experiences and what I think I know, but at the end of the day this isn't about going off and following some author, speaker, or book. It's figuring out what works in your particular situation.
The cool part about Agile is that it's not Scrum, ie, there is no certification authority or magic recipe. It's just a bunch of schmucks sharing what worked or didn't work.
I shy away from answers like "it's all Scrum" or "It's all Kanban" for just that reason -- too facile. In a 15-project program, you usually have several groups going strictly Kanban. Enterprise architecture is one (if you have that) and program release is another. These things don't have to sync up, they just need to be ready. So even my advice about using sprints isn't absolute. Advice in this area is a lot of generalizations. You get what you pay for!
If you have any experience with these larger structures, I'd love to hear about it. I'm always collecting tidbits like that. Thanks for the chat!
I can share experiences and what I think I know, but at the end of the day this isn't about going off and following some author, speaker, or book. It's figuring out what works in your particular situation
Likewise and ditto. As I said I would imagine that it would be very context dependent.
Comments
Yep, that's pretty close. There are some considerations with teams-of-teams. Infrastructure, suppliers, scheduling, production support, release procedures, etc. There is also a bit of organization and dynamic scaling necessary: you don't want a program backlog with 4 thousand items on it. That's unworkable.
Usually it helps if you stay with fixed iterations instead of Kanban and do program planning all at once (Yes, 150 people all in the same room working out the next couple of sprints. Fun to watch and participate in!)
Other kinds of tooling issues become bigger in a large group, like how to integrate separate physical pieces, how many branches to have in your CM tool, how technical drawings will be cataloged, etc. But none of it is super hard, and lots of other folks have already gone down this road. The important thing is not to over-constrain your development environment just to make yourself feel safer.
The biggest obstacle to running a larger group like this is dealing with the parts that are counter-intuitive. It just seems natural with 100 folks that you'd have a detailed charge-code breakdown, for instance. Or that 100% capacity is something you want to achieve. There are a few more gotchas like this, but if people are open-minded, it can mean a huge increase both in performance and happiness.
The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better.
Note I didn't say you couldn't go total kanban at large scale, just that there was a trade-off involved with each path.
The industry is moving towards plain kanban without the sprints. I like this idea with smaller groups, especially groups with lots of support work on existing code, but for larger projects creating something new, using sprints, having a fixed point of coordination for a lot of different stuff, works much better.
I mostly don't work with organisations of that size, but the technique I hear people use to get around that coordination issue is to have events that happen on a regular cadence, but don't have them tied to delivery in the same way sprints are.
So you have stories flowing but also schedule fortnightly planning meetings (or whatever) on top.
This fits with my experiences on smaller kanban style projects where we have regular cadences for non-flow things like usability testing, backlog grooming, etc.
[Edit: Which is what the OP folk are doing "The ideas on this board are reviewed once a week during our Inbox Review meeting"]
It's worth noting that when we were in our last "building a big new product" push over a year (for our Helpdesk product) we were doing sprints because we had harder deadlines to work within. Having said that we still hated the overhead required to properly plan a sprint so even if we were in that phase again I'm not sure that we'd go back to sprints.
Yep, that's how to do it. You can have certainly have cadences without sprints.
The interesting thing here is that the same problem arises at a larger scale as it does on at the team level: architecture. Not how pieces of the software is put together, but the architecture of the existing and future business environment.
So, for example, a large project might include hardware, software, embedded software, offshore testing, multiple vendors, fixed demo dates, fixed regulatory dates, and so on. You can certainly manage all these cadences separately, but for most folks sprints of a week or two in length give you fixed reference points to then optimize around.
Of course, it's easy to think up a scenario with a pretty simple business environment, say the next version of Google+. In that case, Kanban probably would work a lot better. Do the simplest thing you can, but no simpler.
I find that business architectural issues can be difficult for the teams to grasp. The Scrum guys have preached sliding stories under the door to the team for so long, there's an entrenched mindset that things like that aren't the team's problem. (Not everybody, but many folks think this)
Counter-intuitively, by fixing the planning and delivery times, you can simply the cadence discussion. It all has to fit somehow in this list of dates. It also makes it easier to simplify or add complexity to the business architecture without having to worry so much about impacts.
You might think: why not just go kanban with one fixed planning cadence? Kind of the best of both worlds. Technically this would be awesome. You run into some communication and messaging problems though. If your message is "It's kind of like Scrum only bigger" then you can send out for Scrum training and explain how it all works. People will take the training and then ask questions like "who is the product owner" which aren't perfect but at least they're in the right direction. But if all you have is a bunch of boards and hand-waving, it's very difficult to get everybody to have some kind of mental model on what's happening. It's just too much (unless you already have established some previous Agile practice). Folks have to have some sort of working mental model of how things are supposed to work. Going from something like RUP to full-bore program-level Kanban in a complex business environment is just too far. My opinion only, for what it's worth. Perhaps in the next few years we'll see people tackle this. One of the things we don't talk about enough is that we struggle quite a bit with teams doing Agile, much less programs. It's simple concepts, but application is a bear.
You can certainly manage all these cadences separately, but for most folks sprints of a week or two in length give you fixed reference points to then optimize around.
Curiously what I've been hearing from folk in this situation is that it's the separation of the cadences that they see as an advantage. With the large teams they were finding there was just "too much stuff" happening at a single point and it became impossible to manage. Moving to a kanban style, and moving the various end-of-sprint rituals and spreading them out into their own cadences helped enormously - but I would imagine that it would be very context dependent.
The other thing I find useful about the kanban style is when the cadences of some work doesn't match up well with the sprint cadence. For example the more generative UX work (user interviews, etc.) doesn't always naturally fit into that 1/2 week cycle. Sprint-ahead/-behind is an abomination in my eyes - so having separate cadences helps a lot there.
Going from something like RUP to full-bore program-level Kanban in a complex business environment is just too far
Heh. With RUP you can probably find enough things in method composer to evolve it into something kanban-ish ;-)
Personally I'm not a fan of the big-bang rollout of new processes. Never seems to work well. And having folks who can actually understand "It's kind of like Scrum only bigger" means you've already got folk with a fairly sophisticated knowledge (assuming that they actually understand Scrum that is...)
One of the things we don't talk about enough is that we struggle quite a bit with teams doing Agile, much less programs. It's simple concepts, but application is a bear.
Seems that it's pretty much all I talk about - probably why I keep getting sucked into coaching roles away from more fun thing :-)
We reach a point of dimishing returns really quickly just talking about situations. I can share experiences and what I think I know, but at the end of the day this isn't about going off and following some author, speaker, or book. It's figuring out what works in your particular situation.
The cool part about Agile is that it's not Scrum, ie, there is no certification authority or magic recipe. It's just a bunch of schmucks sharing what worked or didn't work.
I shy away from answers like "it's all Scrum" or "It's all Kanban" for just that reason -- too facile. In a 15-project program, you usually have several groups going strictly Kanban. Enterprise architecture is one (if you have that) and program release is another. These things don't have to sync up, they just need to be ready. So even my advice about using sprints isn't absolute. Advice in this area is a lot of generalizations. You get what you pay for!
If you have any experience with these larger structures, I'd love to hear about it. I'm always collecting tidbits like that. Thanks for the chat!
I can share experiences and what I think I know, but at the end of the day this isn't about going off and following some author, speaker, or book. It's figuring out what works in your particular situation
Likewise and ditto. As I said I would imagine that it would be very context dependent.