Scrum and Kanban In A Nutshell

Scrum, essentially is:

• Dividing teams 

Dividing teams into self-managing, cross functional teams, with a production owner providing business requirements and prioritization; a scrum master focusing on improving the process and removing blocks; developers and testers work together. 

 

• Dividing the timeline

Dividing the timeline into short, fixed-length sprints.  

 

• Dividing the work

Dividing the work into small tasks. Plan tasks into each sprint. At the end of sprint, deliver the tasks.

•   Having a retrospective at the end of each sprint reflecting on what is working and what is not.

If Scrum is so simple, why does it have so much power? Well, it doesn’t. I have seen many projects fail with Scrum development methodology, and developer team, QA team, and requirement team at each other’s throat and point fingers. Scrum itself is not a magic bulletin. It structures the team in a way that promotes communication and cooperation, but how well the team members function is beyond software management. I think the strength of a scrum team can be seen from the retrospective meeting: does the team point out what is not working candidly, even sometimes it seems it is getting personal? Does the team come up with pragmatic actions and not actions just to cover themselves?  -- by the latter I mean if a process or a rule enables someone to say “I have followed it therefore it is not my fault”, it is not a good process or rule. 

Kanban, in a nutshell is:

 

• Map out the stages of a workflow and write them down on the wall (or a whiteboard)
• Limit how many items can be in each stage of the workflow (Work In Progress, WIP)
• Measure the lead time (average time it takes for one item to travel from stage 1 to the end, also called “cycle time”)

What extra power does Kanban bring about?

1.       The psychological influence of seeing the whole picture on the wall. Seeing the whole workflow on the wall will entice people to get out of their little shell, to get interested in what others are doing, and to contribute to move things quickly along the workflow.

2.       Kanban stresses upon lead time: the time it takes to deliver a task from the beginning to the end. If something blocks testing, there is no need to for the developer team to develop more features, there is motivation for the development team to help out the QA team to remove the blocks.