I interviewed @dominicad (Dominica DeGrandis), who teaches and coaches teams using Kanban for IT Operations and Development Operations. She is an independent consultant as well as an associate of David J. Anderson. Her background includes ten years of doing Configuration Management, build and deployment automation, and server & environment maintenance, followed by leading teams performing those functions.
Dominica is my podcast guest next week. In lieu of a written excerpt introducing the podcast, I removed the portion of podcast that specifically discussed Dominica’s Dev/Ops Class. From Dominica’s website:
The DevOps movement is shifting the focus away from separate departments working independently to an organization-wide collaboration — a “systems thinking” approach. It’s about addressing all the work as a whole, versus looking only at the bits and pieces, or only looking at capital versus expense. It’s about work flowing across functions (versus lurking in silos) and delivering the right thing quickly.
I think whether you are a Dev/Ops or just a Kanban fan, you can take some insight from her workshop outline.
Audio file on Dominica explaining her Dev/Ops Class
Well heck, a short excerpt from the podcast:
Joe: One of the statements I heard in your talk in Boston is that you can set policies in place, instead of solutions. Could you explain what you mean by that?
Dominica I love policies. We talk about making policies explicit. This is all about, stop hiding the rules. That’s really what we mean when we say, “Make process policies explicit.” “Stop hiding the rule on page 200 that’s in some document that’s buried out on a share that nobody can find.” If there’s a policy, for example, say developers are supposed to check their code into this branch, then put it up, make it visible to them. Especially new people being hired, they don’t know where to go find policies. Put policies up next to your Kanban board, or put them at the bottom of your Kanban board. Sometimes you’ll see a policy at the bottom of each column, and that’s the policy for the criteria before the item can be pulled into the next column. Policies can be changed when they need to be changed.
Policies are really just a short?term, tactical fix to make an improvement while you’re waiting on some longer term strategic fix. Policies can come and go, and be modified. The idea is that if a policy is staring at you, it’s much easier than to have a discussion about why it’s a bad policy or a good policy, or how it needs to be changed.
Another short Audio with Dominica DeGrandis discussing Personal Kanban
P.S. There is plenty of material left for the Podcast next week!
Comments are closed.