{"id":12438,"date":"2012-03-15T08:28:41","date_gmt":"2012-03-15T13:28:41","guid":{"rendered":"https:\/\/blog.planview.com\/?p=12438"},"modified":"2020-02-25T08:32:30","modified_gmt":"2020-02-25T14:32:30","slug":"handling-groups-whose-problems-are-giving-you-problems","status":"publish","type":"post","link":"https:\/\/blog.planview.com\/handling-groups-whose-problems-are-giving-you-problems\/","title":{"rendered":"Handling Groups whose Problems are Giving you Problems"},"content":{"rendered":"

\"\"<\/h4>\n

Introduction by Planview AgilePlace COO Jon Terry<\/em><\/h4>\n

We know \u2014 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\u00a0software development management<\/a>\u00a0roots by now.\u00a0But, 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.<\/p>\n

Kanban is just a natural fit for Ops people who want to be Lean-Agile, but for whom the idea of Scrum\u2019s fixed iterations just makes no sense. Indeed, we\u2019ve seen the increased speed of Scrum actually cause\u00a0problems for Ops teams as they struggle to balance quick-moving competing<\/strong>\u00a0demand. They get stuck as the punching bag in the Scrum of Scrums!<\/p>\n

Today\u2019s guest blogger, Dominica DeGrandis is one of the thought leaders in Kanban for Operations. She\u2019s 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\u00a0the David J. Anderson & Associates blog.\u00a0We\u2019re thrilled to welcome Dominica to the blog!<\/p>\n

\n

Handling Groups whose Problems are Giving you Problems<\/h2>\n

I\u2019ve been pondering a bunch lately on how to handle external dependencies.\u00a0 I\u2019ve come to the conclusion that, a) \u201cExternal\u201d needs to be amply defined and, b) \u201cRisk\u201d needs to be thoroughly examined.<\/p>\n

If we define\u00a0external<\/em>\u00a0to 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<\/sup>\u00a0party vendor in a different time zone who can\u2019t remember the name of our company? Indeed, there might be situations where working with a 3rd<\/sup>\u00a0party vendor in Poland is easier than working with the sales department down the hall.<\/p>\n

The key seems to lie in understanding the risk associated with the dependency. What is the cost if the dependency isn\u2019t received on time? What kind of track record does the external entity have?\u00a0 Examples could go on and on. Here\u2019s a sampling:<\/p>\n