Scrum to Scrumban in 6 Steps + FREE Cheat Sheet

Summary

In this engaging video, "Development That Pays" creators introduce you to the transition from Scrum to Scrumban in a seamless six-step process. This compelling guide walks teams through evolving their Agile practices by layering Kanban systems on top of Scrum structures, ultimately adopting a pull-based approach. From visualizing workflow and setting work-in-progress limits to stopping early binding and repurposing planning sessions, these steps aim to foster efficiency and productivity. Gary Strawn cleverly outlines how this transition maintains key elements of Scrum while introducing significant Kanban principles and lean methodologies. The video suggests retaining useful Scrum rituals and offers a cheat sheet for viewers eager to apply these fresh strategies in their teams.

Highlights

• Scrum to Scrumban in just six steps! Get your team agile-ready 🚀.
• Visualize your workflow to take the first step towards improvement! 😎
• Implement WIP limits to streamline tasks and combat context switching 🔄.
• Leverage Kanban's pull system to supercharge your Scrum framework 💪.
• Say goodbye to estimation! Embrace prioritization for a leaner process 👋.
• Our cheat sheet will guide you through transforming Scrum practices smoothly 🗺️.

Key Takeaways

• Transitioning from Scrum to Scrumban involves six manageable steps to enhance Agile efficiency 🚀.
• Key steps include visualizing workflows, imposing work-in-progress limits, and adopting a pull system 🛠️.
• Scrumban adaptation requires moving away from early binding towards ordering and prioritization 📋.
• The elimination of estimation in favor of more straightforward prioritizing boosts agility and focus 👀.
• Switching to triggered planning sessions can further refine backlog management and task delegation 🗂️.

Overview

In an insightful episode, Gary Strawn from "Development That Pays" takes viewers on a journey from Scrum to Scrumban. By integrating Kanban's efficient pull system with Scrum's robust framework, teams can streamline their process while maintaining the necessary rituals that keep them grounded. This evolution eliminates redundant estimation tasks, focusing instead on prioritization to boost productivity and efficiency in software development.

The video kicks off with simple tasks like visualizing workflows and enforcing work-in-progress limits. As the team adapts to these methods, they gradually introduce more advanced concepts like triggered planning sessions and eliminating estimations. These changes not only simplify workflows but also enhance team collaboration, unlocking the full potential of Agile practices.

To support this transition, Gary provides a cheat sheet as a handy resource for teams ready to embrace Scrumban. The video encourages viewers to retain beneficial Scrum rituals while adopting novel approaches to planning and workflow management. Ultimately, this transformation aims to deliver high-value items efficiently, maximizing both speed and quality of software delivery.

Chapters

