Scott VandenElzen Scott.VandenElzen@LoanSifter.com Kanban Scott VandenElzen Scott.VandenElzen@LoanSifter.com

Credits Kniberg, Henrik (2009), “Kanban vs Scrum” http://www.crisp.se/gratis-material-och-guider/kanban

Methodologies What is a software development methodology and why do we care? An Software Development Lifecycle (SDLC) methodology is an organized way of designing, developing, & deploying software that allows you to build a quality product in a repeatable fashion.

Methodologies An SDLC is both a set of tools, artifacts and work practices an organization uses to create software AND It’s the workflow process within an organization to get the requirements gathered, the software built, the testing done, and the bugs fixed. Examples - Agile, Scrum, Kanban, Waterfall, Rupp, TSP, TDD, Spiral, SSADM, Rad, Lean, Crystal, XP, and more!

Scrum in a nutshell Split your organization into small, cross-functional, self-organizing teams.

Scrum in a nutshell Split your work into a list of small concrete deliverables. Sort the list by priority and estimate the relative effort of each item.

Scrum in a nutshell Split time into short fixed-length iterations (usually 2-4 weeks), with potentially shippable software demonstrated after each iteration.

Scrum in a nutshell Optimize the release plan and update priorities in collaboration with the customer, based on insights gained by inspecting the release after each iteration. Optimize the process by having a retrospective after each iteration. So… instead of a large group spending a long time building a big thing you have a small team spending a short time building a small thing repeatedly.

Kanban in a nutshell Split the work into pieces - write each item on a card and put it on the wall Use named columns to illustrate where each item is in the workflow

Kanban in a nutshell Limit Work In Progress – assign an explicit limit to how many items can be in each workflow state Measure the cycle time - the amount of time it takes an item to flow through. Optimize the process to make this lead time as small and predictable as possible. Implicit in this – keep the work items small

(very brief) Kanban Background Kanban, the Japanese word for “signboard’ has become synonymous with demand scheduling. “Toyota created Kanban in the early 40s and 50s to help control production processes and implement Just in Time (JIT) in their Toyota manufacturing plants in Japan. By using kanbans, they reduced WIP between processes and the associated cost of extra inventory” (Gross, 2003). This aligns with lean manufacturing and development closely through elimination of waste/time wasted AND increase in efficiency.

Which should I use? Sounds like a great thesis idea!

Which should I use? There are frameworks for evaluating which SDLC might fit best for an organization that take into account complexity, uncertainty, quality criteria and the weight / importance of each phase of the product lifecycle. CuQuP -- Yusof, Shukur, & Abdullah

Which should I use? It Depends! You should use the tool (or SDLC in this case) that fits the job and organization. Remember no tool is perfect.

Which should I use? There is a range of formality even among “agile” methodologies.

Which should I use? “Remember no tool is perfect” – But you can add stuff! Just because Kanban doesn’t have a product owner doesn’t mean you can’t add one to your process. In any methodology you can add whatever roles or ceremonies your organization needs. Common Trap – we sent developers to scrum training and when they came back they discovered we had extra steps in our workflow. I heard “But that’s not Scrum” – my feedback “SO WHAT! It works for us.”

Compare/Contrast Scrum prescribes roles Scrum prescribes timeboxed iterations Kanban limits WIP per workflow state, Scrum limits WIP per iteration Both need fine tuning Who should be on the team How long between releases How big should my WIP be in each state Scrum board is reset between each iteration Scrum prescribes cross-functional teams Scrum backlog items must fit in a sprint Others…

Compare/Contrast Both are Lean & Agile Scrum and Kanban are pull scheduling systems. This means the team chooses when and how much work to commit to, they “pull” work when they are ready, rather than having it “pushed” in from the outside. Scrum and Kanban are based upon continuous and empirical process optimization, which corresponds to the Kaizen principle of Lean. Scrum and Kanban emphasize responding to change over following a plan.

Kanban

Can I use more than one? YES! At Visonex they use Scrum for our standard product development. They do 6 sprints 2 week sprints per quarter and released quarterly. The quarterly release dates are planned a year and advance so the team and the clients know when updates are coming. They have a 2 scrum teams of 8 developers and testers that works together for the quarter. AND…

Can I use more than one? They use Kanban for our maintenance work that is released every 2 weeks. 2 developers work the maintenance queue along with a part time tester. The advantage: standard work continues un-interrupted and released on schedule. Bug fixes can be pushed out without interrupting the flow.

Kanban in practice Visonex runs 2 or 3 scrum teams. Sprints start/stop every 2 weeks. They run a Kanban queue with 1 or 2 developers. The Kanban has an express lane for critical stuff. If something is in the critical lane, other work is paused.

Kanban in practice Their board limits the WIP to 2 items in development and 2 in test per developer. A developer might “jump over” to test the other developers work if a testing resource isn’t available to keep things flowing. 2 week releases are planned a year in advance Stakeholders (development, support, operations) meet weekly to prioritize the backlog. They set the top 10 items each week. Business analysis makes sure these items are ready for development. Business analysis keeps the backlog prioritized so the developers just need to ask for the next item.

Kanban in practice Critical items can come in and the work in the regular board stops until the critical item is deployed. Right before the release, all work is rolled up in a final deployment test, tested, and then the package is released. They rotate the developers who work the maintenance queue quarterly so everyone has a chance. It’s a good training opportunity.

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards

Sample Development Kanban boards There are other boards for other teams: System Administration Operations First & Second tier support Marketing Sales http://dl.dropbox.com/u/1638038/publikationer/10%20kanban%20boards%20and%20their%20context/10%20different%20kanban%20boards%20and%20their%20context%20-%20mskarin.pdf

Other resources Crisp consulting resource page http://www.crisp.se/gratis-material-och-guider/kanban Crisp’s Blog http://blog.crisp.se/tag/kanban Cartoon - Henrik http://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000 Book - David Anderson – Kanban http://www.amazon.com/Kanban-David-J-Anderson/dp/0984521402/ref=sr_1_1?ie=UTF8&qid=1293750801&sr=8-1