Transforming Teams to Kanban and Scrumban

[@corazonesnegros502]

This is gold! Thank you.

[@Artemisagile]

Here's the video of the presentation I gave at Mile High Agile 2015 on Transforming Teams to Kanban and Scrumban. It was a "Tales from the Trenches" presentation meaning it was a case study of taking a real-world team through this process. I may update it later with a slightly refined version (since this was designed to be presented to an audience, not discussed on KZbin). In the meantime, though, here's what I discussed:

[@jonchicoine]

Bill, Great Video! My team is contemplating the move from scrum to possibly scrumban... I thought the Porlock case study was extremely informative. (i hope you're feeling better soon, sounds like you have a bit of cold or flew, eh?)

[@jahzeelramoscalosairri8851]

What's the metrics for Scrumban?

[@Artemisagile]

Hi Jahzeel. We look at a few metrics for Scrumban teams: lead time, cycle time, and throughput. Lead time is the amount of time it takes from the time a work item enters the backlog until it's delivered (so backlog to done). Cycle time is the time from when work starts (it moves to In Progress) until it's delivered. And throughput is the number of items we can complete in a certain timebox (say 2 weeks). There are some other metrics we can view (like control charts) that plot those items over time so we can see how consistently we're delivering. We don't want a lot of variation but there are likely to be outliers that take much longer. I hope that helps!

[@jahzeelramoscalosairri8851]

@@Artemisagile it does! Thanks for your answer. By any chance, do you know if there are any available reports for those metrics in Jira Atlassian software?

[@BlackbeltEntrepreneur]

Would love to see how Scrumban is used for those in SAFe Agile Release Trains

[@Artemisagile]

Great question. SAFe recognizes that teams may be working in ways other than Scrum (especially Kanban). They should still do the same kinds of things during PI Planning (such as creating PI Objectives). SAFe does expect that Scrumban and Kanban teams will still slot work into iterations during PI Planning even if the execution during the PI is going to be different. They'll still participate in the Train-level meetings (Scrum of Scrums, PO Sync, etc) and will demonstrate what they produced during the System Demo for the Train. It's a pretty poorly-understood idea within most SAFe implementations because most teams run Scrum or something similar. But we will need to describe the work we're doing/value we're delivering at every sprint boundary - the same as teams working in Scrum. While it's less ideal, one of the core values of SAFe is alignment which is achieved primarily through planning and execution cadences. The main article on doing Kanban (or Scrumban) at the team level is described in this article: www.scaledagileframework.com/team-kanban/ I hope that helps!

[@zoranvujkov1323]

Great video and explanation. I have got one question: if you need to do some kind of projection I guess you would use average number of requirements/tasks/tickets team can deliver per week? What is your experience regarding that?

[@Artemisagile]

Hi Zoran! If you're looking for forecasting, you'll typically look at the throughput (the number of items the team completed over the course of a timebox) or, if you're using story pointing because the work is different sizes, you can calculate a velocity over that period as well. That should give you a good representation of what the team can typically produce and, as we know in agile, past performance is a pretty good indicator of future performance. You should also be looking at cycle times and possibly looking at how long work items stay in individual states to see if there's waste you can eliminate (delays, hand-offs, etc.). That will help you continuously improve your team's performance. Hope that helps. Thanks for commenting!

[@burrillgray4812]

That would be Release Planning which, for all intents and purposes, precedes Sprint Planning; that involves other higher order skills. One side note: Sprints are NOT about predicting, but rather about Adapting!!

[@CyclingDad]

Great video!

[@Artemisagile]

Thank you! Very happy you enjoyed it.

[@CyclingDad]

+Artemis Agile Consulting I'll need to watch it again and take some notes

[@Artemisagile]

After reviewing this, did you have any questions? Let me know if you need anything!

[@portioncontrol]

Where can i find that 8 Ball magic estimating App?

[@Artemisagile]

Hi Pierre-Gilles. Sorry for the delayed reply - I never got notified that you'd commented. I don't have it available anywhere right now. But if you're interested, I might just release it for general consumption. Let me know and I'll get it published to Apple App Store and Google Store.

[@Artemisagile]

And it's free of charge. It would be ridiculous to charge for it. :)

[@skaterdude14b]

19:49 I’m your basic average girl

[@TheMainphrame]

great cat. 11:57

[@cyrock911]

The first step is to have fewer meetings, and waste less time in order to be more efficient coding. This video is about an hour long, I think thats a fail just right here. Beside that, there's some interesting informations.

[@Artemisagile]

The presentation was that long because it's more than just about how to do it, but also a case study of a team that underwent the transformation. Be cautious about fewer meetings as a metric; focusing on more effective or efficient use of time is a better one. Some teams need more meetings but they're shorter and more focused - and more effective as a result.