• 00:00 - 00:30: Introduction to Scrum and Scrumban In this introductory chapter, the author Gary Strawn plans to take the audience from understanding Scrum to mastering Scrumban in six steps. The chapter promises a detailed walkthrough and offers a cheat sheet to assist in the learning process. The context is set in the realm of profitable software development, underlining the author's channel, 'Development that Pays,' which aims to provide valuable insights to software developers. Gary encourages new viewers to subscribe and stay updated by pressing the notification bell icon.
• 00:30 - 03:00: Visualizing Work in Scrum and Scrumban The chapter introduces Cory Ledus, who is credited with inventing 'Scrumban.' The term 'Scrumban' is explored as not just a middle ground between Scrum and Kanban, but as a pathway evolving from Scrum to other methodologies. The discussion invites viewers to revisit previous episodes for more context on these methodologies, positioning Scrumban as a progressive path rather than a transitional state.
• 03:00 - 06:00: Introducing Work-in-Progress Limits This chapter discusses the introduction of work-in-progress (WIP) limits within agile frameworks, particularly focusing on the transition from Scrum to ScrumBan. It highlights the widespread adoption of Scrum as an initial step for teams embracing agile methodologies. The narrative suggests an exploration of how teams can effectively transition from Scrum to ScrumBan, prompting the reader to observe when and how the transition occurs during the process.
• 06:00 - 11:00: Implementing a Pull System The chapter discusses the implementation of a Pull System and starts by highlighting visualization as the first step. It suggests that many teams, such as those using Scrum, might already have a visual board, although it is optional in Scrum. However, in Kanban, having a visual board is mandatory as it is a key principle of the methodology.
• 11:00 - 15:00: Stop Early Binding and Start Ordering The chapter introduces a minimalistic approach to scrum, highlighting the importance of having a basic board to begin with. It emphasizes the significance of early-stage organization within a team and suggests a quick adaptation to the sprint planning process. It encourages the team to engage in a brief sprint planning session to initiate effective workflow management.
• 15:00 - 18:00: Eliminate Estimations The chapter discusses the process in Scrum project management, starting with the concept of 'tickets' or tasks that are placed in the to-do column, also known as the Sprint backlog. It emphasizes the daily routine of beginning with a stand-up meeting, highlighting an aspect that is commonly known among developers but seldom spoken about.
• 18:00 - 23:00: Moving to Triggered Planning The chapter titled 'Moving to Triggered Planning' deals with the challenges teams face when starting tasks but struggling to finish them. The transcript illustrates a common issue where, after a few days, a team might find themselves juggling multiple tasks at once, as shown by an example of three developers attempting to work on eight tickets simultaneously. This scenario highlights the importance of visualizing workflows to address inefficiencies, a crucial aspect of transitioning to a more structured and efficient planning approach. It implies that focusing on too many tasks at once can be counterproductive, and suggests that visualizing the work can help in prioritizing and managing tasks better.
• 23:00 - 28:00: Wrapping Up and The Value of Scrumban The chapter titled 'Wrapping Up and The Value of Scrumban' discusses the negative impact of context switching on productivity and introduces the concept of work-in-progress limits as a strategy to mitigate this issue, as adopted from the Kanban methodology.

Scrum to Scrumban in 6 Steps + FREE Cheat Sheet Transcription

