• Like

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Scrumban Ideacamp - Amsterdam Scrum Gathering 2010

  • 8,529 views
Uploaded on

A small presetation covering the topics discussed on the Scrumban Ideacamp I facilitated during Amsterdam's Scrum Gathering (Nov. 2010). Scrum, Kanban, Quality of Service, Sustainable pace, scrum …

A small presetation covering the topics discussed on the Scrumban Ideacamp I facilitated during Amsterdam's Scrum Gathering (Nov. 2010). Scrum, Kanban, Quality of Service, Sustainable pace, scrum boards... Enjoy! :-)

More in: Business , Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
8,529
On Slideshare
0
From Embeds
0
Number of Embeds
9

Actions

Shares
Downloads
375
Comments
2
Likes
36

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. An approach to Scrumban Whitepaper - Ideacamp Reducing, measuring and controlling uncertainty © 2010 Proyectalis Gestión de Proyectos S.L.
  • 2. Disclaimer: this presentation is meant for reading rather than presenting… © 2010 Proyectalis Gestión de Proyectos S.L.
  • 3. Ángel Medinilla   Telecom Engineer / vocational programmer   13+ years in industry, mainly as a project manager & agile consultant   Entrepreneur, Blogger   Motorbikes, Aikido, gaming, books, travel, music, gourmet cooking, wines, comics…   Certified Scrum Master - PMI Member - Agile Spain Co- Founder angel.medinilla@proyectalis.com http://twitter.com/angel_m http://es.linkedin.com/in/angelm http://slideshare.net/proyectalis http://www.presionblogosferica.com (spanish) http://www.proyectalis.com/en/blog (english, upcoming) © 2010 Proyectalis Gestión de Proyectos S.L.
  • 4. This presentation is about combining Scrum & Kanban © 2010 Proyectalis Gestión de Proyectos S.L.
  • 5. There are two main schools of thought out there: Scrumban & Kan-bum © 2010 Proyectalis Gestión de Proyectos S.L.
  • 6. Kan-bum guys do a full Kanban implementation, but they add some Scrum Liturgy © 2010 Proyectalis Gestión de Proyectos S.L.
  • 7. Selected. 4 Valid. Integration Pending Done! 3 Dev. Ready 1 1 There is someone very similar to a Product Owner, and sometimes (maybe on a weekly / monthly basis) he’ll call for a prioritization, estimation & planning meeting © 2010 Proyectalis Gestión de Proyectos S.L.
  • 8. Selected. 4 Valid. Intergration Pending Done! 3 Dev. Ready 1 1 He will be responsible for writing stories, prioritizing them and even setting a Quality of Service for each story © 2010 Proyectalis Gestión de Proyectos S.L.
  • 9. Selected. 4 Valid. Integration Pending Done! 3 Dev. Ready 1 1 On those meetings, maybe they’ll do a Demo and give their stakeholders (uh, I meant chickens) a whole vision of what they’re building and ask for some feedback © 2010 Proyectalis Gestión de Proyectos S.L.
  • 10. Selected. 4 Valid. Integration Pending Done! 3 Dev. Ready 1 1 The team would be probably doing some kind of Daily Meeting, so they can share, coordinate and decide © 2010 Proyectalis Gestión de Proyectos S.L.
  • 11. Selected. 4 Valid. Integration Pending Done! 3 Dev. Ready 1 1 In order to fine-tune their Kanban board, they’ll have to frequently reflect on how to become more effective (continuous retrospective) © 2010 Proyectalis Gestión de Proyectos S.L.
  • 12. Beautiful! but sometimes it’s nice to have time boxes, burn-downs, fixed delivery dates or it’s too difficult for the team to work with WIP limits.... © 2010 Proyectalis Gestión de Proyectos S.L.
  • 13. Or maybe our team is still too used to Scrum and finds it difficult to do a complete switch to Kam-bum © 2010 Proyectalis Gestión de Proyectos S.L.
  • 14. Sooo… now let’s take a look at the Scrumban guys. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 15. Burn-down:: Pending Selected. Dev. Valid. Integration Done! Release Plan: They probably started with the typical Scrum Board, with columns mapping their value stream, but with no WIP limit or queues © 2010 Proyectalis Gestión de Proyectos S.L.
  • 16. Burn-down:: Pending Selected. Dev. Valid. Integration Done! Release Plan: ! ! ! ! Sometimes they have to do some bug fixing, and sometimes the client asks for small and / or urgent tasks © 2010 Proyectalis Gestión de Proyectos S.L.
  • 17. This leads to Context Switching it’s identified as an impediment by the team, and even though the Product Owner understands it, client & product nature makes this emergent tasks unavoidable. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 18. Different approaches as a Separate Maintenance Team were tried but it made situation worse: maintenance team motivation dropped, knowledge was scattered and value stream was worsened for this kind of work. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 19. Velocity ? ? So their velocity is not very predictable, and is hard to know why sometimes they seem to do more or less © 2010 Proyectalis Gestión de Proyectos S.L.
  • 20. They looked at Scrum Literature, but all they could find was something about Focus Factor It was like reading “it’s your fault you can’t focus only on Product Backlog during Sprints, and we don’t care a bit about what happens out of your focus factor”  © 2010 Proyectalis Gestión de Proyectos S.L.
  • 21. So they started doing something: they tracked what was going on out of their Focus Factor © 2010 Proyectalis Gestión de Proyectos S.L.
  • 22. Burn-down:: Pending Selected. Dev. Valid. Integration Done! Release Plan: Pending Selected. Dev. Valid. Integration Done! They created a separate board (or a new lane on the old board) where they started to track bugs and emergent tasks © 2010 Proyectalis Gestión de Proyectos S.L.
  • 23. Burn-down:: Pending Selected. Dev. Valid. Integration Done! Release Plan: Pending Selected. Dev. Valid. Integration Done! 5 1 This was definitely a 3… They didn’t estimate bugs or emergent tasks in advance, but they gave them some effort number once they were done. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 24. Pending Selected. Dev. Valid. Integration Done! V Scrum Pending Selected. Dev. Valid. Integration Done! V Kanban So at the end of the sprint, they could measure up how much effort did they put on bugs & unpredictable tasks © 2010 Proyectalis Gestión de Proyectos S.L.
  • 25. Pending Selected. Dev. Valid. Integration Done! V Scrum Pending Selected. Dev. Valid. Integration Done! V Kanban (By the way, they called this “Kanban”, even tough it’s not really Kanban as there’s no WIP limit yet… Just hope the Kanban Police doesn’t find out ) © 2010 Proyectalis Gestión de Proyectos S.L.
  • 26. V Scrum V Kanban 80 20 Uuuh… Well, on average we make something like 85 20 75 scrum points per 75 30 sprint. Guess we can 70 35 commit on that as long as you keep the kanban 75 25 level safe… 80 25 ? ? That means somewhere below ¿Your prediction? 25 kanban points As soon as they had some numbers, they were able to commit better on how much effort would they put both in Scrum & Kanban development © 2010 Proyectalis Gestión de Proyectos S.L.
  • 27. V Scrum V Kanban 80 20 No, in fact we did 110 85 20 points of aggregated velocity, which is quite 75 30 good. It was YOU who 70 35 told us to prioritize 50 Kanban points during 75 25 ! 80 25 the Sprint and made us fail the sprint goal 60 50 That means we’re great and you Yaaargh! You suck. Maybe we failed on your should discuss this commitment! with the CEO  They were also able to understand and explain what happened during a given Sprint © 2010 Proyectalis Gestión de Proyectos S.L.
  • 28. Pending Selected. Dev. Valid. Integration Done! V Scrum Pending Selected. Dev. Valid. Integration Done! V Kanban + V Kanban - Soon, they started to differentiate good Kanban (value to the customer) from bad Kanban (bug fixing). Bad Kanban does not add to velocity, but affects it. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 29. Vavg Kanban + Velocity Vavg Scrum Vavg Kanban - And they started to see the effect that bugs and emergent tasks had on Scrum Velocity © 2010 Proyectalis Gestión de Proyectos S.L.
  • 30. Vavg Kanban + Velocity Vavg Scrum Vavg Kanban - So they could take decisions on things like increasing investment on bug fixing or stop emergent tasks if project is running late © 2010 Proyectalis Gestión de Proyectos S.L.
  • 31. Burn-down:: Pending Selected. Dev. Valid. Integration Done! Release Plan: Pending Selected. Dev. Valid. Integration Done! ? ?? ? They still had a problem: how to know on which task should they work next? Should they get the next Scrum task or the next Kanban task? © 2010 Proyectalis Gestión de Proyectos S.L.
  • 32. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! PRIO ASAP So they implemented a simple and visual quality of service mechanism(QoS) © 2010 Proyectalis Gestión de Proyectos S.L.
  • 33. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! PRIO ASAP The Fire lane meant “drop whatever you’re doing, there’s a server on fire and we don’t care if velocity drops – go fix it now!!!” © 2010 Proyectalis Gestión de Proyectos S.L.
  • 34. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! PRIO ASAP Mwaa-hahaha!!! There should be some kind on control mechanism on Fire QoS, so it doesn’t open the gates of hell to the team © 2010 Proyectalis Gestión de Proyectos S.L.
  • 35. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! PRIO Was this really ASAP a fire??? No it wasn’t… Uh-oh… Time to coach our P.O. I.E., every Fire request should be audited post-mortem and there should be a limit on how many of them you can open on a given sprint (that’s why it’s a small lane). © 2010 Proyectalis Gestión de Proyectos S.L.
  • 36. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! Prio ASAP PRIO lane means “as soon as you finish what you are doing right now, please choose this urgent task”. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 37. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! Prio ASAP This is not as disruptive as a Fire, but still introduces some controlled context switching, so it shouldn’t be over-used by the Product Owner either. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 38. Burn-down:: Pending Selected. Dev. Valid. Integration Done! COMMITTED Release Plan: Fire! Prio ASAP The key words in the asAP QoS definition are “As Possible”, You should do some of those, but only as long as it doesn’t compromise the Sprint Goal © 2010 Proyectalis Gestión de Proyectos S.L.
  • 39. Dev. Done! Sprint Burn-down: Pending Selected. Valid. Integration COMMITTED Fire! Kanban burndown: Prio ASAP Mmm…Guess I’d Uh-oh, hold the like some Scrum Kanban, guys!! done too… Soon the Team started to keep a separate Kanban Burndown so they could see if they could invest more on kanban or not. © 2010 Proyectalis Gestión de Proyectos S.L.
  • 40. V Scrum V Kanban 80 7500 Uuuh… Well, on average we make something like 85 7000 75 scrum points per 75 8000 sprint. Guess we can 70 8500 commit on that as long as you keep the kanban 75 7500 level safe… 80 7000 ? ? That means somewhere below ¿Your prediction? 7500 kanban points Some teams found it difficult to give a story-point estimate to kanban tasks, so they used a different scale (hours, bug size, kanban points or whatever) © 2010 Proyectalis Gestión de Proyectos S.L.
  • 41. V Scrum V Kanban 80 7500 No, in fact we did a lot more 85 7000 kanban than usual (you over- kanbanized us by 50%, 75 8000 which is quite a lot). It was 70 8500 YOU who told us to prioritize Kanban points during the 75 7500 ! 80 7000 Sprint and made us fail the sprint goal 60 11.200 That means we’re great and you Yaaargh! You suck. Maybe we failed on your should discuss this commitment! with the CEO  This worked like charm. You could even normalize average speeds and add them up, but that’s too much work, and there’s no real need to do so  © 2010 Proyectalis Gestión de Proyectos S.L.
  • 42. Just some final advice… © 2010 Proyectalis Gestión de Proyectos S.L.
  • 43. 1) Sustainable pace is about working always towards your average speed There’s no use in aiming for top speed every single sprint, except for undermining team’s morale © 2010 Proyectalis Gestión de Proyectos S.L.
  • 44. Backlog and average speed This will be done for sure (boring) Min. V We will probably end up somewhere over here (average speed) – a.k.a. “We can do this!”  Max. V Yougottabekiddin’ me!  © 2010 Proyectalis Gestión de Proyectos S.L.
  • 45. 2) No tool is foolproof if your P.O. is opening 25 PRIO Kanban every single day, I’ll give you a clue: the problem is not in the post-it notes brand you’re using…  © 2010 Proyectalis Gestión de Proyectos S.L.
  • 46. Hope it helps! I would love to hear about how this is helping you or how could we improve it . Please frop me a line at angel.medinilla@proyectalis.com © 2010 Proyectalis Gestión de Proyectos S.L.
  • 47. http://creativecommons.org/ licenses/by-nc-nd/3.0/ This presentation is based upon the ideas and work of many people. And while I’ve tried to recognize copyrights and give credit and attribution where possible, I cannot possibly list them all, so if you feel like there’s something that should be added, changed or removed from this presentation, please drop me an e-mail at angel.medinilla@proyectalis.com Special thanks to Henrik Kniberg, on whose article “one day in kanban land” is this presentation inspired. You rock!!  © 2010 Proyectalis Gestión de Proyectos S.L.