Scrum vs. Kanban

Posted: August 2, 2016 in Business, Product Development
Tags: , , ,

Scrum vs kanban logo

Development teams should decide what agile development framework they adopt / try out using retrospectives to aid improvements and change. The way teams operate are significantly different between Scrum and Kanban but the fundamentals of business delivery stays the same eg. Prioritisation, frequently delivering value to customers, agile software delivery and development team structure / support. So what are the differences:
Scrum

  • Scrum is one of the most popular ways to implement Agile. It is an iterative software model that follows a set of roles, responsibilities, and meetings that never change. Sprints, usually lasting one to two weeks, allow the team to deliver software on a regular basis.
  • Teams commit to delivering two weeks worth of work, but if the original plan changes by even adding work, removing work or changing work / stories within a sprint would mean the team fails in achieving the original sprint commitments / goal
  • If teams deliver what they commit to then they celebrate passing the sprint (which was the sprint goal) ie. a teams goal is to deliver on their sprint commitments, not to get the actual development / value live to customers
  • Set Scrum ceremonies such as daily stand ups, fortnightly sprint planning, fortnightly backlog grooming and a retrospective
  • Sizing user stories which can be a different size
  • Sprint burndown charts to measure progress
  • You have a team velocity to help set realistic future sprint goals and project feature ETAs
  • Normally there can be no dependencies when committing to work in a sprint so even more upfront planning / scheduling / grooming is needed

    Kanban

    • Kanban, meaning “visual sign” or “card” in Japanese, is a visual framework to implement Agile. It promotes small, continuous changes to your current system. Its principles include: visualise the workflow, limit work in progress, manage and enhance the flow, make policies explicit, and continuously improve.
    • The goal is to move user stories / bugs through different stages of the development cycle with the goal to get the story from one side of the board to ‘live’ / ‘done’ ASAP
    • The stories high up in the backlog / coming next should be broken down so that each piece of work is roughly equally sized allowing you to gauge an average story cycle time and deliver value frequently
    • The team are typically not bound by time limits to getting work done and instead restrict WIP by dev status to ensure value gets delivered frequently to customers
    • Grooming, stand ups, planning and retrospectives are not mandatory but regular grooming, stand ups and retrospectives are recommended to ensure efficiency is at a good level
    • As there’s typically no fixed deadline on work getting done, teams can spend longer on thorough investigations into multiple solutions if needed. Also on the other end having a column on the Kanban board for demos, pre-production work and a column representing live is also possible allowing stories to be closed only when value starts getting delivered to customers
    • Because of the above, it makes the status of development work crystal clear rather than a sprint ending and you having to dig around to find out where it is and spend more effort / create additional release stories trying to get it live
    • The team lead and dev manager role is even more important to ensure the team are trained up, working efficiently and resourced to get the job done
    • As teams pick work from the top of the backlog adhoc, it’s likely a new highest priority item will be picked up sooner than if it was at the top of a Scrum board as you don’t have to wait two weeks until the sprint finishes before it’s in development

      Both Scrum and Kanban have plenty of pros, cons and bring different challenges to the table, but give software engineers the autonomy to get through the backlog without sprint boundaries or artificial deadlines then you’ll likely see productivity, quality and communication increase, with the caveat that they must have strong support from the team lead, dev manager and PO who aren’t affraid to get stuck in.

      Leave a Reply

      Fill in your details below or click an icon to log in:

      WordPress.com Logo

      You are commenting using your WordPress.com account. Log Out /  Change )

      Google+ photo

      You are commenting using your Google+ account. Log Out /  Change )

      Twitter picture

      You are commenting using your Twitter account. Log Out /  Change )

      Facebook photo

      You are commenting using your Facebook account. Log Out /  Change )

      Connecting to %s