What strategies can we use to cope with new work entering the system?
#3 Risk of unplanned work disrupting the work process and schedule
going deeper from a previous blog entry “Seven Risks in Software Development”.
To be more clear about what is meant by unplanned work: they are those
high-priority, new work items that the team feels cannot be refused or be delayed.
Example: you manager requests something the an executive vice-president wants completed in 2-days.
Most common scenario: the work-item is taken on as requested. Other “in-flight” work-items are put aside for a while and one of three common outcomes occurs:
- Team (or some team members) works overtime to make all work-items happen on-time.
- All or some of the other work-items are delayed.
- The other work-items are delivered as scheduled, but with poorer quality.
There are 4 strategies to help cope with unplanned, high-priority work.
- Adhering to prior work-in-process (WIP) limit agreements.
- Kanban – queued to be pulled when capacity allows.
- Scrum – deferred until the next sprint.The delivery team is saying “no” to taking on the requested work immediately because of prior agreements about how work is accepted. Sometimes these WIP limit agreements work and sometimes they break down because of pressure. So just like antivirus software, good to have in-place because it does work sometimes.
- Slack – the emergency responder model – have excess team capacity to deal with these unplanned requests.Example 1: production support rotates week-to-week among team members and that non-available resource is not considered when planning for team capacity.
Example 2: team lead does not usually start any planned work assignments. And then when something comes in, the team lead takes it on directly or stands-in for another team member who takes-on the new high-priority, work-item.
The person in the slack resource role, must be able to drop current work to deal with high-priority, work-items and do so in a way that does not affect the team’s performance for committed work.
- Visualize the effect of high-priority, unplanned work has on the team’s cycle time (see Risk of missing the delivery schedule because of poor predictions for more information on cycle time)Here we are saying the above two strategies either do not work most of the time or cannot be implemented. Example: because of budget, there is no possibility of placing slack in the team.
Visualizations methods from Daniel S. Vacanti’s book “Actionable Agile Metrics for Predictability” include:
- Cumulative Flow Diagrams (CFDs)
- Cycle Time Scatterplots
- Cycle Time Histograms
- The bad effect that an increased cycle time has on the 85 percentile when running Monte Carlo simulations from the team’s delivery data.Note: we assume the performance of the 85 percentile is what can be communicated back to the business for service level agreements (SLA) or service-level-objectives (SLOs).
- Class of Service for high-priority workIn Kanban, you can design your workflow board to include a special swim-lane for high-priority items. Normally, this swim-lane will have a WIP limit of 1.
This works, when there is capacity to service the swim-lane. Otherwise, this special, swim-lane will disrupt the work-items already in-play.
However, there are ways for the business stakeholders and delivery teams to meet in the middle by setting up a very limited, high-priority, swim-lane or “silver bullet” than can only be used by the business stakeholder(s) (e.g., product owner) once a quarter.
Question: what would any group of managers / product owners / product managers do when there is a special, high-priority, swim-lane with a WIP limit of 1?
Answer: keep it filled. That special queue is a GREAT way to get my “special” work requests completed fast!
Daniel S. Vacanti has a wonderful write-up in his book – Chapter 13 – Pull Policies – about the effect that “special queues” can have in small US airports and then the negative effect special queues and the resulting pull-in-new-work practices can have on both predictability and cycle times.