Advertisement

Kick Chaos-Driven Delivery to the Curb by thinking like an Operating System

Manager, Customer Education & Improvement Coach at LeanKit
Jun. 9, 2016
Advertisement

More Related Content

Advertisement

Kick Chaos-Driven Delivery to the Curb by thinking like an Operating System

  1. Kick Chaos-Driven Delivery (CDD) To The Curb
  2. @everydaykanban The Chaos of Firefighting
  3. @everydaykanban Eureka!
  4. @everydaykanban
  5. Myth: Multi-tasking is achievable @everydaykanban www.scienceprog.com
  6. @everydaykanban Reality: We actually rapidly switch tasks
  7. Choosing a method to schedule work Four common methods used by Operating Systems @everydaykanban
  8. First Come, First Served @everydaykanban 1.
  9. Shortest Job First @everydaykanban 2.
  10. @everydaykanban Scheduling by 3.
  11. Round Robin @everydaykanban 4.
  12. @everydaykanban How long do I have to wait?
  13. @everydaykanban I’ve been waiting a long time
  14. @everydaykanban Wait… there’s no purrfect scheduling method?!?
  15. @everydaykanban Blend methods; balance tradeoffs
  16. @everydaykanban One common blend:
  17. @everydaykanban
  18. @everydaykanban
  19. @everydaykanban
  20. @everydaykanban

Editor's Notes

  1. Hello, my name is Julia Wester. I work as an improvement coach at LeanKit and I’m here to talk about kicking the rampant chaos driven delivery to the curb by thinking like an Operating System and creating explicit policies to manage work!
  2. Many teams, especially Ops teams, experience high levels of chaos trying to manage the variety of demands on their time. Without a defined approach to managing work, they end up catering to the whims of the loudest voice.
  3. I realized these chaotic Ops teams work with systems that effectively deal with similar challenges. So, I decided to take a look at those systems to find ways to help Ops teams see they already know a lot about taming chaos.
  4. Enter the OS. It gets bombarded with multiple requests at unpredictable intervals too. Yet, it is able to process its work in a very effective manner. I thought we should look at the methods it may use to see if they might be appropriate for our contexts.
  5. But first, we must come to terms with the fallacy of multi-tasking. An OS can only process one item per core at a time and we can only have one thought at a time. However, the goal of the OS is to make users believe it can multitask effectively.
  6. We fool ourselves often on this matter. What we actually do is rapid task switching. We cycle through pieces of multiple tasks one after the other and incur transition costs. We need to be smart about how often we task switch.
  7. So, how does the OS decide what to work on and how much to task switch? Well, an OS is coded to follow a set of explicit policies. There are multiple policies to choose from and each has its pros and cons. Let’s look at four of the most common.
  8. The first is First Come, First Served. Its fair and scheduling overhead is low, but cycle times are usually longer. Also, it doesn’t account for priority or size, so it’s better for teams that have homogenous work – which usually isn’t the case for ops or dev teams.
  9. Shortest job first keeps short jobs from being stuck behind long ones. But, Longer-running jobs may never be started. But, we often lack duration info and have a tendency to estimate badly, so this method is the least ideal on the list in my opinion.
  10. Priority scheduling expects you to assign priority to each job and executes it in order of highest priority. This is a commonly used method in teams. But, with a constant flow of the highest priority jobs, other important work may never be completed.
  11. So people may turn to round robin which processes each job in the queue for a set time and repeats. If a job can’t finish in one time unit, it waits for another turn. No work is ignored but it can take a long time to finish a job if you have a large queue.
  12. Each method except Round Robin led to certain work being ignored and that usually isn’t acceptable. We can achieve better success by discarding work that is not valuable or feasible up front and then including a safeguard against starvation of any remaining work.
  13. One strategy an OS uses for this is to assign portions of capacity to each work priority or type. This helps avoid creating emergencies by inaction. In addition, it can reserve some flexible capacity that can go where its most needed.
  14. Thoroughly unsure of what to do? Well, you’ve likely figured out that no one process alone is likely to be perfect for you. Yet you can still learn from the scheduling methods used by an OS to help you decide how to process requests. No one said we had to pick just one.
  15. My suggestion is to combine the best parts of one or more methods. First, evaluate all options for pros and cons. Each con represents a trade-off. Trade-offs are a reality for us, they just need to be acceptable for our specific context.
  16. A common option is to blend the priority method that we often see together with a round robin approach. So, each item has a priority and we work from highest priority downwards BUT we work on them in chunks so no priority class gets ignored.
  17. The key is to break down work into small, but valuable pieces. At LeanKit we have the concept of FizzGood. In a round robin, aim to deliver something of value in each cycle, even if small, so that the feeling of death by waiting is reduced.
  18. One step farther is dedicating people to certain priorities or types of work to allow focus which reduces cycle time. However, we also want to reserve flexible capacity that can move b/t teams. Finally, in the groups, allot capacity to preventative work.
  19. Key takeaways are: Look to your environment for applicable ideas for taming your everyday chaos. Consider the trade-offs of each idea and make sure they’re not too costly for your context. And finally, make your work FizzGood and don’t let any work starve!
  20. You can continue the conversation on twitter with me, everydaykanban. Thanks for listening!
Advertisement