• 00:00 - 00:30 previously I introduced you to Cory lettuce and scrum bond today I'm gonna be taking you all the way from scrum to scrum bond in just six steps and stay tuned to the end because I have a rather lovely cheat sheet for you welcome to development that pays the channel dedicated to profitable software development my name is Gary Strawn and if we were meeting for the first time please consider subscribing and remember to hit that Bell icon so you don't miss
• 00:30 - 01:00 a thing last time I introduced you to this man Cory led us and his invention I guess you could call it that scrum bond if you missed that episode and you'd like to catch up you can find a link to it over here as I said in that episode Cory didn't so much position scrum bond as a Midway halfway house between scrum and Kanban rather as a pathway from scrum to well to something else this I
• 01:00 - 01:30 think was a super shrewd move given the level of adoption of scrum and the fact that scrum is often the first step the team's take when getting in to agile so how easier said to follow this pathway from scrum to scrum ban well I think we should go and find out and as we travel keep your eyes open for the moment that we break or break out of scrum I think
• 01:30 - 02:00 you might be surprised at just how far we get before we do so step one visualize the work oh you thought this journey was gonna be difficult if you're like most scrum teams you probably already have a board and the board is just one of the things that scrum doesn't mandate in Kanban though a board is mandatory it's one of the key tenets of Kanban that we must visualize our
• 02:00 - 02:30 work so if you have a board even one as simple as this one then you've already taken your first step towards scrum bang congratulations at this point I'd like to introduce you to the team gonna be working with today I'm gonna ask them to take themselves off for a super quick sprint planning session and I do mean super quick [Music]
• 02:30 - 03:00 thank you very much team 8 items let's call them tickets in the to-do column as this is scrum are we could also call the to-do column the Sprint backlog they're effectively one in the same time to set to work starting each day of course with a daily stand up one thing that every developer knows but few will admit is
• 03:00 - 03:30 that it's much easier to start a job than to finish it so if we check in with this team again after a couple of days there's every chance that they're called look like this and this is where visualize the work starts to pay us back it's very clear that the three developers are attempting to work on eight tickets simultaneously I can spend a whole video a whole series of videos talking about why this is an undesirable
• 03:30 - 04:00 state of affairs starting with the cost of context switching but for now I think we'll just move on quietly to step to step to impose work-in-progress limits if you know anything at all about Kanban you'll know that one of the things it does is to impose work-in-progress limits so let's give that a go I'm going to rewind to the beginning and this time each developer is allowed to work on a
• 04:00 - 04:30 maximum of two tickets at any one time ideally it would be just one ticket but we know that things happen and tickets can get blocked so we're gonna give people just a little bit of leeway so two tickets maximum let's see here that plays out fast-forward a couple of days and oh it does seem now that we have all three developers working on exactly two
• 04:30 - 05:00 tickets we've given them the opportunity to work on two and they haven't been slow to take us up on our offer they've stayed within the letter of the law but the spirit of the law not so much think we should try a different work-in-progress limit something a little more Kanban style and I'm gonna do that not by applying a limit to a person but by applying a limit to the process the process here is
• 05:00 - 05:30 the in progress column and I'm gonna squish it so there's only room for one ticket in the column and I'm gonna draw a hard limit at five tickets it's hard to overstate the impact of what that simple change will have on this team starting with what happens when this occurs which it will now if the ticket
• 05:30 - 06:00 gets blocked the developer no longer has the option of reaching for another card it may be necessary and this could be a revelation for the team to work together to solve the problem to unblock this column quick question for you have we broken scrum yet no I don't think we have everything we've done so far is I think scrum compliant these are changes that you could make to your team today
• 06:00 - 06:30 and maybe maybe you should another thing you may have heard about Kanban is that it is a pull system and indeed it is I'm about to use that term pull system rather a lot so I think we should look at a very quick example an example that you've probably experienced you go into a restaurant let's say it's a fairly fancy restaurant and you order yourself an omelet believe it or not you just
• 06:30 - 07:00 triggered a Kanban pull system the first of a series of polls the waitress writes down your order and takes it to the kitchen now that piece of paper is the Kanban kanbans literal meaning is signal or sign so that note arrives in the kitchen question does of the chef start on your omelet immediately well she might if your order is the first of the day but if she's already preparing a
• 07:00 - 07:30 meal someone else do you think she should start your omelette as well or would you prefer that she waited until that other dish was finished I think you already know the answer she's gonna focus on finishing the current dish then and only then will she reach for the piece of paper with your omelette order and then she'll set to work on your omelette ignoring any other orders that come in while she's busy when the omelette your
• 07:30 - 08:00 omelette is ready the chef will ring the bell to indicate to the waitress that it's time to bring you your omelette and that bell that's the second pole that's the pull system in a restaurant let's see the same thing in action back at the office and believe it or not the pull system here is enabled by this line and here's how when a card moves to the right it frees up space and it is this
• 08:00 - 08:30 base that is the signal the Kanban a signal to the team to pull another card from the left I think it's great that we've added a pole to our board but I think I think we can take it up a notch step number three add more columns step one was about visualizing workflows and
• 08:30 - 09:00 this board was not a bad start but for most teams the workflow is a little more involved than this let's reflect that by replacing in progress with a column for development and a column for testing each of course with their own work in progress limits so they're poles form to do and test pulls frog ah yeah that doesn't quite work as thanks Stan dev is pushing
• 09:00 - 09:30 into test let's fix that by introducing a buffer between the two excellent now we have a place for the developers to put cards that they have finished and test is now empowered to pull tickets in when they are ready to test excellent let's move on to the next step step four stop early binding and start ordering I wonder if you know this way
• 09:30 - 10:00 back when we did the super speedy sprint planning session that not only did we assign points to each ticket we also assigned people quarry refers to this as early binding and while there's probably short-term benefit in giving work to the expert in the long term the team's ability to handle anything that's thrown at it will suffer again that's something we could spend a long time discussing but quite apart from the impact on the
• 10:00 - 10:30 long term performance of the team this early binding can jam up our perfectly positioned pole system Bryan's about to pick up this ticket even if it's the least important card here and Carol doesn't have a ticket to pick up at all at least she won't without a discussion with her colleagues so let's not do this in scrum bond we swap early assignment for ordering and prioritization and to
• 10:30 - 11:00 make this explicit I'm gonna create a new column called ready these are cards that are ready to pick up hand importantly they are presented in order with the most important at the top so all things being equal when a developer is ready to pick up to pull a card this is the card to pull the one at the top the one that is most important three steps down two to go
• 11:00 - 11:30 have we broken scrum yet I think not perhaps the next step is the one that will tear step 5 stop estimating on our journey so far there's been no shortage of Kanban principles but now it's time to layer on just a little bit of lean in lean as I'm sure you know every action that is considered not to have value is considered to be waste and it can be
• 11:30 - 12:00 argued that estimating backlog items does not add value and should therefore be considered a waste and this should therefore be eliminated now that argument and I know it's a controversial one is beyond the scope of what I want to talk to you about today but rest assured we will be coming back here on development that pays to discuss it more fully so do stay tuned but for now back to the action where was I oh
• 12:00 - 12:30 yes in scrum ban there is no estimating no story points no planning poker the sprint planning session becomes a session purely about prioritizing work and not about sizing work that sound was the sound of scrum breaking yes we've now stepped outside of the boundaries of scrum and were well on our way to scrum by but we're not quite there there's one step still to go step six move to
• 12:30 - 13:00 triggered planning there's an aphorism that goes along the lines of don't test what you can't release and don't develop what you can't test and the board is now perfectly set up to deliver this test is pulling from ready to test develop is pulling from ready ready is pulling from the sprint backlog sprint backlog is that's yeah that's
• 13:00 - 13:30 where it breaks down how do things get in to the sprint backlog well we take ourselves off for a sprint planning session a session where we move items selected items from the product backlog in to the sprint backlog would it be fair to say it like this we take items from the product backlog and push them into the sprint backlog mmm I think you
• 13:30 - 14:00 can see what I'm getting at here this part of the process is starting to look like a bit of an odd one out but is it even possible to apply a pull system to this part of the process instead of scheduling a sprint planning session every two weeks could we trigger a planning session on demand we could and if we want to do scrum bun we must the enabler for this is another line when the number of items in this column
• 14:00 - 14:30 drops below a certain point the trigger point then it triggers the need for a planning session sprint planning happens for most teams once a fortnight so a valid question would be does this triggered planning session happen more frequently than once a fortnight well the chances are that it could possibly that it should but don't quit on me yet these sessions remember are much more lightweight no planning poker no story
• 14:30 - 15:00 points the focus of the meeting becomes only on prioritization answering the question what are the things that the team should work on next I'll wrap things up in just a second but first the small matter of the cheat sheet that I mentioned at the beginning it is used to download today it will cost you an email address the email address I will use to send you updates or development that pays cheat sheets improve over time and
• 15:00 - 15:30 when they do you'll get the copy in the mail you'll find a link to it somewhere around this video let's get right back to the action so we've made it all the way from scrum to scrum by an e6 steps along the way we lost the concept of a sprint but did we also lose the Sprint review and the retrospective not at all we'd be wise to retain these rituals from scrum although
• 15:30 - 16:00 now we're gonna have to be disciplined about scheduling them in along the way we stopped estimating which I guess means that we no longer have an indication of the team's velocity and therefore we no longer can forecast accurately actually that's not quite true we still have the power to forecast but that really is a tale for another day so we've dropped a couple of things along the way but what have we gained by
• 16:00 - 16:30 taking scrum and layering on a generous portion of Kanban and a sprinkling of lean we've exchanged a relatively heavy weight framework for a lightweight one we've bought ourselves a little more development time but most importantly we've implemented for ourselves a fully fledged pool system a system that helps us to identify high-value items and to get those high-value items from backlog to customer in the shortest possible
• 16:30 - 17:00 time that is the promise of scrum bond so question of the day would you consider taking your team on this journey or at least on part of this journey from scrum the scrum bond let me know in the comments below thank you very much for watching I hope you enjoyed this episode as much as I enjoyed making it if you did I would appreciate a thumbs up and remember to hit that logo to subscribe for a brand new episode each and every Wednesday I
• 17:00 - 17:30 will talk to you again very soon