DevOps and Kanban

Business901 Podcast Transcription
Implementing Lean Marketing Systems

DevOps with Dominica
Guest was Dominica DeGrandis

Related Podcast:
How to unite Development and Operations

Copyright Business901


Dominica DeGrandis has taught the use and implementation of
the Kanban method to teams and organizations in San Francisco,
Seattle, Portland, Boston, New York, Philadelphia, Minneapolis,
Miami, Detroit, Salt Lake, Paris, London, Ghent, Munich,
Columbia... and counting.

The thrust of her work is to teach methods for managing and
improving workflow and communication between and within
teams and departments, especially the
workflow through IT. She is a proponent
of the DevOps movement and works to
bridge the gap between Development
and Operations teams.

After spending most of her career
synchronizing interactions and
dependencies between teams, Dominica
is keen on improving the way teams
work together to help bring alignment to the entire organization.
Dominica holds a BS in Information Computer Science from the
University of Hawaii. She is an independent trainer, coach and
international speaker.

She can be reached at dominica@ddegrandis.com and on twitter
at @dominicad when not in the yoga studio or the garden.


Transcription of Podcast
Joe Dager: Welcome, everyone. This is Joe Dager, the host of
the Business901 podcast. With me today is Dominica DeGrandis.
She teaches and coaches teams, using Kanban for IT operations
and development operations. She is an independent consultant,
with a background that includes 10 years of doing configuration
management, build and deployment automation, and server and
environment maintenance, followed by leading teams performing
those functions.
She has also filled the role of project and program manager. She
travels across the world speaking about her signature area of
work, improving interactions and dependencies between teams.
With a little time left, she spends it at the yoga studio or in the
garden.

Dominica, I would like to welcome you, and would like to ask you,
which have you been practicing longer? DevOps, or yoga?

Dominica DeGrandis: Hey, Joe, thanks for having me on. It's
great to be here. I have probably been practicing DevOps longer
than yoga, I would have to say. They wouldn't call it DevOps,
back 10, 12 years ago, but I
always seemed to be in a position Sponsored by
of the middle person between the
development and the operations
teams, and having to do handoffs
all the time, and handle
integration points. So that goes
back with my first job, out of
college.
Joe: I always thought of yoga as
an individual thing, finding peace
with yourself. But knowing that


you're an avid practitioner of yoga, what are some of the
principles of yoga that helps in teamwork?

Dominica: It's remarkable how the energy is different,
depending on the different people at the yoga studio. Sometimes
you'll go in, and there will just be a few people, and they might
all be fairly advanced. And there's a different rhythm that
happens when you have some advanced practitioners in the
room, versus if you're in, what I mean, a really big class. There
might be some beginners, there might be some people who have
never done yoga before, medium people, and advanced people.
The idea of vinyasa yoga, which is all about moving and flowing,
vinyasa's like a flow yoga. It's concentrated on breathing, and
your breath for different positions. So when you have a group of
people doing yoga together, and they're all breathing together,
there's energy in the room that starts to happen. I can feel it
happening in the room, and it's like everybody's in sync, and
supporting one another.
Even though I think initially it's meant to be as an individual, I
work out all the time with lots of people.
Joe: Let me dive into the teamwork a bit here. Is teamwork that
much different in DevOps than it is in other parts of an
organization?

Dominica: I believe so, yes. I believe that because there are
different incentives for development teams versus operations
teams. In the development world, you are getting paid, and you
are getting recognition for creating, developing, and deploying
new functionality into production. In the operation's world, we are
getting paid and recognized for keeping productions stable.
Anytime change is put into production, there is a risk of
destabilizing it. There're two opposite ends there as far as
incentives go. Usually these two things will report up to different


directors. Sometimes you'll have to go to a VP level to get a
common leadership point.

Joe: Well, you're a proponent of combining the two, aren't you?
Dominica: I'm a proponent of the DevOps movement. The
DevOps movement is about bridging that gap between the two
teams. You could merge these teams but not necessarily. It's
really meant to help bring an understanding of these different
teams so that they can break out of their individual functional
silos and start improving the way they work together for the
benefit of the organization as a whole. What's the real goal here?
Are we trying to deliver new functionality to get us a jump ahead
in the market? We want to start having teams look at that goal
instead of just only trying to keep production stable or only trying
to get the highest number of change request fixed in a limited
amount of time.
Joe: When we talk about that gap, to bridge it or bring it
together. The obvious thing is better communication, but there's
got to be more to it than that.
Dominica: Completely. I think the biggest thing is probably
bringing visibility. Bringing visibility to what the other teams are
doing. Many times these teams have heavy dependencies on each
other. The development team is dependent on operations
supplying them with environments and equipment. Access to
different databases and trying to bring some visibility to those
dependencies upfront and early on is very useful. Normally, we
don't have a lot of visibility between these two teams because
they're off in their own silo. They're off in their own world and
one team will say, "Oh, why does it take so long to get an
environment up?"

