Learn how I can make a difference #thatsIntelligence

news

read more @ www.agileatwork.co.uk

Scrum? Kanban? What about Scrumban anyone?


Scrum is probably the most famous and popular implementation of Agile going....


It's established, structured and well documented - with clearly defined roles, responsibilities and ceremonies.


I've written a few blog posts about Scrum but if you're new to Scrum it's probably worth reading my article 'The ten must do's of Scrum'


Probably less well known or understood is Kanban, Kanban doesn't have the structure of Scrum, its less defined (or rigid) and is very good for operationally led teams as opposed to project based teams (which tend to better suit Scrum)... yes it's another plug for my blog! But if you want to know more about Kanban read 'What is this Kanban everybody is talking about'


A problem I've encountered a lot - especially in smaller software houses and in-house development teams is the pull between project work and operational work - often with unclear priorities being set, little project management in place to support to the process and even less visibility! 


Kanban is brilliant as a work-flow tool..... it show's bottle necks, enforces WIP (Work in Progress) management and helps the team and management visually understand the flow of work (or not) 


Now at this point... the purists might start to argue that good Scrum does or should use Kanban techniques and Kanban should be trying to build better teams as per Scrum - and I see that argument.... however I still believe that Scrumban is a technique in it's own right and in many organisations where pragmatism and compromise are part of reality it has something to offer - even if just a discussion starting point!


So how do we do Scrumban? Well, as with all things Agile there are numerous implementations - I'd suggest starting simple (depending upon h
ow experienced your team are with Scrum and or Kanban) and refine in iterations. 


1.  The first thing you'll need is a board/project board/Information Radiator.... and simply define your 'To-do' Queue and the relevant swim lanes for your organisation - you should also define your WIP (Work-In-Progress) limits... I'd suggest this is linked to team size, team of 4, WIP = 4! moving forward you might want to allow limited multi-tasking.. that's another blog but perhaps 4+1 where one additional task is allowed in (but build up to that)






2. Maintain the product back-log.... but not too much! This is such an important step in Scrum  that I might write a blog article all about it... However in Kanban and Scrumban which is less predictable the product back log should be smaller and more limited.

The Scrumban Back-log is likely to be event driven, aim to just know what the team will be working on next......  and you should expect it to change!

3. Planning meetings - In Scrum these planning sessions are held at the start of the Sprint - In Scrumban the meeting is held at the start of a cycle - what's the difference? Sprints are a predefined length - however a cycle in Scrumban are held based on the number of jobs left in the To-do queue. So for example when the number of items left in 'to-do' hits a defined trigger point (lets say two left) this triggers another planning session - end of one cycle, start of the next! 

Each planning session will define the priority of work and move these jobs to the 'To-Do' queue, just as you would in Scrum ensure that these sessions are 'time-boxed' 


4.When the Sprint/Cycle begins... start pulling jobs from the work queue, respecting your WIP swim lane quotas - Remember the team should be trusted! So allow team members to select the task they want, know about and enjoy working on!

5.Respect the WIP limit... if you decide that no-more than 4 tasks are allowed to be in progress enforce it.. if a job hits a blocker, can't continue, or a new job takes priority .. it goes back on the 'To-do' list... doing this helps to enforce focus and reduces the waste caused from constantly switching.

6.    Review Meetings - Just as you would in Scrum, Ensure that you have review meetings with stakeholders, clients , customers also known in Scrum as the demo.... This is how software teams come in contact with the end-users... it ensure's clarity, understanding and helps to build trust between teams. 

7. Retrospective Meetings - I love a good retrospective.... And so should you! try and hold this after the review meeting.... agile is about refining the process, introspection and iterative improvements.... ensure that you hold these meetings and that you feedback into them.


8. Stand-up meetings.... these are probably the most famous aspect of Agile... I've met teams that believe there doing Agile just because they have a daily stand-up. In Scrum these are very defined, "What did I do yesterday?", "today", "impediments"... In Scrumban they should be very much Kanban board focused.


9. Metrics - Every manager love metrics.... and that's perhaps the problem - because it leads to abuse! 


Managers like to increase these metrics! In Scrum where you have Velocity, this can lead to inflated estimates, poor enforcement of the definition of done (which leads to technical debt) or a rush to complete every story within the 'time-boxed' sprint which leads to a lack of quality and again technical debt!


In Scrumban you have a cycle time, the length of time it takes a number of tickets to move through the system from left to right  - by calculating mean cycle times and using standard deviation you can gauge a sort of velocity - IE. A team of 5 might take 5 days to complete 10 tickets. 



The following rules should be followed by Scrumban


  1. Keep the back log small
  2. Plan on demand
  3. As you progress - allow some multi-tasking, perhaps having your WIP = team size + 1
  4. Use average lead and cycle times to measure performance - not velocity! 
  5. Allow your team to specialize - let people focus on what they enjoy doing - They pull the tasks themselves.... don't allocate!
  6. Think about deployment... and plan for it in the sprint/cycle

Scrumban is perfect for where a team needs to adapt and change fast... where project work is not predictable (or poorly defined) or where teams are heavily involved in support work.


It removes some of the metrics which are more suited to project based teams and this in turns leads to more accurate planning and less abuse from management.


By limiting the teams WIP - it helps to ensure that teams finish what they start to a higher standard.


And finally, good luck - and if you have any Scrumban stories... good or bad please share!