Introduction by Planview AgilePlace COO Jon Terry
We know — we geek out a lot about people using us for construction, or manufacturing, or logistics, or auto repair, or talent management or whatever. Our business at Planview AgilePlace really has spread quite a bit beyond our software development management roots by now. But, we still recognize that our core business (and our hearts and heritage) are in the IT department. And, within that broad area, some of the most successful Kanban implementations (of Planview AgilePlace or any other flavor) are IT operations groups.
Kanban is just a natural fit for Ops people who want to be Lean-Agile, but for whom the idea of Scrum’s fixed iterations just makes no sense. Indeed, we’ve seen the increased speed of Scrum actually cause problems for Ops teams as they struggle to balance quick-moving competing demand. They get stuck as the punching bag in the Scrum of Scrums!
Today’s guest blogger, Dominica DeGrandis is one of the thought leaders in Kanban for Operations. She’s a long-time Ops person herself and a long-time associate of Kanban trailblazer David Anderson. Dominica speaks often on the Lean/Agile/Kanban conference circuit and offers Kanban training targeted at people in Ops. She also edits the Kanban Weekly Roundup at the David J. Anderson & Associates blog. We’re thrilled to welcome Dominica to the blog!
Handling Groups whose Problems are Giving you Problems
I’ve been pondering a bunch lately on how to handle external dependencies. I’ve come to the conclusion that, a) “External” needs to be amply defined and, b) “Risk” needs to be thoroughly examined.
If we define external to mean outside the control of our department, does that mean a different department down the hall in the same company? Or does it mean a 3rd party vendor in a different time zone who can’t remember the name of our company? Indeed, there might be situations where working with a 3rd party vendor in Poland is easier than working with the sales department down the hall.
The key seems to lie in understanding the risk associated with the dependency. What is the cost if the dependency isn’t received on time? What kind of track record does the external entity have? Examples could go on and on. Here’s a sampling:
- The group that “contributed” to our department missing the release date on a regulatory requirement the CFO promised the owner of the company. Strategy? Maybe future dependencies relying on this group (if they are still around) ought not to be pulled into the kanban board ready queue until this group confirms their part is done.
- Or the group that generally meets its deadlines, but tends to optimize locally? Strategy? Maybe place this kind of dependency risk in a separate “Waiting For” area of the kanban board with Service Level Agreements (SLAs) displayed for management to deal with.
- Or the group that regularly sends a member of their team to our standup. They are on-board with “optimizing the whole” of the organization versus narrowly focusing their energy on their departments function. Strategy? Maybe a dependency on this group could be considered low-risk and we might allow a dependency card to hang with its associated card in our standard workflow. But maybe, our policy would only allow this when there are no issues.
Once an issue comes up, the dependency card could get a pink sticky attached indicating blockage. But is this sufficient to signal an escalation to the right person? Even if the team morphed the dependency card into the expedite lane, what good would it do if the issue could only be addressed by someone external to the team? External issues outside of the control of our department likely need management attention in order to minimize the risk impact.
We can look at external dependencies as different levels of risk. A dependency risk-range if you will, where high-risk dependencies are more obvious than low-risk dependencies. Ideally, sufficient information is on the card, allowing the team to re-evaluate the risk level if need be – a handy ability in an ever-changing world when earlier priority decisions on risk may have changed – and not everyone was informed.
External dependencies need visibility on risk. We can demonstrate this risk by introducing a risk-range area for external dependencies in our kanban system design. Kanban cards offering up criteria to determine risk should warrant brownie points.
![New Perspectives from the The 2018 Project Collaboration Survey [Webcast]](https://blog.planview.com/wp-content/uploads/2018/06/diverse-teams.gif)
![A Global Collaborative Work Management Blueprint [Video]](https://blog.planview.com/wp-content/uploads/2019/07/A-Global-Collaborative-Work-management-blueprint.png)