They don't have a clue at the struggles that some of these
operations teams have to go through just to get servers ordered
in or just to get refreshed from production. So this ability helps

bridge the gap between the teams and it brings them closer
together so they can understand and help. We want them to help
each other out.
Joe: Well, this may be naïve on my part to even say that, but
when you talk about the visualization, is that just putting a big
task board up there for everybody to see?

Dominica: It's a good start, putting the work that's being done
up on the board so people can see what tasks or what work items
need to be completed in order for the job to be done. "Done" is a
tricky word because what's the definition of "done?" In many
cases it's, "OK, I've coded up this story, and it's done. I'm
throwing it over the fence to operations. I'm done."
The idea is, well, no, it's really not done. It's not done until it's
working in production. Then we can all consider it done.
But even then I would say it's still really not done. Is it being
used in production? A lot of times we'll deliver functionality, and it
doesn't get used. I would say it's really never done until that
functionality is not in use anymore, and it's been sun set because
we still have to maintain it. We still have to maintain those
servers that run that functionality.
Joe: What's the difference between, let's say, a task board and a
Kanban board?
Dominica: A Kanban board is going to show the work in
progress. It's probably going to have WIP limits on top of the
columns, Work In Progress limits, so that you can see what's
coming up next and what's being probably delayed because it
cannot be worked on yet due to the WIP limits. You're likely going
to be able to notice bottlenecks on a Kanban board. There are
very simplistic Kanban boards. To do, doing, done. I don't see a
whole lot of that in my world in a DevOps implementation. We've
got maybe a "next" column. We've got maybe a "waiting for"

column where we're waiting on some dependencies, and maybe
some analysis is going on with some implementation. We can
visually see the steps of the workflow that is happening from
development through operations all the way until it's delivered.
Instead of just having one "done" column because "done" is hard
to define, we might have a "delivered" column on the board. Then
after that, have a column that will indicate features or functions
that are actually in use and have been maintained. We have all
the monitoring and everything set up for that functionality.
Another item that I like to see on my Kanban board anyway is an
abandoned work area. I just did an Ignite talk at the last DevOps
staged in Mountain View, California on this because I think it's an
essential thing for us to think about. The business understands
the direction that they're going, but they may change their mind.
They may pivot. They may want to stop working on a feature that
got so far through the pipeline.
Sometimes this can say...well, it used to for me. It would impact
morale because it was like, "Oh, we put all this effort into doing
this work, and now the business wants to consider it waste and it
goes in the waste bin."
But with an abandoned work area on the board, then we
anticipate that there may be those kinds of changes, that we do
expect some work to be abandoned and not make it all the way
to production, and that's the right thing to do and we need to let
go of that work and be OK with it.

Joe: When you talk about a Kanban board, does each team have
their own Kanban board then?
Dominica: That really depends. That's highly contextual in the
organization. It depends on the size of the organization. It
depends on how well these teams are integrated or not. The goal
is to have a Kanban board that you can walk up to and it makes

sense and people can understand what's going on. If there's too
much stuff going on in the Kanban board and it's too confusing,
it's not going to work right. It's whatever works. If one team
starts using Kanban, say a development team starts using
Kanban, then, it may spread virally, and we'll see others' teams
in the organization start putting up their own Kanban boards.
Then they start working together over time and it may be that
they'll evolve into one Kanban board so that both teams can see
each other’s work on the board. That can be very useful, but it
does require support from leadership to do that.
Joe: I think that's a big thing because all of these boards look
kind of messy to me. And you're saying another team should be
able to come up and decipher someone else's board?
Dominica: I think it's really helpful if they can. If different
teams have their own Kanban boards and they're using different
colors for post-it notes and different policies, it'll be harder. It'll
be more confusing for teams to read the other one's board. So it
can be helpful and help them keep it in better alignment if they
can agree upon some-- I don't want to standard, because there
really is no standard, but you could see how it could be helpful if,
for example, people would use bright pink post-it notes to
designate blocking tickets.

Then, as you're moving through the organization, people would
know "OK, that's a pink post-it note, so they must be blocked on
something. OK, let's see what they're blocked on."

Joe: I think that would be an excellent idea. It is a good thing to
develop some "standards" about a board.
Dominica: In the same organization, if the goal is to--down the
road we think that we might want to bring these teams into
better alignment or maybe even merge these teams together,


then the easier it is to understand each other's boards and that
the better it is.

