fun interview format: lean kanban & scrum sprints
-: thank you for joining sidebar. i’m your host – (dash) and our guests for todays format will be lean software development and scrum development process. please welcome them… (applause) ;p
scrum: thank you for having me. it’s a pleasure to be here.
lean: yes, thank you. what a great looking audience you have today.
-: excellent~ well let’s dive right into it shall we? we’re here today to figure out some things. before we get too far can you briefly summarize what you do? we’ll start with lean then alternate as we move forward.
lean: well, we focus on defining the workflow and understanding how long it takes for work to move through each stage. we do so by limiting work in process (wip) by stage, dealing with impediments as needed based on exceeding these limits, and provide the opportunity to deliver working software as soon as the work is completed.
scrum: ok, we focus on defining process rules and norms to drive a more collaborative team dynamic within these boundaries. we also limit work in process (wip) by batching work in timeboxed sprints, communicating impediments verbally, and have a goal to deliver working software at the end of each sprint.
-: that’s great. thanks for the summary. but it sounds like each is pretty similar. could you describe what the differences are?
scrum: right~ we focus on, optimize, and batch work in a timeboxed sprint. sprints are the boundary conditions for observation and feedback to everyone involved. we find consistency the key to predictability.
lean: with that — we focus on and optimize the workflow for each work item. we pull work as needed, providing observation and feedback at each stage in the defined workflow. we find optimization within your current working conditions the key to improvement.
-: ok~ then why not the other approach? in a couple of sentences if possible… let’s keep the gloves on folks ;p
lean: lol~ if priorities change, we don’t make you wait until the next sprint, just until the next opening in the queue. we simply focus on limiting the work rather than the conflict that arises from increased concurrent items being worked on. generally speaking we don’t have rules that can be broken putting your project at risk, rather you are alerted and have the flexibility to resolve the alert as needed.
scrum: good stuff~ so we won’t let you flounder about trying to figure out how to deal with “things”. there is guidance, from there you have liberty and ownership of your processes. we won’t vary widely on how to do “things”, so if you ask most people “how” something is done in a specific context, you’ll find most answers to be fairly consistent. generally speaking, people get things done, so we deal with the things people need to get them done.
-: nice~ seems like two very good approaches to managing work… thank you both again for being our guests today. we hope to see more of each of you as people learn more about the value provided from your approaches.
(both – lean & scrum): thank you for having us… (smiles and waves) ;p