To deepen your understanding of Kanban and flow, here are some questions.
Which of the following would be pull signals for grocery shopping?
- The refrigerator is almost empty
- Essential items are running low or are out
- There’s a specific recipe you plan to make that requires ingredients you don’t currently have
- Fruit and vegetable drawers are empty or near empty
- You’re out of your go-to snacks
- Staple items like rice or pasta are running low
- Your preferred beverages are running out
- There is space for new groceries
- It’s a new day
- You have coupons or items are on sale that you frequently use
- You’re expecting guests and need to prepare meals or snacks
- You notice certain items are nearing their expiration dates and need to be replaced
- You’re planning meals for the upcoming week and need specific ingredients
- The weather forecast suggests it’s a good day for shopping and transporting groceries
- It’s your regular grocery shopping day (Saturday morning)
Which of the following would be pull signals for doing laundry?
- The washing machine is currently not in use
- There’s an empty spot on the drying rack or line
- It’s your regular laundry time, e.g., Sunday at 3 PM
- A few clothes are in the laundry basket
- The laundry basket is filled to the brim
- Clothes are spilling out of the laundry basket
- You’re out of fresh clothes to wear
- There is space in your wardrobe for clean laundry
- There’s a specific garment you want to wear that’s dirty
- You spilled something on your shirt
- You’re expecting guest
- You’re preparing for a trip and need to pack clean clothes
- There’s a forecast for good weather, ideal for drying clothes outdoors
- It depends on the complexity of the laundry
Historically, items have finished within 14 days or less 85% of the time. You then start a new item, and the chances of missing the Service Level Expectation (SLE) is 15%. If the 85th percentile line changes as you work on the item, does that change the probability of the already started item meeting the new Service Level Expectation (SLE)?
- Yes
- No
- Maybe
- It depends on the complexity of the item
The probability of not meeting the Service Level Expectation (SLE) changes linearly over time. This means that for each day an item remains in progress, the probability of not meeting the SLE increases by a constant number of percentage points. Is this statement true or false?
- The relationship is always linear
- The relationship is always non-linear
- The relationship is always unknown
- The relationship follows the normal distribution
- It depends on the complexity of the item
The likelihood of fulfilling a Service Level Expectation (SLE) increases as the item progresses further along in the workflow.
- Always true
- Always false
- You would have to analyze the data further
- It depends on the complexity of the item
The likelihood of meeting a Service Level Expectation increases as an item progresses further along in the workflow.
- Yes
- No
- Sometimes
- If it’s being worked on
- Only if it’s not blocked
- Not if it spends any amount of time whatsoever in a queue state
Historically, no item has ever finished within 30 days. In this scenario, you should communicate a Service Level Expectation where the start of the range is 30 days.
- Yes, for example you should say “between 30 and 60 days 85% of the time”
- No, you should always say things like “60 days or less 85% of the time”
- It would require more analysis of the data
- It depends on the complexity of the work item
Multi-item forecasts have Service Level Expectations (SLEs)
- True
- False
- Depends on whether it’s a release or just a pile of items
- Depends on the complexity of the items in the forecast
A starting point for a work item will always be
- When it enters a particular state
- When it exits a particular state
- Wherever there is a state change happening
- Depends on the complexity of the items
- Depends on the type of work item
A state can be single column, a group of columns, a lane, or a whole board
- True
- False
- Depends on the complexity of the items
“Blocked” is a valid state in any workflow
- True
- False
- Yes, and not only that, it would be a valid state anywhere in a workflow
Which states should you in general try to avoid having?
- To Do
- Doing
- Done
- Review
- Waiting
- Blocked
- On-hold
- Expedite
- Refinement
- Waiting for clarification
- QA
- Estimating
- Waiting for John Coleman
- Backlog
- Right-sizing
- Waiting for reply
- Cancelled
- Can’t start
- Inactive
- Queued
- Ready
- Active
- Knowledge transfer
- Dependency identified
- In Progress
- To Do / Blocked
- Monitoring
- Gathering feedback
- Blocked to start
- User Acceptance Testing
- Subdivided states where you have “Active” and “Finished”
- Archived
- Complex
- Unclear
- Vague
- Big
A Definition of Workflow (DoW) must include enough policies to ensure that a workflow would always eventually become empty if no new items arrive
- True
- False
- It depends
A Definition of Workflow (DoW) must include enough policies to ensure that no single item will ever get stuck indefinitely
- True
- False
- It depends
Rigid work-in-progress limits destroys autonomy
- True
- False
- It depends
In actively managing work items, what would be the most useful?
- Going through all items in the workflow
- Going through at least one item per person participating in the workflow
- Looking at the oldest (least recently started) items first
- Looking at the most recently started items first
- Looking at unstarted items and trying to start those as soon as possible
- Cancelling items where there has been no activity for a while
- Rewriting unclear items
- Breaking items into smaller items
- Going through the items, from the last workflow state to the first workflow state
- Going through items that are blocked
- Going through items that have violated their Service Level Expectation (SLE)
- Updating the status of each item at least once per day
- If an item gets stuck, we start a new one immediately to improve efficiency
Context-switching is always inefficient
- True
- False
- It depends
Expectations, timelines, timeboxes, and so on, should be based on
- Data
- Assumptions
- Guesses
- Wishes
- Demands
- What the customer demands
- What the organization demands
- Career ambitions
- Current amount of items in progress
- Current amount of queued items such as “Backlog” or “Options”
- Current amount of items in the workflow in total
- Monte Carlo forecasts
- Graphs
- Averages
- Charts
You can forecast when a particular outcome will be achieved
- Always
- Sometimes
It is possible to make process improvements without downsides
- Always
- Sometimes
- Never
There are times when answering “When Will It Be Done?” is impossible
- Yes
- It’s always impossible
- You can always say something
If your forecast was wrong, you should
- Update it
- Communicate that it was wrong
- Do everything you can in order to meet the original forecast
- Spend more time on analysis next time
- Call a workshop
- Get more people to work on the forecasted work
- Renegotiate the work
- Cancel the work
- Reduce the scope of the work
- Cancel something else
- Hire more people
- Hire consultants
- Hire expensive consultants
- Hire really expensive consultants
- Get agile coaching
- Buy a whiteboard
- Accept it, and learn from it after delivery
If we were to update the agile manifesto, we could
- Change “Individuals and Interactions Over Processes and Tools” to “well-defined processes and appropriate use of tools that are fit for purpose”
- Change “Working Software Over Comprehensive Documentation” to “deliver what customers want when they want it”
- Change “Customer Collaboration Over Contract Negotiation” to “deliver what customers want when they want it”
- Change “Responding to Change Over Following a Plan” to “ask the right questions sooner”