Joe: What do you mean by workflow mapping?
Dominica: What I mean by workflow mapping is identifying the
steps basically that the work flows through. It's up to understand
how work comes into your organization and then how it exits or
how it gets handed off to the next team, and to clearly enter all
those states in there. When we first started using Kanban back in
2006, at Corbis, we were using it for sustainment
fixes--production fixes and sustainment fixes, small changes. We
had the analysis work and development work, and then it would
go into test.
I sort of raised my hand and went, "Well, hey. Wait a minute.
There's this whole area in there where we're getting the code,
and source code control, and we're doing builds, and we're
packaging it up, and deploying it to these environments. Where's
all that work happening? It's not magic."

I admit, there was a sense of, "Hey, what about me?" Not even
representing all the work I'm doing, or that our team is doing on
the board. We ended up putting a build ready queue on the
board, so that we could really see all the steps that the work
needed to get to in order to see value for the business.
Joe: In your speaking and in your work, you work a lot with
creating teams.

Dominica: Not necessarily creating teams, but uniting teams. I
would say, uniting the different teams so that work can flow
smoother between the teams. I believe that the integration points
and the handoffs are some of the biggest risks in software
development. When we have to hand things off to a different
team is where we have a lot of problems, a lot of accidents, a lot
of unknowns. The better those teams can be aligned, and sync

up, and understand the problems that the other team is facing. I
think the bigger the improvement that we have, and the faster
that we'll be able to deploy those improvements into production,
to see if that's what the customer wants or not.
Joe: How do you go about making that handoff? Do you have
two teams meeting together to make it? How do you go about
doing that?
Dominica: A couple of key things: One is standups, having
standups in front of the Kanban board, and ensuring that
somebody from the operations team is attending the
development team's standup in front of their Kanban board.
These standups are very short, and very brief. They're typically
centered on blocking issues. If I'm in an operations role, and I'm
attending a development Kanban standup, I can see what's
blocking them, and I can also get a good look ahead. I can see
what's coming up the pike, so I have fewer surprises. "Oh, I
didn't know you needed an environment by tomorrow."

Dominica: I can find that kind of stuff out earlier. Hopefully
have some kind of feedback mechanism in place too, so that the
teams can learn what's working, what's not working well, and we
would do this not only through standups, but through ops review.
Operations review is a monthly meeting where the goal is to,
basically, show the data. Each lead of a team will get up and, just
like in five minutes, present the demand that their team is
seeing, and their capability to meet that demand, and what their
issues are.
The good, the bad, and the embarrassing get revealed at these
ops reviews. I believe that brings about empathy between
different teams, and a greater understanding, and that helps
teams want to work together better to improve everybody's life.


Joe: I picture each team rolling in their Kanban board, their
monthly briefing.

Dominica: We hope, that it's off-site, so that people are focused
and paying attention, but they'll show their cumulative flow
diagrams, or their control charts. They'll show their issues. It's
more about looking at the actual data over the last 30 days.

Joe: We have daily standups, and the monthly review with
everybody, that's typically off-site. Do we have a weekly?

Dominica: Not necessarily.
Joe: We talk a lot about multiple teams working together. Is it a
combination of just team leaders communicating with each other?
You mentioned someone from the ops team was attending the
development teams. How do you get the multiple teams to work
together like that?
Dominica: I think one of the best scenarios is if you have one
board that incorporates all these teams, and everybody's at the
same standup every morning. To me, that's ideal. Organizations
don't always have the ability to do that. And they might say, "Oh,
our team's too big." But we had about 50 people attending our
standup. It was a huge implementation, like a 12 million dollar
implementation of SAP that impacted everybody from analysis, to
business, to ops, to development. Customers or product owners
would attend these standups, and then everybody gets to see
what the issues are.

Obviously, if you're not ready for that and your teams do have
separate Kanban boards and separate standups, hopefully the
standups are staggered so that people can attend one or the
other.
Another great thing I've seen is when somebody from one team is
actually embedded in another team for a period of time, maybe


30 days, or 60 day. You might have a team member embedded in
that team and their working right alongside them.

Joe: That was really one of my questions here, what happens
when someone has to be on multiple teams. Is he going to
multiple meetings?
Dominica: Oh, that's a great question. Hopefully, you can
design your Kanban system to show demand coming in on maybe
one shared services team and how it's impacting them and how
and how are they supposed to prioritize across five or six
projects. I think that's where the visibility can be so critical to
bring about understanding because people can only do so many
things at once.
And if a shared services team, there's a real risk there. If you've
got four or five projects going on, and everybody needs support
from the security guy, or from the sysadmin guy. How do they go
about prioritizing?

