4 ms·
Kanban is also fine, for the reasons you mentioned. I wonder if TFA favors this methodology? Do note Kanban can devolve into "do everything, all at once, and w
by the_af 4y ago
Kanban is also fine, for the reasons you mentioned. I wonder if TFA favors this methodology?
Do note Kanban can devolve into "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!". It happened to my team, and we had to ditch it because the stakeholders weren't onboard with no fixed cadence of deliveries.
- jrs235 4y ago>stakeholders weren't onboard with no fixed cadence of deliveries. Can the fixed cadence of deliveries be weekly or semi weekly status update of cards on the board? (Note: the view of the board should always be available to stakeholders, they may need to hold their breath for a week until a more in-depth status meeting of current cards on the board...)
- WorldMaker 4y agoYep. Also I've never seen a Kanban operation deliver everything to Production as soon as it hits a "Done" column and there's no reason not to "time gate" (once every fortnite, just like Sprints are supposed to be, for instance) a Production column "pull". I think that's easily missed in Kanban versus Scrum discussions: every Kanban column is supposed to be "pull" rather than "push". Production "pulls" finished UAT stories when it is ready (which maybe is a biweekly schedule that keeps ops happy and gives marketing time to prepare materials, etc). (I also think that's why a lot of micro-managers dislike Kanban versus Scrum, because they want to "push" everything and dislike people making their own "pull" judgments based on their current bandwidth and ability.) The failure case of "Production pulls finished work" is that Production sometimes wants to cherry-pick finished work ("I want these three but not this fourth one") after they've been already merged for UAT testing. I've not seen a good Kanban software that visualizes that "state change" of stacking cards together as they become bundled together/releasable units.
- jrs235 4y agoAh yes! I forgot about the "pull" mechanism of kanban. This also helps identity bottlenecks and discover where more "resources" (::barf::) are needed or where re-allocation of "resources" should occur. I need to reread the following books: Kanban: Successful Evolutionary Change for Your Technology Business Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency The Goal: A Process of Ongoing Improvement. The Deadline: A Novel About Project Management
- marcosdumay 4y ago> "do everything, all at once, and we need right now. Stop doing what you're doing, do this thing instead!" Hum... Since the single main stated goal of kanban is to minimize WIP, it's safe to say that this is not kanban. Of course, it won't stop bad managers from implementing it. But nothing will stop bad managers from implementing it anyway. Anything can devolve into that, trying to implement something different won't save you.
- hirvi74 4y ago> WIP Do you mind defining this?
- mgkimsal 4y agoWork In Progress, I think they're referring to.
- marcosdumay 4y agoYep, work in progress.
- WorldMaker 4y ago"Work in Progress". "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.)
- hirvi74 4y agoThank you for the clarification, but I am afraid you lost me at this part: > "Strict" Kanban is about minimizing in flight stuff that you don't have bandwidth for. (Strict "traffic limits" based on team size in any specific column.) What is "in flight stuff" and "traffic limits?" Are you saying strict Kanban minimizes the number of tasks that are in progress in order to prevent overloading the team i.e., there is an upper limit set to curtail the amount of simultaneous tasks?
- 015a 4y agoBut again, sprints can also devolve into that. Structure becomes valueless when people subvert it; there's nothing particular about kanban which makes it more susceptible to this than scrum.
- the_af 4y agoTotally agreed. From the outside, though, kanban looks more like "no methodology". If people who aren't on board look at both 2-week sprints and kanban, kanban looks a lot closer to "we can ask you to do whatever, whenever". It's wrong, of course, but in my experience they understand better that it's discouraged to insert new requirements in the middle of a sprint. People will subvert whatever they want, though. Probably the biggest shortcoming with agile methodologies: "you are not doing it right" -- yeah, well, real people in the real world never do it right.