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
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.