It's very challenging. If we can visualize that on a board and
bring customers to see that--when I say customers I'm not
necessarily talking about external customers to the company, but
downstream and upstream customers, business people, or
developers, or product owners.
If they can come look at a board and see the demand that's
coming into their shared services team, then they can begin to
help prioritize, so that the shared services team, or a person in a
shared service role, it'd be easier for them to select the next work
item to work on, or the next task to work on.
When you visualize a board like that, it could be that they decide
to hire more people. It could be that they decide to actually bring
some of those specialized skill sets into the team. In other words,
they might embed a specialized skill set into their team for a
while.

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.
Joe: Talk about the goalie that stops people from interfering
with the team and everything. How much authority does a goalie
have? Can he stop a leader from coming in on the team?
Dominica: The goalie is really about running interface to protect
the rest of the team from getting interrupted. Like most things,
we really need leadership support in all of this. If the VP comes in
and interrupts somebody, maybe they need to be reminded
about, "Hey, we have this policy. We have a goalie, and please go
work with the goalie, so we don't get interrupted." We'll probably
always have emergencies. That's just the nature of our work in


operations. We will handle the emergencies. And that's why it's
important to design a Kanban system that's going to handle
emergencies, so that we have the capability to do that.
But the thing I love about the goalie is, one, it helps provide
cross-training for the team. If you have one person that's always
handling that one feature, or that one functionality, or that one
tool, it brings in a lot of risk. When they win the lottery, it's not
when they get hit by the bus, it's when they win the lottery, and
they call in rich, who else is going to take it? The goalie helps to
cross-train teams, reduces that risk.
It's a rotating position. It might rotate on a weekly basis, or
maybe a 10 day basis, or whatever. So everybody gets to
understand the problems that people are having on a day-to-day
basis. It's a way to train people. It's also a way to help document
or automate some of those daily requests that come in.
Joe: Is there something about Kanban or DevOps you'd like to
add that maybe I didn't ask?

Dominica: One of the biggest challenges with Kanban is that,
because it's not very prescriptive, and people will ask...Some
people will want to be told what to do. And that can be really
challenging, because that's not really easy. What we like to do is,
we're trying to improve collaboratively by doing these safety fail
experiments. "We're going to try this, see how it works, adjust it
slightly, and try it again." It's through that gradual evolution over
time where we can, hopefully, get to where we want to go. That's
one of, probably, the bigger challenges that I see. Also, people
will try to copy other people's Kanban boards, and that's a big
problem. Trying to do what everybody else is doing just rarely
works. Your situation is likely to be different, and sometimes it
can just be dangerous to copy somebody else's Kanban design.


Joe: You also have a couple of community groups online that
you work with in the DevOps field. Could you name them, and
mention how someone could contact you?
Dominica: Sure. There is Kanban Ops. It's a Yahoo! Group. You
just google "Kanban Ops." It's a private group, which is nice,
because we don't have a lot of vendors posting outside, trying to
sell anything. Kanban Ops is a group of practitioners who can ask
questions, like Kanban Dev. There's a Kanban Dev Yahoo! Group
too, where people can just ask questions to the community and
get responses. The Kanban Ops group is much smaller. It's really
just getting going, but it's more about case studies for the
community out there who's using Kanban for ops, and I facilitate
that group. So if somebody just went to Kanban Ops and
subscribed to that, then I would approve that.
We have the Limited WIP Society, which is a nonprofit
international society. There are local Limited WIP Societies all
over the world, Australia, London, Europe, U.S., everywhere, and
they have meetups. It's a great resource to go to, for example,
get a list of the three dozen online electronic Kanban tools out
there on the market now, things like that. Then there are videos
out there from all the latest speakers at the Lean Kanban
conferences.
One last thing I wanted to mention, Joe, was another important
thing to know about Kanban, typically, especially in the office
arena, we are used to having work pushed on us, right? "Do this,
do that," without people really understanding the front up-time
that we might need.

That continual pressure and force are just not sustainable. Even
no relationship can respond positively to that continued force.
That's why it's so key to set those work in progress limits and to
adhere to them.



Joseph T. Dager
Business901
Phone: 260-918-0438
Skype: Biz901
Fax: 260-818-2022
Email: jtdager@business901.com
Website: http://www.business901.com
Twitter: @business901

Joe Dager is president of Business901, a firm specializing in
bringing the continuous improvement process to the sales and
marketing arena. He takes his process thinking of over thirty
years in marketing within a wide variety of industries and applies
it through Lean Marketing and Lean Service Design.

Visit the Lean Marketing Lab: Being part of this community will
allow you to interact with like-minded individuals and
organizations, purchase related tools, use some free ones and
receive feedback from your peers.

Marketing with Lean Book Series included in membership
Lean Sales and Marketing Workshop
Lean Service Design Workshop


DevOps and Kanban

More Related Content

Similar to DevOps and Kanban (20)

More from Business901 (20)

Recently uploaded (20)

DevOps and Kanban