Scrum in a Nutshell
1. Create small, cross-functional, self-organizing teams.
2. Split your work into a list of small, concrete deliverables. Prioritize the items in the list and estimate their relative effort.
3. Split time into short fixed-length iteraions (max. one month), that can each deliver a finished product / feature.
4. Get regular feedback from the customer in order to optimize the release plan after every iteration.
5. Optimize the process by analyzing feedback after every iteration.
Instead of a large team spending a long time building a big thing, create small teams spending a short time building a small thing, integrating regularly to see the big picture.
Scrum uses timeboxed iterations and cross-functional teams. Daily standup meetings help align the team. There are 3 roles: Product Owner (product visions), Scrum Master (process leadership) and the Team (implements the product). The teams should be cross-functional and the work in progress per iteration is limited.
Scrum uses five types of events: sprint, sprint planning, daily scrum, sprint review, sprint retrospective and three types of artifacts: product backlog, sprint backlog and increments.
Kanban in a nutshell
1. Visualize the workflow: Split the work into pieces and put each item in the respective workflow state on the Kanban Board
2. Limit Work in Progress: each workflow state should have an explicit limit to the number of items in progress.
3. Measure the lead time (average time to complete one item): The lead time should be as small and predictable as possible
Kanban uses visible boards, limited size of queues and the work in progress is limited per workflow state. The approach is slightly more adaptive.
Defining principles of Kanban: Start with the current state and then agree to pursue incremental, evolutionary change. Respect the current process, roles, responsibilities, and titles and encourage acts of leadership at all levels.
Core properties include visualizing the workflow, limiting work in progress, managing flow, making process policies explicit, implementing feedback loops and improving collaboratively.
Blending the approaches into Scrumban
Scrum and Kanban are both empirical methods. You are expected to experiment with the process and customize it to your environment using feedback loops. Neither Scrum nor Kanban provide all the answers, they only give a basic set of constraints to drive your process improvement.
In Scrum Sprints you are asking yourself: “Are we building the right stuff and are we building it right?”
Kanban provides real-time metrics. This allows you to choose the length of your feedback loop, based on how often you are willing to analyze the metrics and make changes.
What if someone turns up and wants to add an Item G to the board?
A Scrum Team would say: «No, sorry, we’ve set the items A-F for this sprint. Feel free to add G to the product backlog and if the product owner considers it high priority, we will pull it into the next sprint.»
A Kanban Team would say: «Feel free to add G to the To Do column. However, we have set a limit of 3 for that column, so you will need to remove D, E or F. We are working on B and C right now, but when we have capacity we will pull the top item from the To Do column.»
A Scrum team may decide to allow a product owner to change priorities mid-sprint, or a Kanban team may decide to add restrictions about when priorities can be changed or it may decide to use timeboxed fixed commitment iterations.
Both methods allow working on multiple products at the same time.
