>> Doug Thompson: Hello, thank you all for coming. My name is Doug Thompson and I’m a Program
Manager on the Xbox Platform Team here at Microsoft. I’m honored to introduce my Manager Eric
Brechner to the Microsoft Research Visiting Speaker Series.
Eric’s here to talk about his new book Agile Project Management with Kanban. Now Eric is not one to
brag so I will do it for him. Amazon has this as the number one rated hot new release in software design
and engineering, kind of a big deal.
[applause]
Several years ago Eric assembled a team for the Engineering Services in Xbox. I was a proud member of
that team. I was lucky to be on it. At the time, we were always in TFS which is the Microsoft Internal
Bug and Work Item Tracking System to manage our work in deliverables.
Eric made a declaration once the team had kind of got into a groove and established their roles. He said
you guys need to use Kanban. We must use Kanban to be better because he’d found that it was such a
success in his previous teams.
It was a good thing we did that because agile’s, the Kangan’s agile methodology would provide an
awesome framework for us. We welcomed the change and found the migration from the Waterfall like
world that we had been in to Kanban to be natural and straightforward. We could really visualize our
work on a day to day basis and see the emerging patterns easily.
Our team broke free from the TFS and Kanban, sorry, and Waterfall world and landed in an
environment. That allowed us to work efficiently and consistently to produce high quality deliverables.
All of that is great. But the thing I’ve appreciated the most about Kanban and what you’re going to learn
about today is its versatility and ability to mold around the team.
Eric has a few Kanban boards in the team’s hallway. You just walk down it. Each board runs differently,
is managed differently. But they all have the same results. It adapts to the various personalities since
the whole point is to visualize your work. Some people want to get very granular with how they manage
their stickies as Eric is going to show you. Some people like to manage them at a high level.
But it doesn’t matter as long as everything is being tracked and followed accordingly. That’s the beauty
of Kanban. Each team member contributes to the Kanban. There’s a whole sense of camaraderie and
culture around it. There’s a day to day conversation and openness that we have. There isn’t a central
Kanban boss. But there is a team mentality.
After using Kanban fruit for years now. The thing that I can tell you that I appreciate the most is that our
team not only delivers features at high quality. But I appreciate the shift in culture that Kanban has
fostered. Kanban is awesome. With that it is a privilege and honor to welcome Eric Brechner up here to
tell you all about it.
[applause]
>> Eric Brechner: Thank you Doug. I’ll pay you the 20 bucks later.
[laughter]
>> Doug Thompson: Thank you.
>> Eric Brechner: No that was awesome. Thank you so much. Thank you all for coming out and letting
me talk to you for a little while about this. Most talks of course have slide decks and things like that, or
just a chair and someone talks. I’m going to do this a little differently. I’m going to actually create for
you on the board a Kanban board. I’m going to use it for this talk, okay.
I’ll just take you right through it. Now, some things you should know about me in advance that Doug
didn’t cover. But I’ll cover them very quickly. I’m a little, so I’ve been a Developer since I was a
Professional Developer. I paid for it since I was fifteen year old. I worked at many different companies
including soon will be my twentieth anniversary here at Microsoft.
All this kind of adds up to my receding hairline. But what I’ve had in common all those years is I’m a
little, as my wife can attest, a little OCD about how I do things. I just, I really like being super efficient
about everything that I do. I’m constantly trying new ways and new things just to do a little better.
Over the years just about any methodology you could imagine in software development I’ve given a try.
The reason why I wrote this book on Kanban is because I have finally found my own little slice of
Nirvana. It’s amazing. Doug talked about it. I’m not going to belabor that point.
But it’s so simple. The book is really thin. That’s because it really doesn’t require much to describe it. I
do cover everything you’d ever need to know in this book. I hope you pick up a copy. I’ll cover some of
that today and answer your questions. But it’s a remarkable thing.
Without further ado let’s create a Kanban board. Kanban board is very simple. The only thing you need
in order to actually use Kanban, there’s no separate planning meetings, no separate retrospectives, or
anything. It’s just the board. Yet it works as a project management tool for just about any workflow
that you happen to have.
With that let’s get started. The first part of the Kanban board is the backlog. This is the collection of
stuff you need to do. You don’t want it all sitting in your head or something like that. You need to write
it down. You write it down on a sticky which we’ll be doing. You put it in the backlog, simple as that.
After the backlog you have your steps. The steps today that I’m going to be doing is I’m going to be
answering your questions. What are the steps to answer your question? Right, well first step and this
won’t come up much but it can come up. I want to make sure that I capture it. Is that you may need to
break down that question. Sometimes people ask really big questions and they’re actually made up of
lots of small questions.
First thing I’m going to do is break down the questions. I’ll have a break down. I’m not going to be using
it much but it’s important to have it there. This comes up a lot more in software development. Often
you have a feature that comes in and it’s big. It has lots of different pieces to it. You really do need to
break it down before you actually work on each piece. You break it down into tasks. Sometimes the
features are very small and they don’t get broken down at all. But a lot of time you do, so it’s important
to have that step.
The next step is, after break down, the question. I’m going to answer it, fair enough. Then after I
answer it I’m going to want to validate, make sure I answer the person’s question. I’m going to want to
double check because I’m trying to be a good speaker here today. That’s it. That’s my Kanban board. It
has just a couple more elements to it. I’ll go over those elements. I’ll start taking your questions. This
really is this simple.
Okay, so a couple of other elements. Each step has a, I’m working on it and I’m done with it. There’s
two columns to each step. That’s important and you’ll see why as we kind of go through it. But that’s a
very important element of Kanban.
Many people do use boards when they’re doing just about anything. When they’re keeping track of
work at home, maybe the kids homework or something like that. When they’re, obviously when they’re
doing software development, or working on a project, people often have a board that tracks the work.
They have a big done column at the end, okay.
One of the things that’s different about Kanban is that it’s done columns for each step. That is an
important distinction. Okay, now why have the done columns for each step? There’s some really
complicated stuff we can get into if you’re curious. But one of the things that the done columns do is it
enforces you to think about whether or not you’re actually finished with each step. You don’t get to just
move the things over. You actually have to obey some kind of rules. There’s done rules, okay, so there’s
done rules for each step, right.
Now, just as an example we’ve got my break down step. For my break down step if I’m going to break
down the questions how do I know that I’ve broken it down sufficiently? Well, I’m going to say for
argument sake. That when I break it down each of the individual questions I break it down to takes less
than two minutes to answer, right. That would be a nice small question.
In real life, you know our teams it’s typically when you break down a feature you break it down to the
task that are no more than like one to three days each. Right, that way you know you’ve kind of gotten
it down to a workable chunk. But here less than two minutes to answer. That will be my done rule.
Then I know that I’m done with it, right. For the answer, for me to be done with my answer I’ll want to,
this is being recorded I’ll want to repeat the question and then answer it. Okay, so I’m done if I’ve
repeated the question and I’ve answered the question.
But of course I may not have done a great job of that so we’ll want to validate it. I won’t be done with
validate until I’ve asked the questioner and they have said yes, that does in fact answer my question.
Okay, so there are my done rules. I’ve got a done rule for each one.
Now, in software development the done rules may be more like for break down tasks are no more than
one to two days. For implement which would be the natural thing for answer. For implement it would
the usual things you have implementation. It’s been code reviewed. It’s been unit tested. It builds. It
passes the basic check in tests, right. Those would be the done rules for implement.
Then for validate it might be we’ve pushed it out into production within a small ring. It’s validated,
nothing came up. It went maybe into a second ring. Now we think we’re good to go. It’s done, okay.
It just depends on what you’re doing. You can see the flexibility that Doug referred to. These done rules
they can be specified by your team. The steps you can make them whatever steps make sense for what
you’re doing. If this is a list that you have at home, a lot of people use Kanban at home believe it or not.
Those done rules can be you know like your list of honey dos. The done rule is I checked with honey and
she said it was good, right.
[laughter]
Whatever works for you, you can set those rules however you like. But the important thing is that there
is a sense of done. This ensures that you have quality at every step which is something that many other
methods don’t ensure. But it helps a lot in delivering value continuously to your customers, okay, which
is a key thing about Kanban.
Alright, now before I get to the very last element. There’s only one other element and then we’re done.
I want this talk to last more than just you know ten minutes or so. Before I get to that last element any
questions? Yes.
>>: I wanted to point out that another reason for having a done column is without it you kind of have a
push model, whereas with it it’s pull model which is really, really helpful.
>> Eric Brechner: Okay, so talk a little bit about pull. I realize it was more of a comment but, other
questions. Yes.
>>: Schedules, so you talked about backlog. But you didn’t talk about schedule yet in how that…
>> Eric Brechner: Okay, schedule and probably estimation to go with that.
>>: Guest cost.
>> Eric Brechner: Alright, schedule and estimation. Look they’re going on my backlog, right. That’s just
what you would expect. Yes.
>>: What about how teams transition from Scrum Outlook?
>> Eric Brechner: Ah, transition from Scrum.
>>: Can you add Scrummerfall to that as well?
[laughter]
>> Eric Brechner: Sure, and instead of saying transition I’ve been told by people who have Scrum in
everything. That this is very similar and it’s not a transition so I’m going to go evolve.
[laughter]
Okay, so evolve from Scrum. Yes.
>>: Fiscal versus digital combo?
>> Eric Brechner: Ah, online boards. Yes.
>>: If you have dependencies that are date driven how do you manage that?
>> Eric Brechner: Date driven. Also it was a loaded question because there were dependencies in there.
>>: Ah, you’re breaking down before you’ve left your back…
[laughter]
>> Eric Brechner: To repeat that so people can hear it. I was breaking down the questions early. I
should have left it for that step.
[laughter]
But Kanban’s really flexible, yeah.
[laughter]
>>: What was the hardest part about driving a change from a cultural perspective for your team?
>> Eric Brechner: Ah, cultural change. Yeah, way too many, yes.
>>: How am I going to put some of this into TFS?
>> Eric Brechner: Ah, TFS, that’s the Team Foundation Server service, thing that tracks all of our work as
a large group. Yes.
>>: How about Kanban specific project metrics?
>> Eric Brechner: Project metrics. Yes.
>>: Could you talk a bit about for branching models and publishing factor into this?
>> Eric Brechner: Branching and publishing. Yes.
>>: Using Kanban across a team that’s in different geographies?
>> Eric Brechner: Oh, okay.
>>: Time zones?
>> Eric Brechner: I’m going to put that with the online boards because those two are related. Yes.
>>: Could you repeat the question, please.
>> Eric Brechner: Oh, and I will repeat the questions you know as I answer them coming up. That one
was about how do you deal with teams spread across geographies? Yes.
>>: How do you, what’s the benefit of breaking away from Timeboxing?
>> Eric Brechner: Benefit versus Timeboxing. I hope I get to that one that’s a good one. Yes, in the
back.
>>: [indiscernible] one is scale and the next one is management acceptance.
>> Eric Brechner: Scale.
>>: That’s whole management change.
>> Eric Brechner: Scale of the methodology or just…
>>: Yeah, scaling to you know I work in a team with a bunch of teams which is within OSG.
>> Eric Brechner: Scale to OSG.
>>: Yes, exactly.
>> Eric Brechner: I’m within OSG too, definitely can do it. Yes.
>>: How do you integrate threat modeling with this?
>> Eric Brechner: Threat modeling. I’m going to need a bigger pad. Yes.
>>: Can something go backwards in the process?
>> Eric Brechner: Backwards.
>>: When done with everything?
>>: Validate the answer.
>> Eric Brechner: Yeah.
>>: The [indiscernible] or perfect team size that this model can work with? Whether this applies to a
one dev kind of team?
>> Eric Brechner: Sure, team size. Yes.
>>: Can you speak to like the advantage or agility that you might gain from this versus a pure Waterfall
model?
>> Eric Brechner: Agility versus Waterfall. Yes, Amy.
>> Amy Draves: Online they have a question, sense of ownership of board tasks doneness?
>> Eric Brechner: Ownership tasks and doneness associate with that. Yes.
>>: How do you measure capacity and priority? Or how do you prioritize things come in?
>> Eric Brechner: Okay, those are two different things. It’s not a break down gosh darn it. Those are
two different questions.
[laughter]
Priority, yes.
>>: How do you treat separate expertise on the dev team. For example one dev implementing one
feature…
>> Eric Brechner: Ah, expertise. Yes.
>>: Tasks versus bugs in prioritization.
>> Eric Brechner: Ah, bugs. I’ll talk about prioritization with that too. Any others? Yes.
>>: Estimation techniques, [indiscernible]…
>> Eric Brechner: Okay, I’ve got that one on there, so we’re good. Yes.
>>: How do you measure whether it’s working fine or not with this? Whether Kanban works fine or
not?
>> Eric Brechner: Measures of success. Okay, any other for now? By the way we can add more at any
time of course. Yes.
>>: Pipelines and orchestration of parallel work items?
>> Eric Brechner: Oh, okay, so I’m going to call that swim lanes if you don’t mind.
>>: Yes.
>> Eric Brechner: Okay, yes.
>>: My team tried this but they were kind of bored with the processes involved. Any tips on how to not
burden the team with the processes but still have them do the tasks?
>> Eric Brechner: Okay, so not…
>>: If I could add to that a little bit. How would you prevent the board from becoming too flexible?
>> Eric Brechner: Okay, so not burdening with process and too flexible. Yes.
>>: Alright, when we should use Kanban and when we should not?
>> Eric Brechner: Okay, short answer the second one.
[laughter]
Okay, no, so the question was when not to use Kanban or when to use it? I’ll just say when to use. Yes.
>> Amy Draves: There’s a bunch of questions online. But this one is sort of longevity question if it’s
outside of the two to three weeks sprint, how do you use it? Use it similar to MS Project?
>> Eric Brechner: Oh, okay, so if it’s beyond the length of the sprint. Okay, let me get to answering
some of these. Then we’ll keep moving on. I’m worried that it’s so many that we’re not going to get to
talk much.
Okay, nonetheless I will still take more and put them on the board. I can also promise you that every
question that people have asked, even the cultural change one is actually answered in the book. It may
not be you know particularly to your liking or something that you want more. But of course I am still
around you can ask me. I’m in the gallum in the, whatever that’s called in Outlook, the address book.
Okay, so I was going to get to what is the last element here. There’s a reason why I left it off. It’s
because the thing that’s a little bit complicated for folks to understand. But it’s what makes this project
management. Everything up to here is visualization of work, okay. There are some done rules. That’s a
little bit of project management. But mostly it’s visualization of work.
There are lots of people as I mentioned before who will put stickies on for all their work. Move them
along a board and all that. But they still need some other former project management, ways of tracking
their work, and making sure things don’t go badly. Whether it’s Scrum or Waterfall, or some other
interesting method, they need something.
In Kanban you don’t need any of those things. But you do need one more element. That is what are
called WIP limits. Now WIP just stands for Work In Progress. That is work that you started but you
haven’t finished, okay. WIP comes up so much that you know they have an acronym for it. Work In
Progress, what you want to do to make this project management is to control the work that’s in
progress. That’s what makes it project management, okay.
What are these WIP limits? All these WIP limits are are a maximum number of stickies that are allowed
in any step. Okay, that’s all they are. Now, how you set them is what’s interesting. Typically the way
that you set them is you start with the step that’s going to take the longest, okay. In this case clearly
that’s answer, right. You set that value to be something that’s going to allow you to work smoothly.
You know have enough flexibility but not anymore than that because you want to limit the work in
progress.
The reason you want to limit the work in progress is that that’s what gives you all of your agility. If you
don’t have much work in progress at any given time it’s very easy to switch and do something new. You
have that agility. It’s very easy for you to produce stuff and get it out the door quickly because you
don’t have much ever that you’re working on at any one given time. It’s all getting right through the
system, okay. You want to keep it low. But high enough that you can get stuff done.
In the example here I’m going to be answering questions. Sometimes there’s two related questions or
something like that. I’m going to want a little bit of flexibility here. I’m going to go ahead and make my
little WIP limit, I’ll make it three just to be safe. It’s just me, someone who knows how to do this is
complaining. But it’s just me; I’m going to make it three. I could probably knock it down to two. I don’t
think I’d want to go below two. There will be times when I need to do more than one question at a
time.
Alright, once you have your WIP limits. No more than three questions at a time an answer. Once you
have that one you’ll want your other steps to match their pace to the middle step. There’s all kinds of
queuing theory about exactly why this needs to happen. But basically you’re fastest possible
throughput is going to be when all, when the speed of stuff moving through the board is fairly constant.
If this goes too fast, if you pile up too much work here it’s just going to pile up, right. Then you’re going
to have all this extra work in progress. Then when you change course or something like that you’re
going to have to throw this away and that’s terrible, right. You don’t want this piling up here. You also
don’t want stuff piling up over here without it being validated. You want the validate to move it right
through, okay.
You set the WIP limits for the other steps to match the pace of the middle step. Now that may seem
slightly complicated. No worries, there’s an online spreadsheet that comes when you get my book.
[laughter]
There’s an online spreadsheet you can grab. It has all the formulas worked out for you. You just enter
in some basic information. It sets your WIP limits for you. In this particular case I’m going to make this
one and this one because both of those are really quick. They don’t need to be any bigger than that.
Like I said for break down most of this stuff is going to fly right through.
Okay, we’ve got our WIP limits. Now, key point about the WIP limits is that they limit everything in that
step both the stuff that I’m working on and the stuff that I’m done. I can’t keep just piling on, okay.
Even though there’s, it says one here it can be sitting here or sitting here. There’s never more than one
in the entire step whether it’s done or not. That turns out to be extremely important in getting the flow
right. If you’re allowed to add more and just build up your done column, bad things happen.
The other thing is that I’ve made a little mistake. This final done column here it’s as big as you want it to
be. You’re just finished with stuff entirely. That last WIP limit really just applies to the working on it.
The final done column that’s basically infinite.
That’s it. That’s our entire board. Bill?
>>: Isn’t there kind of a similar problem with your break down column? Because breaking down any
question into another couple of questions is going to be bigger than one.
>> Eric Brechner: Okay, so the question and I’m going to answer it right away. You can do that in
Kanban. You get mail, you get little bugs, you get little things that are very quick to just do right away.
You can do that. There are no Kanban police. There’s no Kanban army. There are no Kanban zealots
hopefully, okay.
[laughter]
No one’s going to beat you up for just making this work for your team. I’ll just answer that one right
away. For the break down step the one refers to the questions coming in. When they get broken down
and they get broken down say into three other questions. Those are kind of clustered together as one.
But then as I answer them they become individual. The flow remains the same and smooth.
Okay, so let’s start getting going. We’ll start with priority. Someone asked how do you prioritize? Okay,
it’s a very straightforward thing in Kanban. We’ve got a backlog. We’re going to order it. Now, I can
spend a lot of time ordering all these different stickies, carefully putting them in some clever order.
Then later on things change. You know in a few minutes people start complaining or asking about
something else, or something like that. That would be kind of a waste of time.
What I’m going to do is I’m going to kind of clump. I’m going to clump. The thing that’s most important
is just what am I going to do next, okay? I’m in the middle of answering priority. Let’s see we’ll do
capacities related to that. Project metrics I’m going to move down a bit. Team size, geographies online,
dependency is super important. Evolving from Scrum I want to cover that. Measures of success,
expertise put that with dependencies, bugs and I’ll put that with Scrum somewhere. I forget where it
went, there, close enough.
Alright, close enough. Good enough for me to work with. You think this is a little funny, right. I mean
didn’t I just arbitrarily do that? In an actual team what we do is we have a daily standup. If you’re
familiar with Scrum a lot of you have probably used that in Scrum. It’s the daily Scrum. When I was
doing Waterfall years ago we still had a daily standup. We still met and talked about you know that day.
What we’re going to work on, all that sort of thing.
A lot of people are used to doing this. That’s what we do every day. Every day we get in front of the
board. We talk about the backlog. We talk about priorities. We talk about any blocking issues.
Anything people need to discuss. What we don’t have to talk about unlike Scrum is that we don’t have
to talk about what we did or what we’re going to do next. Because that information’s right on the board
and you can move the stickies any time of day, whenever you like, okay, because they’re stickies you
just move them.
[laughter]
No big deal. You just mostly focus on what are the issues of the day? One of the things that you’re
going to talk about of course is okay; do we have the right priorities? Are there any new things that I
need to add? Any new questions come up in my particular case, right that sort of thing?
Even though I was pretty rough here in just sorting just a little bit to get the priorities right for the order
in which I’m going to answer these questions. I can change that any time. You’ll notice I will. That’s
because this serves me. I don’t serve it, okay, likewise for your teams. For the priority we just put
everything in priority order.
Obviously, your customers, your stakeholders are going to have something to say about that whenever
they do have stakeholders on our teams. They are pretty insistent their stuff is the most important
things in the world. No problem. We take them in front of the board or we describe it to them. We say
hey, where does yours fit in? They can look at the board.
They can say you know what the kernel fix is more important than what I’m doing. But I think it’s more
important than this. Can I put it here and we’ll say sure that sounds good. Or we’ll say actually this is
this. They’re like and we have a discussion. It’s not terribly complicated. It’s very visual.
Did I answer the question? Who had priority?
>>: I did, so also the difference between Scrum versus Kanban is that in Scrum you lock down the
priority, right. In Kanban it seems like it just comes in fluid, right?
>> Eric Brechner: Yes, so what the questioner who put this up commented on. Was that in Scrum the
priority is kind of fixed. It doesn’t have to be. I’ve run Scrum teams where we’re pretty fluid about that
too. But definitely in Kanban it’s very fluid. That’s because in Scrum for those of you who are unfamiliar
with it. It’s a particular project management methodology. They Timebox what’s called a sprint. You
plan out everything you’re going to do in a sprint, the sprints last one week to four weeks.
You planned out everything you’re going to do. Then you do it. You don’t mess with it. Then you get to
plan again at the end of that Timebox, at the end of that month or week. In Kanban you continuously
delivering just like I did. Every day you’ve got new stuff that you’re finishing. There is no Timeboxing at
all. In that case we have a lot more flexibility which is very nice.
Did that answer your question?
>>: Yes.
[laughter]
>> Eric Brechner: Awesome we’re done with our first thing. Now you notice a bug came up during
validate, right. No, now you probably wouldn’t think of it as a bug. It was a follow on question, right.
But in a certain sense if this is like work and I’m working on features or tasks, or something like that. I
got to validate but there was something that I didn’t do quite right.
>>: Break down.
>> Eric Brechner: I just took care of it. Right, took care of it and moved on. If it had been a big thing, if
you had a really big follow on question I could have written up a new question, new sticky, put it into
the backlog, and prioritize it. That’s basically how it works.
Let’s see. Let’s talk about dependencies, going over capacity here. Okay, let’s talk about dependencies.
You know what expertise comes right into this. I’m going to put that right here. Yes.
>>: I just had a follow up question on that thing. If that had been a bug and you would put that in the
backlog. Would you still move priority to the done column?
>> Eric Brechner: Yes, I would. Okay, that was like an email. I can answer right away. I don’t have to
put it on the board, quick answer. But big things you want on the board. We’ll get to that in a moment.
Let’s talk about dependencies. Dependencies are really rough on all of us. This is when you have work
items and they depend, you know tasks, stickies. That depends on other things, right. Those other
things aren’t ready. One of the ways they may not be ready is because you have some expertise on your
team. There’s one particular person who could do that task. They’re busy doing something else so they
can’t work on it right away, right.
Both of those cases they’re similar. In that you have a work item. You have a sticky that get’s blocked.
What do you do? What we do and Doug’s team actually came up with this idea. Thank you Doug, is we
add a new marker, we add a new column right in the middle called track, right. Let’s say my
dependencies question has a dependency I can’t answer it.
[laughter]
I put it in the track column, okay. Now what the track column does. First things first, the track column
does not count anymore toward my WIP. It’s off the board in some sense. But we’re keeping track of it
because we can’t work on it right now. We have to wait for that dependency to free up. Or in the case
of the expertise we have to wait for that person to become available, right.
It sits here in the track column and its right there on the board. At our daily standup one of the things
we do is we talk about the items in the track column. How are they doing? Is it ready yet? Is it going to
be ready soon? Is it next week? When is it? Oh, it’s ready now, fantastic, okay. It’s unblocked,
wonderful. When it’s unblocked it goes back, now we can work on it.
Now if we were at our WIP limit. If we already had in this case three stickies filling up these areas then it
obviously couldn’t move right away. But as soon as that got freed up it would be at the top of the list.
The reason why it’s at the top of the list is that it’s already higher priority. That’s how it got into the
board in the first place. It’s the top priority we just couldn’t’ work on it right away. We just put it right
at the top. Instead of pulling from the left we just put it right there. Yes.
>>: How does this work with bigger, fatter, inter-teamed dependencies?
>> Eric Brechner: Bigger, fatter, intertwined dependencies.
>>: Inter-teams, so I’ve got some other team and it’s going to take them quite awhile to do this thing.
That I’d like to be working on…
>> Eric Brechner: Right, right, yeah.
>>: Right.
>> Eric Brechner: This is exactly what I’m talking about. In that case this guy would sit right there in
track until that team was ready and it delivered it. Now if it was a big deal. It was going to be six
months or something like that. That’s what project planning is about. That’s when you’re really thinking
about how you’re ordering your backlog. All the usual coordination that you would do regardless of
what project management technique you were using.
You would have some conversation about how we would time it, right. But if it’s yeah the priority is
right. It moves through the board but they’re not ready yet. Then we put it in the track and we track it
every day. If we say oh, it’s going to be next week we’ll leave it there and not talk about it as much. But
the next week we’d talk about it. Yes.
>>: The stickies you said represent work that is scoped to about one to three days, correct?
>> Eric Brechner: Yes.
>>: Which we think of as tasks.
>> Eric Brechner: Yes.
>>: But what I’m losing here is tasks that in and of themselves don’t deliver value.
>> Eric Brechner: That don’t…
>>: The task in and of itself does not deliver value. But…
>> Eric Brechner: Okay, so…
>>: The accumulation of several tasks is what…
>> Eric Brechner: Right, so the question here is each of these tasks they could be fairly short. By
themselves they don’t deliver value. We could move them all the way through the board. They could
be done but the actual value is in the collection of tasks together. Much like how it originally broke
down, right?
Absolutely, that happens all the time. We just, you know in Xbox we typically use a switch of some kind.
That prevents that collection of work from actually showing up to a customer until all the different
pieces are done. One of the last tasks is going to be switching it on.
>>: Okay.
>> Eric Brechner: Did I answer the question about dependencies? No objection. We’re moving on.
With expertise, with expertise there’s a few different ways you can handle expertise, right. One is you
block on it, right. It’s treated just like a dependency.
Another way that I prefer actually is that if you have people who are specialists in one thing or another
and they’re busy. I hate it when I’m in a situation where one of the members of my staff could be on
vacation or sick on any given day and it gums up all the works. That’s really just not a good way to run
your team.
What I typically do instead is if we have that flexibility. If there’s someone available I’m going to give
that work to someone who’s not as familiar with it. I’ll use the person who has expertise as their
backup, mentor, code reviewer, all that sort of thing, right. Then that’s going to mitigate my risk.
Now, I’m not going to do that for everything. There’s some tasks that really, really, they’re big things.
They really do belong to one person. That makes total sense. They should own it. But you know for
some items you really don’t want to put yourself in a situation in which you know you’re just going to be
stuck. That would be my recommendation.
Did I answer the question about expertise?
>>: Yes, you did.
>> Eric Brechner: Good, alright, evolving from Scrum. Scrum, for those of you not familiar I mentioned a
little earlier Scrum has these ideas of Timeboxes. There was a Timeboxing question here as well. I’ll just
move it through when I’m done. Scrum has this idea of one to four weeks. You just focus on a set of
work that you plan in advance. At the end of it you ship it.
Using Kanban, going from Scrum to Kanban is actually pretty simple. You probably already have a board.
You’re already working on things and moving them all the way through. You already have a definition of
done. You’ve got a lot of the, you got a daily standup, right. You’ve got a lot of the elements of Kanban
already. It’s really not that much of a stretch.
All you do is put your steps up on the board if you don’t have them already. Add a done column to each
step, put in some WIP limits. Again, using my cutesy little spreadsheet that’ll tell you exactly what they
should be. Then just track your work on the board.
You can still have your sprint planning meetings if you like. You can still have your sprints if you like.
You can still do your retrospectives at the end. Those of you who know about Scrum know what I’m
talking about. You can do all those things. It’s all good. It works pretty much the same.
This is what I did when I first started using Kanban. I took two of my Scrum teams. They switched over
to using Kanban. They worked exactly the same as they did before for awhile. After awhile they got
really good at Kanban. They got comfortable with it. It made sense. They’d adjusted their WIP limits a
little bit to match the individuals on their team.
You know just move up and down just a little bit, fine tune it. After awhile they realized that they didn’t
need the planning meetings anymore because it was continuous. They realized they didn’t need the
sprints anymore because there wasn’t a beginning and an end. They just keep moving stuff through.
They realized they didn’t need the retrospectives anymore. Because their retrospectives were all about
when things got blocked and messed up. All that was happening right in front of them day to day, they
could see it on the Kanban board. Because one of the things that the WIP limits do is that they enable
you to see any time work is blocked.
If the validate step is taking too long and just sitting there eventually all these answers are going to be in
the done place. They’ll be stuck because the validates taking a long time, right. You don’t need a
retrospective to notice something’s wrong. You’ll notice it right then. You don’t have to wait until the
end of the month.
This is true for just about everything that goes wrong on a team except for major things. Like hey, are
we going to have a brand new change in direction? Or hey, there’s a personality problem between
these two people and we really need to talk about it, or whatever else. But the regular things that we
use to talk about are retrospectives. They come up all the time, same day, every minute of the day,
right there on the board. We didn’t need to do those.
Eventually, it just became Kanban. But the initial transition looked just like Scrum. We kept our Scrum
master. We kept everything. Yes.
>>: Usually how much time do you spend every day as a team managing this board?
>> Eric Brechner: The question is, how long do the standups last? They can vary. They can be as short
as five minutes. They can be as long as a half an hour. It depends on really what the team wants to talk
about. But actually managing the board takes very little time. That just takes a few minutes.
>>: But while doing that priotorizing as like an adding of the new features or anything. I must like to use
sometime, right, like some [indiscernible].
>> Eric Brechner: About adding features and all that. Doesn’t that take up some time? Yeah, yeah it
takes five or ten minutes.
>>: Every business day you keep adding or removing some of the features are doing the repriotorizing?
>> Eric Brechner: With all the adding, the moving of the stickies, all that sort of thing, doesn’t that take
time? That can be done any time of day, all the movement around and the juggling of the stickies. That
can be done any time of day.
Now, you put your own life at risk if you start changing the priorities all by yourself without consulting
with your friends. But that can be done at any time. It really doesn’t take. The standup doesn’t need
much time at all. Standups, now for my teams, well we range three to ten people-ish, right. For that
number of people doesn’t take very long.
But Kanban has been run with its teams as large as seventy-five. It still takes less than fifteen minutes.
Because again, not everyone’s talking about what they did or what they’re doing next. You only talk
about blocking issues. Those blocking issues are really evident on the board. Do you have a question?
>>: I was hoping you could talk about deployments. If you have an ops team doing deployments if you
don’t have, you’ve not setup to do continuous deployment...
>> Eric Brechner: Right.
>>: Production you kind of have to…
>> Eric Brechner: I’ve got it on the board. I got it. This is about publishing and stuff like that.
>>: Right.
>> Eric Brechner: And deployment, I’ve got that one. Yes.
>>: This is regarding Scrum, traditionally it’s like a spread planning session where the items are
decomposed, the team talks about what they are, design review session, whatever. Are those meetings
still held? Or when are those sprint plannings take place?
>> Eric Brechner: The question again going back to Scrum which we’re in the middle of answering. I’ll
take care of it immediately. Was about when do you do all the stuff that you typically do during sprint
planning? Like breaking down features into tasks and planning out who’s going to do what, and all that
sort of thing.
The breaking down into tasks that’s the break down step, so that’ll just happen continuously every day,
doesn’t have to happen in some special planning session. The assignment also happens continuously
every day. Who’s ever available takes the next sticky. If they can’t take it because they’re not prepared
to take it, something like that, then we have that expertise issue that we were talking about earlier. Yes.
>>: During standup session I’m taking notes and sending them to the team. Or Kanban board the only
artifact which is...
>> Eric Brechner: The question was during the standup are you taking notes and sending them to the
team? Or is the board the only artifact? The board is pretty much the only artifact. The only time we’re
sending notes beyond the team is when we finish something big. We want to show off, which happens
a lot.
[laughter]
Yes.
>>: In Scrum you have an idea of like when you will be able to deliver a particular thing. It’s either in
this sprint or not this…
>> Eric Brechner: That’s about estimation and planning about when things will happen. I will get to
that. Yes.
>>: What do you do when you have an excessively large backlog?
>> Eric Brechner: What do you do about an excessively large backlog? You don’t sweat it.
[laughter]
You don’t sweat it. Everybody has an excessively large backlog. They may not realize it but they do.
There’s always way more than you can ever possibly achieve. That’s called life. Yes.
[Laughter]
>>: This is kind of getting back to the expertise question. What if you have a team where it’s really a
bunch of small teams where these two people work on this service, or these two people work on that
service? You’re really not sharing a backlog across the entire team.
>> Eric Brechner: If you have split up teams, we’re running a little long on time.
>>: Okay.
>> Eric Brechner: If you have multiple teams and they really don’t share much with each other. They’re
working on their own backlog. Give them their own boards, doesn’t take up much space.
>>: Real quick…
>> Eric Brechner: Okay, I’m going to move on a little bit. Make sure I talk about branching and
publishing and about bugs. We’ll see how we go from there. Did I answer the question about Scrum?
We good?
>>: Yes, we are.
>> Eric Brechner: Good. What about branching and publishing? What’s going on here is you finish a
bunch of work, right. But it’s not all; as soon as it comes over here it’s not necessarily really done
because it needs to get published out, right. Maybe it’s a new release of an app. Maybe you’re
publishing out to production for a web service or a website. Maybe you’re just integrating, right.
Maybe you’ve been doing a bunch of work in a branch. You’re integrating it up to the main branch or
something like that.
There’s lots of reasons why there’s like a publishing step. What we typically do there is we divide up our
done area. Into its pending, pending integration, pending publishing, pending whatever it is, and it’s
published. When it gets published all the little stickies that were in that little pin get moved down here.
The next set of stickies keep building up until it gets published again.
There’s nothing really that we need to do other than doing the publishing step. But this allows us to
know when things are actually out there. Did that answer the publishing question?
>>: Yes.
>> Eric Brechner: Good.
>>: Actually, I’m sorry. That wasn’t my question but with the publishing would you do that even in
multi-levels? Like if you have RI multiple steps. Would you track everything like oh, now we moved up
from and L three to an L four?
>> Eric Brechner: If there were multiple publishing steps, couple different ways you could do that. If
your team is in charge of it you could have those steps on your board.
>>: Yeah.
>> Eric Brechner: If your team wasn’t in charge of it relax it’s done.
>>: Okay.
>> Eric Brechner: Someone else is going to take care of it. We don’t have to worry about everybody
else’s problems, thank goodness.
[laughter]
I know some people do, but really.
[laughter]
Okay, what about bugs? Bugs are a little different from features. How would you track bugs? There’s a
couple different ways to do this. One, if it’s a teeny weenie bug we’ve already been through this. If it’s
a small bug you can take care of it right away. Just take care of it, no big deal. It’s just you know a little
bit of noise. You fix it. You take care of it, done, okay.
But there are also bugs that are really big. They’re going to require some design work. They’re going to
be broken down into pieces. They’re going to have multiple tasks associated with them. They’re going
to need to be implemented and validated, and all that, in that case, there yet another task. You write
them on the sticky. You put them in the backlog, prioritize it accordingly, you push it through. Did I
answer the question about bugs?
>>: Yeah, I guess the biggest part of it is if you get rid of the Timeboxing the prioritization of bugs versus
features is a significantly easier problem.
>> Eric Brechner: It is, Kanban’s awesome, much simpler.
[laughter]
Yes.
>>: But bugs, so if it’s a customer reported live side issue. That’s a bug that’s reported. How do you
deal with that then?
>> Eric Brechner: If it’s something you can fix immediately, you fix it immediately. Now, I use to run all
the websites for Xbox. Typically when we had a live side issue there’d be an immediate fix. Boom, you
just take care of it like answering your email. You know you’re just right on it.
>>: Okay.
>> Eric Brechner: But that patches it but it doesn’t fix the underlying you know fundamental problem.
We fix it right away. We create a sticky for the underlying problem. We put it through.
>>: Okay, that was my [indiscernible].
>> Eric Brechner: Cool. Let’s talk about geographically distributed folks and online boards. Having a
physical board is awesome. It’s fast. It requires no skill to write new stickies and move them around.
It’s visible; everyone in the team can see it all the time. There’s never any question about where things
stand. It’s just there all the time. It’s great, right.
That’s really nice. I love having a physical board. It makes a big difference. When you have an online
board you know it’s like a web page or something like that, or in an app. It allows you to move around
the stickies. It seems the same but there’s extra overhead for members of the team to actually work
with it. They’ve got to launch the thing. Get to the page. When they’re creating something they’re
using the keyboard and the mouse, and all that. It’s just more work.
If that’s a barrier, turns out engineers are notoriously lazy. It’s just awful. I mean yeah you can bribe
them with pizza but that only goes so far, right.
[laughter]
You need to have zero barriers for your engineers to use the system which is why the stickies and just
and physical board. You move it, so easy, that’s the way to go.
However, if your team is geographically distributed obviously it’s impossible to have that physical board
that everyone can get in front of. In that case you’re going to use an online board. There’s lots of them
available, including one that’s actually built into TFS. You can use that.
Another one that I really recommend is that there’s lots of just scratch pads. Just these virtual scratch
pads and they have stickies on them. You can move them around just like a regular whiteboard. You
can use that, very low tech, very easy to use. It’s not quite as good. But you don’t have much choice for
a distributed team.
Did that answer the online boards’ question?
>>: Can I ask a quick question?
>> Eric Brechner: Sure.
>>: Can you use the one in Visual Studio online, the Kanban board there?
>> Eric Brechner: What about the online Kanban board for Visual Studio online? I have played with it.
It’s missing the done columns for each step.
>>: Yeah.
>> Eric Brechner: I have talked to them about this.
[laughter]
I told them I wrote this book and there’s a problem with your board.
[laughter]
They said, oh, shoot we’ll fix that. In the next release of TFS, which is I think coming out this spring that
will be fixed.
>>: Excuse me.
>> Eric Brechner: Yeah.
>>: Is there like Kanban template which is there with [indiscernible] or?
>> Eric Brechner: Yeah, it’s built in, in the information about its online.
>>: Okay.
>> Eric Brechner: Yes.
>>: From the geography point I’m still kind of curious about aside from the visual representation using
an online board. The time aspect of it because when you’re all in one place you can go and meet you
know for a standup meeting for a few minutes. Everyone kind of sees what’s going on.
>> Eric Brechner: Right.
>>: But if folks…
>> Eric Brechner: I have never heard. The question has to do with what about timing? Now we’ve got
an online board but what about timing for the daily standup kind of thing? Just a few minutes but
nonetheless it’s problematic when people are time shifted, right.
In every book I’ve read and every personal experience that I’ve had. There’s just no replacement for
getting together on a regular basis. There just isn’t. Someone’s going to have to do it during breakfast
or at night, or something. There’s just no getting around it unfortunately. Yes.
>>: This is going to sound like a joke question but I’m actually serious. Is the team that is implementing
the online Kanban board using an online Kanban board?
>> Eric Brechner: I do not know.
>>: [indiscernible] Doug.
>> Eric Brechner: I’ll have to ask them. That’s a great question. I have no idea. If I were them and they
were all situated nearby I’d be using a physical board.
[laughter]
Okay, let’s see when to use [indiscernible] for tasks? I want to get to the one that had to do with big
groups.
>>: That’s Katelyn’s.
>> Eric Brechner: Okay, I’m the one talking to that scale. Here it is scale to OSG. Before I get to that
one, benefits versus Timeboxing, since we talked about Scrum before. The biggest benefit relative to
Timeboxing is that since you’re delivering value continuously, every day. All those problems that you
have with synchronizing with other teams, right, because your sprint length. Whether it’s a week or
four weeks, whatever it happens to be, may not match up with your customers, with your partner
teams, your upstream and downstream partners, all that sort of thing.
Bring in your customer for the demo at the end of the month. Maybe they’re busy that month. Maybe
they want to reschedule. There’s all this extra stuff around that length of time. Also if something big
changes right in the middle of your sprint, now you’re stuck, right. Either you completely blow up your
sprint or you just have to wait.
None of that happens with Kanban. Kanban doesn’t have any Timeboxing whatsoever. You can give
demos to your customer any day you like. You should because it’s great to get customer feedback. But
you could do it every day. You could do it on their scheduled rather than on yours. After all they’re the
customer. You should be accommodating to them, right. All those problems go away.
One of the great things that happened just with Xbox, one of the things we had to do in order to start
shipping once every month, which is what Xbox does these days. You get an update to your Xbox One
every month. The website gets updated every day. One of the big issues of getting to do that every
month is we had to synchronize every teams shipping schedule, every teams sprint, whatever
methodology they were using.
For my team that was nothing happened, we were good. We could fit with anyone because we ship all
the time. Yeah.
>>: Without the sort of sprint cadence then how do you answer the question if someone says I need
you to do this thing, when will it be done?
>> Eric Brechner: There was the estimates thing here somewhere.
>>: Up, up.
>> Eric Brechner: Up, up, there it is, thanks, okay. Does that answer the Timeboxing question? Yeah.
>>: Just one minor clarification. Like the Timeboxing feels like it provides you a little bit of a focus at the
end of the sprint. Then like if things have gotten unstable it’s a chance to kind of reset and try not to do
that again. How do you not just sort of evolve into we’ve got to, we’ve just touched too many things…
>> Eric Brechner: Okay, so the question is about, one of the nice things about the Timebox is that you
kind of create some churn in the system. The Timebox gives you a chance to kind of get settled at the
end of the sprint and make sure that all the bugs are out of the system and you’re nice and stable.
The answer to that is with Kanban because there are done rules at every step, because you can’t move
from here to here, because the done rules are right on the board. Everyone sees them all the time
because you can’t move along you don’t build up bugs, technical debt, all that sort of thing. If you do
have one by all means write it on sticky, put it on the board, drive through, clean up that technical debt.
But it just doesn’t build up.
We’ve now been running Kanban for four years, actually three years on my current team. That Doug’s
the PM for one of my teams. We’ve been running that now for three years. We have never had that
issue, ever. It’s, Kanban’s awesome.
[laughter]
Okay, did that answer the question?
>>: I’m going to give you…
>>: Just final comment.
>> Eric Brechner: Okay.
>>: People do say the same about Scrum though. Like that just doesn’t happen at least…
>> Eric Brechner: People say lots of things about Scrum. I love Scrum. I used Scrum for eight years. I’m
never going back. It was great but I found something better.
[laughter]
>> Amy Draves: Eric…
>> Eric Brechner: Okay.
>> Amy Draves: Eric, four minute warning.
>> Eric Brechner: Four minute warning, thank you. These two are the most important outlying
questions. I’ll make sure I’ll get through these.
Scale to OSG, OSG for those of you that don’t know is the Operating Systems Group. It consists of only
about thirteen thousand engineers and other folks working on the operating systems. Xbox is one of the
groups. There’s also Windows Phone, obviously Windows Client. It’s a big group.
How do we fit into that group? Well the way that OSG tracks work is in TFS, which we’ve mentioned a
few times. That tracks all our work items as well as all of our bugs. It’s a great system. It’s hierarchal, so
you can have a work item, that’s like ship phone. Then it can have lots of children. Those are, you know
all the different pieces of shipping the next version of phone. Then it can, those can have children, and
so on.
It can kind of break down hierarchally. It’s a pretty nice system. The key thing though is that for it to
work. For us to kind of fit in, for our teams to kind of fit in, in that large organization, and all the tracking
that’s going on using the TFS system. Our stickies need to be in TFS. But our stickies are on the board. I
just told you how it was a bad thing to force engineers to try and update something online because they
don’t do it. It’s overhead to them and yeah. I volunteered Doug.
[laughter]
For my other teams there’s a PM on those teams. They got volunteered once a day when, you know for
any of these stickies that were tracking high up. Doug just sits down in a chair. He used to keep a chair
right across from the board. He sits down with his laptop. You did it at the end of the day as I recall,
updates each of the corresponding work items in TFS that correspond to each of the stickies. If they
moved around he updates them. Never took you more than ten minutes, usually just a few minutes.
Done, we are integrated in. As far as everyone else knows we’re using Waterfall or something to get our
work done. In fact we weren’t and we fit right in with everybody else, no problem. When you think
about the planning and the top down planning, and all that? That just determines what our backlogs
going to be. Helps us prioritize and order our backlog.
The last piece of this of course is estimation. I’ll get to that next. Did that answer the question about
OSG? Yes.
>>: Not quite. You may get there with estimation. But I’m still concerned about how that fits with OSG
level scheduling and the expectation that particular things will be delivered at particular times…
>> Eric Brechner: Right, so let’s get to scheduling and estimation. But otherwise clear enough on how
we coordinate?
>>: I have a quick question.
>> Eric Brechner: Yes.
>>: When you’re going through something there and you identify another task, or it breaks down to
more. Does Doug go enter those in?
>> Eric Brechner: Yeah.
>>: Or assuming that when whatever you’re planning with got pulled backlog.
>> Eric Brechner: The question is when new stickies get created does Doug enter them as work items?
If, that has our work items that we’re tracking you know up in OSG? Absolutely, he creates new work
items for them, types in the stuff, and there you go.
>>: Is it fair to say that you may have some stickies though that you work on pushed through that you
never…
>> Eric Brechner: Yeah, we do some technical debt. The question was are there stickies that don’t end
up in TFS? Yeah, we do a certain amount of just work just for the team, fixing up technical debt,
cleaning up some things, whatever it might be. Little tools that we need that we may not track in the
system because no one’s paying attention to that.
>>: [indiscernible]
>>: Does…
>> Eric Brechner: But we always pay attention to it.
>>: Does Doug have an intermediate set of deliverables that he’s thinking about above the task layer
but sort of below the OSG mandatory layer?
>> Eric Brechner: Any questions about what Doug you know is responsible for and all the things that
he’s tracking should be directed to him.
[laughter]
Okay, let’s talk about scheduling and estimation before we finish up here. This is a big deal, right. We
do have customers or partners, internal partners, or maybe even external partners. That need to know
when we’re going to be done with certain things. They want to do some planning, right. They have a
dependency on us. When are you going to be finished, right?
It’s important to do estimation. It’s important to kind of plan out a high level schedule, right. The way
that that’s done is also fairly straightforward. Now your team may have its favorite technique for doing
this. Maybe it’s story points. Maybe it’s Wideband Delphi. Maybe it’s T-Shirt costing. Maybe it’s using
Project and all kinds of fancy stuff.
You can do that. That will all work. It’s not any different work is work. You can plan in out in whatever
way you’re most comfortable. That’s fine, if you want to make it a little simpler or be more Kanbany.
The way to do that and again you don’t have to do this. You can do it the way you’ve always done it and
its fine. You’ll produce work at a certain rate. You’ll adjust your estimates accordingly.
Kanban turns out to be very quick. But nonetheless you can use whatever techniques you like. If you
want to use a Kanban like technique, something that’s more related to directly what you’re seeing here.
The way to do that is just to count how many stickies you complete in a given period of time, say two
weeks or a month. Just count, it’s not complicated they’re stickies, just count them. That’ll tell you how
many stickies you do per day on average.
Then you count up how many stickies you have you know in priority order, right. How many stickies you
have that are going to go through that system. Now, those are going to be broken down. There is an
estimation step. But the estimation step is one that’s very intuitive. The estimation step is hey, if we
were to break this down how many stickies do you think we’d get, right? Which is a very intuitive thing,
people can figure that out pretty easily.
They’ll make a guess. It may not be perfectly accurate but estimation never is. They’ll make that guess.
You can write it down right on the sticky and compare and contrast when you actually break it down.
You take the total number of task stickies that you think are going to come out the other end. You
multiply that by how long it takes for each sticky. You have your estimates.
Again, in the absolutely free to you if you buy my book.
[laughter]
There’s spreadsheets that do this for you. You put in all your things. You estimate how many tasks each
of them are going to be. You put in your rates that you get from this or it calculates it for you. Boom,
it’ll give you dates because it’s just not that complicated actually. Then you can do all the scheduling
stuff that you like, okay.
Did that answer the question? Great, how we doing Amy? Do I have time for one more?
>> Amy Draves: No, I think we better…
>> Eric Brechner: Alright we’ve covered all the important stuff. Everything else including the answers to
the remaining questions are in this book. There’s even a quick start guide, a troubleshooting guide, rude
Q&As, checklists. Ah, it’s the best.
[laughter]
Get your today. Thank you so much for your time.
[applause]