ERIC BRECHNER: Thank you, sir. [APPLAUSE] We have a little video to
that the folks at my publisher asked me to do. But they let me do it
anyway I wanted, so I enjoy. I'll give you a little
introduction to the book and then we'll get started. [VIDEO PLAYBACK] -I'm Eric Brechner. I'm an experienced developer
at an established software company. My favorite C programming book
is thin, clear and complete, with plenty of examples. I didn't think life
could get any better. Until I found Kanban. After I found
Kanban, I joined Xbox and started shipping every day,
every week, and every month. With Kanban, there are
no milestones, sprints or overhead. Quality happens at every step
and you can ship every day. Kanban was built for
continuous delivery. I love Kanban so much that I
wrote a book about it, Agile Project Management with Kanban. It's thin, clear, and complete,
and with plenty of examples. There's even a quick start
guide, worksheets to fill out, checklist to follow,
and diagrams to ogle. Plus it covers planning
and estimation, working within
large orgs, adapting from traditional waterfall,
and evolving from Scrum. You'll love it, and your
team will love Kanban. Get it today from your
favorite book purveyor, and I'll throw in increased
productivity and quality, and decreased time
and cost for as long as you follow the easy
steps in these pages. Rejuvenate yourself and
your product development with Kanban. Get on board! [END PLAYBACK] ERIC BRECHNER: So,
a little fun there. I enjoyed that. A little bit about myself. I've been a
professional developer as [INAUDIBLE] mentioned. For a long time I've focused
on computer graphics, and then on data flow,
and then on image, you know, image editing
and things like that. I've done a lot of
different things. But the kind of the
side-- my side interest has always been on how
software development is done. If you ask my wife, I'm a little
OCD about how I do things. It's paid off professionally,
maybe a little annoying in my personal life. But nonetheless I've
just been fascinated by how work gets done, and
how to get the most out of every day and the
most out of my teams, now that I've been a development
manager for the better part of 15, 20 years now. So I-- since I manage my teams,
I get to tell them what to do, kind of-- we experiment a lot. So I've experimented
with just about every methodology
you could think of, everything from pair
programming to TSP to various forms of Agile
and test-driven development, obviously Scrum. Scrum was phenomenal. I used Scrum with my teams
for a good eight plus years. And then finally, I discovered
this thing called Kanban, and I've been using it with
my teams now for four years. And Kanban is just so
dramatically simpler, and yet better. It produces higher quality at a
much higher rate than anything else that I've ever used. I've just been captivated by it. It really is the first
time in my entire career-- and I've been working since
professionally since I was 15 in software-- it's the
first time in my entire career that I feel like every
minute of the day that my team spends
working they're working on actual value
going into the product. They're not spending time
doing other things that contribute indirectly, but
really aren't that related. You know, having all these
extra meetings, and all these extra documentation,
and all this extra planning. It just doesn't
happen, they're just working on stuff for customers. And with Xbox, it's
a very, obviously, it's very consumer-facing. We ship to every
console every month. We ship online
multiple times a day. It's having that kind of
methodology at my disposal that has given my
team a real advantage. And I can do a lot
less-- excuse me-- a lot more with a
lot fewer people. My team is an order
of magnitude smaller than the other teams that
do similar work to mine, and we produce a lot more with
a lot of higher quality, which helps me in my annual review. So life is good,
and it's so great that I finally decided I'm
going to go ahead and write a book about this, because
this is just too great. So that's what I'm going
to talk about today. Here's the book. We ordered some
but unfortunately they didn't arrive on time. But that's what it looks like. It really is that thin. I wrote it with folks
like you and your peers, my peers at work,
in mind, who don't like spending a lot of
time thinking about this, hate the idea of working on
process, it's just evil, right? This doesn't feel at all like
process, and that's part of it. There's just no
overhead involved and it gives us tremendous
project management capability. So without further ado,
let me talk about it. So the way that I'm
going to do this, is I'm going to run this
talk using a Kanban board. So I have no slides,
I'm just going to run it as a Kanban board. And what we're going to work
on today for our product is your questions. So I'm going to track your
questions on the Kanban board and answer them. Now I realize this isn't exactly
the same as writing software, but I'll draw the analogy as
we go and hopefully you'll be able to see that pretty easily. So to start with let's
just draw a Kanban board. The Kanban board is the center
of this particular approach and there is nothing else. It's not like there's extra
things to keep track of, spreadsheet stuff. It's just the Kanban board. So what does a Kanban
board look like? It's pretty straightforward,
you start out with a backlog. So I'll put the backlog. OK so we started with a backlog. How many people here
have used Scrum? Any people use? OK, a fair number of
people using Scrum. So you're familiar
with what a backlog is. If you use a more traditional
waterfall-- like old school Microsoft, and when I
was at Boeing and stuff we kind of used old school
waterfall-- that would just be a feature list, right? But the backlog is just a list
of stuff you've got to do. Typically it's prioritized,
it's ordered in some way. So that's the backlog. That's where I'll keep
all your questions. And then we have steps. So the next step
and in this case I'm answering your questions. The next step
here-- normally I'd just say I'd answer
the question-- but some questions
are kind of big. And that's true in software
development as well. The things in your backlog
aren't all the same size, some of them may take
just a couple of days, but some of them may
take a few months. They just come in
different shapes and sizes. So you kind of want
to break those down into equally sized pieces, and
the same thing with questions. You could ask a very
complicated question, and you're going to
want to break it down into a few different questions. So the next step
will be breakdown. All right, and
then after that I'm going to answer the question. And then, after that
I want to validate that I answer the question,
because I'm trying to be a good speaker here. So I don't want to
just answer whatever question I thought
you asked, I want to make sure I'm answering the
question that you asked for. Sound familiar in product
development, right? You code up something, but
until you get customer feedback, you don't really
know what you have. So last step here
will be validate. So that's my Kanban board. You see, it didn't
take me very long. Our actual Kanban boards
are just like this. They're a little
bit bigger, it's kind of a small white board,
but they're just like this. And they have the
same number of steps. We have a breakdown
step, some people call it specify because you do
a little bit of specking there, just enough to break
it down into pieces. Answers, typically implements,
and validate is validate. You can obviously name the
steps anything you want, and you can have as
many steps as you want. This is just an example. So that's it, so we're going
to track all our work here. Now we get to the
first place where this seems a little
different from what many of you who may use boards--
I know a lot of people using Scrum and even
Waterfall use boards to track their work-- this is
the first step where it really kind of differentiates itself
from just regularly using a whiteboard to track your work. Each step has an active
and a done column. So each step is broken into two. So we're working on
breaking it down, we've finished breaking it down. We're working on answering,
it we finished answering it. We're working on validating,
we finished validating. So that's a little
different with Kanban. And it turns out to be
really important in order to use Kanban as a project
management technique, rather than just a visualize
your work technique. So with each of
these steps, we want to be able to specify-- that
one of the reasons for having the I'm working on it,
I'm done, is to specify what it means to be done. Now I'm not saying that
engineers might occasionally cut corners, maybe
not get a code review, not do a full bill, not
run all their tests, or write the unit disk. I'm not saying
that ever happens, but just in case there's
someone-- not you, but someone you know--
who doesn't always do all those things,
you want to have a check to make sure that they're
not just moving things along without actually following
through on all of their work. This never happens at Xbox. OK, so what you want
here, is you want rules. We call these done rules. You want rules that specify
when something is done. So for the breakdown
step-- now these rules I'm going to make
for these questions. But you can imagine different
rules for actual software development. So for breaking
down a question, I want to make sure-- it's
not going to be broken down unless the question can
be answered in like less than two minutes each. So I'll just say less
than two minutes, and then I'll know I'm
done breaking it down. Because I want the questions
to be about the same size, and not take too long. For answering, when is a
question going to be answered? Now this is being recorded,
it's being streamed, so I'm going to want
to repeat the question. So I better repeat, and then I
need to answer it, of course. OK so when it's repeated
and answered, here we go, past tense, then it's done. So that'll be my done
rule for that step. If that were implement,
in product development, you can imagine that saying,
it's been a code reviewed, it's been unit tested, you've
run through all that stuff. Whatever other steps you would
normally do to say something's finished being implemented. And then finally for validate,
I'm answering questions here. I want to make sure that
the questioner is satisfied. Did I answer your
question, kind of thing. So for this one it will
be questioner satisfied. And then I know I'm
done with validate. And that's it except
for one other element, which is a little tricky. But before I get to
that, I want to make sure that I've answered any
questions you have for now. So yes. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: OK so
two questions there. One on prioritization and
one on due dates, absolutely. And I'll talk about
these, obviously, in a lot more detail when
I actually answer them, but the two questions there. One was on how do you
handle dependencies, and the other question was, how
do you handle assigning work? AUDIENCE: In what scenarios
does Kanban not work? ERIC BRECHNER: So
when not Kanban? Just such a sec. Continuous improvement,
I was just kidding. And then there was
a second question? Evil, evil meetings. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: We do
have a daily stand up. Oh, look, hey, I
just did something. So we're running Kanban here,
and right now collecting items for the backlog,
and there is a question about how often do
you have meetings, what meetings do you have. And I just answered
it straight out. We just have a daily
stand up, but there are no other meetings,
that's the answer. There are no Kanban police, no
one just marched into this room and put me up against the wall
and said horrible things to me. It's not like that,
Kanban is just a tool to help you
manage your project. You don't have to put
all your emails on here. If there's a quick
piece of work that's going to take you five,
10 minutes, maybe an hour, you can do that, it's OK. It's all right to just do work
as it comes in if you need to. Kanban is here to
help you manage work that's going to
take a few days, that's more like project type work. But you know there aren't
hard and fast rules, and people that are going to
make fun of you and say you're doing it all wrong and
all that sort of thing. This is a tool to help you work. Any other questions? We might as well-- why don't
we go ahead and get started, and then you can ask questions
all along, which is by the way, a lot like product development. We're going to go ahead and
prioritize everything and start working on it and the new
feature requests will come in, in the form of more questions. And we'll just slot those in
to our existing priorities. So let's see we've
got lots of questions. First step, we want
to prioritize them. Let's talk about
prioritization, that's going to be my first question. It's straightforward, I
don't need to break it down into more than one. I move it over, and now
I'm going to answer it. You can move the
stickies at any time. Typically it's a whole team,
not one person doing this, of course. But you can do Kanban at home,
it's called personal Kanban. Anyway, it really is. It just has three columns,
a backlog, doing, and done. And that's it, it's very simple. But it's pretty handy,
a lot of people like it. Anyway, so for
prioritization we're going to put things in
order and the team just does that together,
based on their shared sense of priorities. They can do it in
a daily stand up. So what am I going to do here? Let's see. I definitely want to cover
estimation and due dates, because lots of
people ask about that. And then when to launch
is related to that, and then dependencies
are nasty after that. Put those closer to this side. Dependencies, maybe
assignments, how large a team, setting expectations. Roles, how about over there? Onboarding time. Oops I lost one. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: I am doing this
in order most important down, and then again. And I'm doing it based on
my personal preference, because I am in charge. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: Oh, you would
do it together at a daily stand up. Again, answering questions
straight off the bat. That was a quick one. You could have a
quarterly meeting if you wanted to, if
it was a major deal. And I talk about that,
there's a chapter in the book all
about using Kanban within a large organization. I'm currently within the
Windows organization, there's 13000 of us
in that organization. There's about 8,000 of
us that are engineers, so it works well
within that framework. But obviously there's
more to it when you're fitting into a big team. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: Absolutely,
of course, that's what I'm doing right now. This is how you prioritize,
so that is how you prioritize. It's not hard, it
doesn't involve a lot of extra whatever. It's stickies and
you move them around. If you're curious about
how you re-prioritize, I have re-prioritized. That's all there is to it. Like I said, Kanban is really
simple and really quick. It's why my teams now I have
gotten just absurdly fast. Yes? You're absolutely right. So the point that this
person was just making was it's a lot easier for me
to do it when it's just me. It's harder when you've
got a whole team, let alone you're in an organization
like 8000 people. So obviously with 8000
people is more involved, and there's a top down and
bottom up thing going on. And I describe all that in
a lot of detail in the book. I can add that as
a question here, if you're interested,
on how that works. So large scale. But at some point or
another, your individual team has a set of work
they need to do. At some point that happens,
and you do need to sort it. And what we do is,
just have the team together at the daily stand up. It's time to re-sort the work. We do this, well
we do it every day kind of as an insertion sort. But sometimes you need to
re-sort the whole thing because something has changed. And then just have
conversations about what it is, and talk about
what the customers need, what the expectations are
of executives and partners, and stuff like that. And you reorder it, and
you reorder it very much like I did, but obviously
it will take you more than the three
minutes that I spent. But it wouldn't take you much
longer than about 20 minutes. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: Quick question
about the daily stand up. How long does the
daily stand up take? Some teams do it in
less than five minutes. My teams typically use it
to socialize a little bit, so they typically take
about a half an hour. But that's just
personal preference. In terms of how much work it
is, it's not a lot of work. Obviously if you are going
to redo your whole board that would take a little
bit longer for that one. OK. So that is prioritization. Let's go ahead and validate. Did I answer the
prioritization question? AUDIENCE: Validated. ERIC BRECHNER:
Excellent, all right. OK, now before I move
on to estimation, I want to make sure I talk about
that last element of Kanban. And it's an extremely
important one, although all it
is just a number. Next to each step, and it's
called a work in progress limit or WIP, work in progress. A WIP limit. And you assign WIP
limits to every step. And this is the part, along
with the done rules, that really makes this project management. Because until then you could
just work willy-nilly and maybe your project's on track,
and maybe it isn't. Who knows? Right? The done rules will give you
a certain amount of quality assurance, but the actual
management of the work, there's not much going on here. You can just see it. So what are the WIP limits? The WIP limits are just a number
associated with each step, and they limit the number of
stickies allowed in that step. That's it. That's what they do. So the way that I just
treated prioritization, I had a WIP limit of
one across the board. I just moved one sticky
all the way through. But for a team, a larger
size team, of course, these WIP limits are
going to be a bit larger. One of the questions
a lot of people have when they're
first using Kanban is how do you set the WIP
limited appropriately? What do you use? And for that there's a
fairly simple answer. And I have little
Excel spreadsheet you can use to calculate
this for yourself. You can download it, it's
very simple but nonetheless spreadsheets are cool. So here's what you do to set
up your initial WIP limits. And then over time,
you can adjust them if you're finding that things
aren't working quite right. So for the initial WIP
limits, one of these steps typically takes longer
than the others, often it's the
implementation step. Doesn't have to be, but for
the sake of argument here, I'm going to say that the
answer step is the longest step. That's often the longest
step, the implementation step. So I'm going to set
that WIP limit first. I'm going to set that WIP limit
to be the number of people that are involved in working on
it, in my case it's just one. But for a team, let's
say you had a team, and it had five
developers on it, and some people who were doing
the specifications, some people maybe were testing it, maybe
the developers also test it. But let's say there were five
people who could actually do the implementation
step, you would see that WIP limit to five. Make sure they
all have something to do, plus a little
bit of buffer, right? Because there is some
variation in work sometimes you get stuck
for a little while and you want to
work on something else for a little bit,
something like that. You want a little bit of buffer,
so maybe add on 50% of that and then you're good. For me, I'm going round
up and call this two. So that's going to
be my WIP limit. I'm maxed out, I can only have
two stickies in that column. And that includes on either
side, whether they're done or I'm working on them. I can only have two total. And that's the WIP limit. Once you have the WIP
limit set for one column, you then can set the WIP
limits for the other columns so they match the pace. And this is where it
becomes project management. You want them to match
the pace because you don't want to overload the
implementation step with specs. You've probably worked
on teams before where you do a whole ton of
work on all these things you're going to do next. And it just piles up,
and then maybe get to it, maybe you don't. Maybe you get to some
of it, and by the time you've done some
of it, you realize the first part, the rest
of it was just wrong. And you need to start over, and
you've wasted all that time. Not a complete waste of time,
but kind of a waste of time. You don't want to
overload things. You want to break
down step to kind of match the pace
of the answer step, and likewise with validate. You want the speed at
which you can validate things to match the pace
the speed at which you can implement them. So you set the WIP limits
for these other ones to match that pace. And for me, and the
minimum WIP limit is one, so for me I'm just going
to take that one, one. Because those are a lot faster,
I can just set those as one. For your individual team,
calculating these throughputs is fairly straightforward. And like I said, I have
a nice little spreadsheet for those people
who don't even want to do the division and stuff,
it will calculate it for you. So that's setting
those WIP limits and that's what
I'm going to follow as I go through the
rest of these questions. And that's everything, by
the way, that's all of it. There's not really a
lot of extra complexity, except of course, there
is subtleties to how you do some of these things
that people have asked about. So let's start with estimation. So estimation, a lot of people
struggle with estimation whether they're using
Kanban or some other method. I'm going to break this down
into two different things. One is how fast you are. And then another
is how many tasks. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: I'll get to that. OK so my estimation
step has now become, or my estimation question has
now become these two questions. And I'll start with
how fast you go. So in order to
estimate anything, you need to know how long
it how long it takes, right? That's the whole
point, you're trying to estimate how long
something's going to take. So when it's going
to be ready, you can calculate from how
long it's going to take. So to calculate that
in Kanban turns out to be pretty straightforward. What you do is you pick
some amount of time that you're going
to measure, you're going to actually pay attention
and measure these things. Maybe you have an
automated system that could do that
all the time, but now let's just say you just got this
board, that's all you've got. And you're deciding, OK how
fast am I finishing things? All you do is you say, OK, how
many stickies make it to done within a certain time period? Say two weeks, or a
month, whatever you want. So you pick that
time period, you count how many stickies
move all the way through during that
time period, you divide and you get stickies per day. Now you know how
fast you're going. Ta da. Any questions on how
to calculate how fast? Yes? AUDIENCE: [INAUDIBLE] ERIC BRECHNER: So quick follow
up here, sometimes-- oh look! I'm handling a bug. OK, so I implemented an
answer, and it didn't quite meet with the
validation criteria. There was a bug, I
hadn't quite answered it because there's variation in
size as you were pointing out. So how do you handle bugs? There's two ways to handle bugs. Sometimes those bugs
are trivial to fix, they'll just take you a few
minutes, and you can fix them. This is an example of that. I can answer that
question very quickly. So you just fix it. Just fix the bug, don't
get hung up here, right? It's like answering
the quick question. You just fix it, you don't
have to put it on the board. But sometimes bugs
are really nasty, and will take you a long time,
you actually have to design it, you have to code it up. It's going to, I
mean, it's going to be a lot of work to do. Obviously you code up
all fixes, but you know. It's going to be a lot of work. For one of those, we would
write a new sticky that talks about fixing
that big bug, we prioritize it on the list
with everything else, we'd pass it through the
same steps as anything else. And we'd fix it. In this case, your
question was about what about different sizes? And that's the idea
of the breakdown step. The breakdown step
should take things that are of varying
different size, and break them down
to the things that are roughly the same size. The metric I like to
use is they'll take me one to three days-ish each. So that's what you want
to break it down to, things that take a few days. And it's typically pretty easy
to do in the break down step. Just break it down into tasks. Does that answer your question? For the how fast? AUDIENCE: Yes. ERIC BRECHNER: OK. Let me cover how many tasks,
and then we'll finish this off. OK, so now we know how
fast things move through. We can do two, and 2.3 tasks
per day, something like that. That's what it comes out
to be, something like that. OK, great. So how many tasks do we have
because the whole point of this is saying I've got
a project, I've got a whole backlog
worth of stuff, I want to know how long
it's going to take, so I've got to compute that. All right, for that you need
to do an actual old school type estimation, but what
you're estimating now is not how many tasks hours
or how many story points or something like that. What you're doing instead is
saying, all right for this item how many tasks would
that break down into? Which is very
intuitive for folks. People can figure that
out pretty easily. Just OK, this is a big thing,
how many different tasks? Each one taking a couple days,
how many of those are there? Most people can figure that out. Now you can use Planning
Poker for that if you like, if you happen to
like Planning Poker. You can use your
favorite method. And by the way, you can
use your favorite method to do estimation in general. There's nothing special
about Kanban here. I'm giving you one that
fits in well with Kanban, but any estimation
technique will work. But this one is a little
more intuitive to folks. It's not this abstract
thing, the story points, or something like that. It's just how many different
tasks is that one made of? So you make that
estimate, you add those up for all your different
features, you multiply them by a task per day,
or divide, or whatever that is. I have a spreadsheet for
that too, not that it's hard, but you just divide,
and then ta da! You get how many days
it's going to be. And then you can
plan dates around it. If the number of
days is beyond when you're supposed to ship, you
can have those discussions, you can simplify things,
you can add people to the team well in
advance if you need to. That doesn't always
work, but you can make adjustments
of one kind or another to try and meet your dates. But that's how you do it. Does that answer your question? Good. So let's say you
have a due date. We have due dates, we have
dates at Xbox, that's for sure. So let's say you have
a due date and you have a bunch of work
queued up, and you want to make sure that that
work is done by the date. You would estimate
how many tasks are in each of the items
that are due by that date, you would use your task
completion rate to figure out how long it's actually
going to take, and then you would
compare that calendar date to the actual date that
you're supposed to deliver. And that would either
be before it, yay. Win. Or after it, boo. AUDIENCE: [INAUDIBLE] ERIC BRECHNER:
Right, because you've take two weeks, a month,
whatever it is, and calculated, just counted how many tasks
you can do during that time. All those tasks are going
to be roughly the same size because they were broken down. So now you estimate
how many tasks are going to have that you
need to finish by the date, you have your rate
of completion, so you know exactly how
long it's going to take. Ta da. And it takes all the
different factors of how big your team
is, whether or not you work on weekends, all the
bugs that you might have fixed, all the e-mail you
might have gotten. All that's taken into
account because you counted how many actual task
you completed during that time period. So you just have it. Does that answer question? OK. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: OK so the
question was, how do you make tasks the same size? I mean obviously you can
do the breakdown thing. You can say they're
roughly the same size, but life is full of surprises. So tasks sometimes are much
bigger than you expected. Even though you
broke them down, you thought they were going
to be a couple of days, maybe they're big. So the follow on question was,
since tasks can vary in size, the estimate will be inaccurate. But again, we're taking
that breakdown step. So the variation in
size is only going to be plus or minus a day,
and that variance in average just evens out over time. There are statistics about
this and stuff like that. It follows a normal distribution
because you're adding them up and all this. But, you know, it's going
to be pretty fricking good. Now I will say this
about estimation. So we just spent a bunch
of time talking about this. Interestingly enough, my
team doesn't do this anymore. So we did at first. I actually have a number
of teams, none of them do it anymore. We did at first, because
people wanted to know, of course they wanted to know. You have to hit your due dates. But we delivered early
or on time all the time. It's just a machine,
just flows right through, the flow is so smooth. We were so predictable
that the team stopped asking us for due
dates and just started focusing on where they
were in our order. Because they knew if
they were in our order, it was going to
come through, and it was going to come through
in plenty of time. So we just haven't been asked
for estimates much at all anymore. I'm not saying that we never do. We occasionally do it,
but it's become rare. The quality is always
there, the speed at which we operate is always faster
than the other teams. And they're asking for
something because they have work that they
need to do and they want to know when our
thing is going to be ready, and by the time
they think of it, by the time they're ready to go,
we're typically there already. So they just need to
make sure that they're in higher enough
priority on our board, and that's what they concern
themselves with, not how long it's going to take us. Because we just developed this
reputation, it's fantastic. Now I'm not saying, I'm not
guaranteeing that for everyone, and obviously there's
different organizations who have different demands
on specifying exactly what date you're going to
be done with whatever. And there are methodologies that
I talked about that give you very good estimates,
but I'm just saying that it's so
reliable and so continuous that we just haven't had that
demand on us much anymore, which is pretty nice. Yes? AUDIENCE: [INAUDIBLE] ERIC BRECHNER: So
the comment here was that it's a sign of
a mature team regardless of what methodology they're
using, when they become really reliable both in terms
of quality and timing, their need to take care
of these little details about what-- just go down. And that's certainly
been my experience. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: So the
quick question here was, in terms of the backlog,
do we fill it up as we go? And who does that? When does that happen? And the answer is yes,
we fill it up as we go. We do an insertion
sort into it, which is exactly what I've been doing. That's just what we do. And no we don't have any sprint
planning meetings or anything like that, which again
is more time focused on just delivering value,
and less time on overhead. AUDIENCE: [INAUDIBLE] ERIC BRECHNER: Right so the
follow on point was, yeah, but when you have a specific
due date you can't just arbitrarily insertion sort, you
need to make sure that it hits and place it accordingly. The experience of my team has
been that doesn't come up. And here's why. Because someone gives us an
absurd due date on an item that's not that important. That's because that's
their job, they assume that they are the
only ones in the world, and we must serve them. Fair enough, that's
everyone's right. So they give us
this thing, and they say we must have this tomorrow. And we say wow,
we're not going to be able to deliver
to you by tomorrow because we have way more
important things on our board. Oh but I am the most
important person in the world, you must do it in time for me. And then we show them the board. It's a great thing
about a physical board. Hey here's our board,
please place your sticky where you think it belongs. They put it on top, we
say, OK let me tell you what the top one is, it's
this, it's a KERNAL thing, and the one under that
is a driver thing, and the one after
that is something that the VP asked for. Oh, OK, well maybe here? OK, well that's this--
Oh, how about here? Looks about right good, A plus. Now you're going to get it
after we do those other things. We will do those other things,
and if they need an estimate obviously we can
provide an estimate. And then they can adjust
their dates accordingly. But again, the conversation
is about priorities. It's not about dates
as much anymore, because we will hit
the date, assuming that the priority is right. And I'd much rather have that
conversation because that sounds like a
business conversation, rather than a ooh I want it
by my birthday conversation. AUDIENCE: Dates aren't always
driven by the business though. ERIC BRECHNER: I
understand, and when dates aren't driven
by the business, we have a methodology
that handles that. And the priorities
would reflect it. But very often we
get requests that have nothing to do with that. They have to do with one team's
wanting to feel a certain way. It's not always the case,
not always the case, and I respect that. And this handles it just fine. I'm just saying, day-to-day
this is where we've landed. That has nothing to
do with Kanban, that's just how our team has landed. Yes? AUDIENCE: [INAUDIBLE] ERIC BRECHNER: So open ended
tasks, how do you handle those? Somewhere in here. OK, let's talk
about dependencies. I'm going to go
ahead and answer it. OK, so dependencies, and next
up will be when to launch. And we can do roles. So dependencies,
obviously, not everything shows up the way you
want it when you need. Even if you give
people due dates, and even if they
are good about that, sometimes people slip,
or they deliver to you and it's not quite working
the way you'd hoped. So how do you handle
that situation? So I'm assuming you've already
prioritized accordingly, they've already given
you an idea of when it's going to be ready,
and you placed things with that expectation,
then you're working on it, mix
it up to the top, you go and grab that dependency. You try and use it and
it's either not there or it's not working right. Now what do you do? Now you're stuck, you
can't continue work. What do you do? So what we do, is we go ahead
and added an extra column in the middle of our answer. This is small board,
we have a wider one. We had an extra
column called Track. And then we'll take the
dependency that stuck, and we'll put it there. All right now what
do we do there? What's happening there? So we're trying to work
on it, but it's stuck. Obviously we don't want
it to hold up all work and have everything just shut
down, but at the same time, we don't want to
just ignore this. This was the highest
priority item, there are expectations
around it, there may be due
dates around it. We need to meet our commitments,
and we take those commitments quite seriously. So what do we do? We put in the track
column, and then, that's assigned to somebody. Sometimes it's the
same developer that was supposed to
be working on it, sometimes we have someone
who works across teams, we call them program managers. And they're the ones
who are handling it, but it's assigned to somebody. And that person's
responsibility when that's in the track
column, is to drive that to the correct state. And maybe that correct
state is we work around it. Maybe that correct
state is we add the task that the other team hasn't
finished yet to our backlog, and we start working on them. They pop up to the
top here, they're the most important things. They go right up to the top
and we start working on those. Sometimes we change
what the feature is or what we're expecting. Maybe we lower the
priority, but we're going to do something
with that track task. And then every stand
up we're talking about those track tasks. Now the track tasks don't
add to the WIP limit. So we can continue
on work, they're not going to stop
the rest of the work. Of course, if we decide
to take on the work that's necessary to complete
that dependency from the other team-- because
we have to-- then of course that work will flow through. But eventually that
dependency will get unblocked because we're going to
work it hard every day. And by the way, this
comes up all the time. We typically have
two or three items that are in this track
column, because, you know, it's a tough world. As soon as it gets
unblocked, then it pops into the implement, because
it is the highest priority item. We're not going to take
something from the left, we're going to take something
from the track column as soon as it's unblocked. Because, it's by
definition, we're working on it before anything
else, it's the top priority. And then we work it through. All right, when to launch? So, you're working on a whole
bunch of different features, you're continuously
moving them through. Notice that unlike Scrum
or Waterfall or something like that, there isn't one
specific day when you're finished with something,
you're finished with things all the time. You're finishing
tasks all the time, and there's quality
bars for every step. So by the time it hits
the end, it's ready. It's ready for wherever
it's supposed to go. In our case, that's
either an RI into WinMain for when we're doing Windows,
or it's actually posting it out to Azure. It's part of the service. That's what happens at the
end of that, so it's done. So theoretically you can release
at any time, but, of course, that's a little silly. You want your releases to
have some coherency to them. So what we do for
things that are part of-- when it's
not just day-to-day-- we can publish it all the time. And some of our stuff
works exactly that way. We just go to production all
the time with them, no big deal. But sometimes it's part
of a larger collection, and sometimes with a due date. And when it's like
that, then we wait until all the
stickies associated with that particular launch
that we were going to do are complete. And then when
they're all complete, they've all made it over
here, we then ship it. And, in the case of one of my
teams, we get ourselves a-- OK, this is like our little-- a
maple bar bacon cake, which is really delicious,
but not good for you. Anyway, so we celebrate
when that's done. Now if we've completed
the work before the rest of the organization completed
their work associated with that, we'll still
have the maple bark car. That's not going to be denied,
but we may not actually go out the door with it
and signify the release until everyone else
has reached that point. And sometimes when
it's something that has to go with a
bunch of other things, we actually need to track that
we have a special section here, in this last done
column for things that are waiting to go out the door. And we'll put it there
until it actually goes out the door with everybody
else, and then we'll move it into the
final done column. Did that answer the question
about when to launch? Roles. With Kanban there are
no specific roles. That isn't to say that people
don't generally have roles. They do on any team, but there's
no specific specified roles. That said, there are
some natural roles that people kind of
fall into on the teams that I run with
Kanban, and other teams I've known who use Kanban. There's the role of the
person who kind of runs stand up every day. That's one particular
person on each of my teams that's assigned to do that. Obviously other people fill in. There's nothing
special about it, they're just get up
there and kind of make sure the conversations
don't go completely off the deep end. So there's that role. We do projects,
we use this thing called TFS, which
is a lot like JIRA, or other work item
tracking systems. So there's a big work
item tracking system that we use inside of Windows. Windows Phone, and Xbox
are all using the same OS, coming soon to a PC near you. OK, fine it's Chrome. Anyway, it's all good. So we're all working
on the same operating system at the same
time, which means that we're kind of sharing at
a lot of status all the way up. And so what that
person does is that he picks a few minutes every day
and just transfers information about which stickies have moved
into the work item tracking system. And it takes him just
a few minutes each day. And that way everyone can see
what we're seeing on our board, but in the work item
tracking system. So those are sort of roles. The other roles are that
some members of the team kind of focus in on certain steps. If you had a formal test team--
we have a kind of DevOps type situation-- but if you
had a formal test team, maybe they would mostly be
the ones doing the validate. The dev team,
obviously, mostly does the implement sort of step,
and then the program managers and stuff mostly do
the breakdown step. But that varies. Any member of the
team can do this, which is kind of like Scrum. Any member of the
team can do it, but if you wanted to be formal
about it, you certainly could. There's nothing
specific in Kanban that says it has to
be a certain way. Right, yeah, so that's
exactly what happened. So the question was
about breakdown. There's the original
sticky, which was big, made up of a bunch
of different tasks, and it breaks down into
lots of different stickies. What we typically do is we'll
keep that original sticky, but we'll put it underneath
the pile of the stickies that it breaks down into. And that counts as one in
terms of the breakdown count, the WIP limit here. That counts as one bundle. And then we'll peel
those off one at a time and move them through. OK so the follow on
question to the roles was is there the equivalent
of a product owner? And the short answer
to that is, it varies. It depends on the feature. So some features,
if they're driven from partners to what we call
the PM, a program manager, they act as that product owner. They know that they've been
working with those other teams, they know exactly what
they're expecting, they kind of represent them. But there are other features
that are brought up maybe they're infrastructure
fixes, maybe they're taking care of technical
debt, maybe they're a feature that someone on the
team came up with themselves, and they act more as
the product owner. So it's not a it's not a
very specific static role. The team just works together. But you could have it be--
there's nothing in Kanban that keeps you from having
it be a particular role, it's just it doesn't
say that you have to. Yeah? AUDIENCE: Is there a
concept of swarming? ERIC BRECHNER: Absolutely
so the question was, is there a concept of swarming? Absolutely. So let's say we've got
a situation-- so where is the one about tasks too
big-- let's talk about that one. OK so let's say
you've got a task, and we'll do open-ended
tasks as well, OK. So let's say you've
got a task, and you thought it was going to be
one to three days or something like that, but it turns
out it's a monster. When you started going
into it, or maybe it was kind of an open
ended sort of thing, it just ended up being way
bigger than you thought. If that were the case,
then what happened is on the board you see
the WIP limit here is two. So what happens on the board
is that you'd have your items here, and they're not moving. They're just sitting there. They're not moving. In the meantime the person has
already broken down a step, these are all validated. Now you've got a situation
in which this person can't do any more breakdown, there's
already one item in there. So they're not supposed
to do that work. The validate people
they've finished, everything's all
validated because they're working on a flow. And now everything's stuck here. It's obvious, you've
got people who are supposed to be doing
breakdown and validate, they got nothing to do. Now on a regular team without
any project management stuff going on
there, this person just keep breaking down
more and more stuff, building up a crap
load of the things that you're not getting to now. While the validate people,
who knows what they would do? Work on more test harnesses,
I don't know, something. But what they wouldn't be
doing is solving this problem. But in Kanban you're
not allowed to do that. These WIP limits force you
to stop and you notice, you notice right away,
typically same day. If not, at the next stand
up the following day, you notice something's wrong. And when you notice
something's wrong, there's a bunch of things
you can do about it. Obviously, you're
going to talk about it. Why is this stuck? And then you can swarm to it. You can have everyone who now
is idle-- they can't do anything else-- they can swarm
to it and help out, they can break it down, they
can talk to other teams, they can-- obviously
depends on the situation. But you get to just
attack that problem. And again it's a
immediately evident because you can see it on the
board, people are just stuck. That's what you do. Did I answer the question
about tasks too big? Oh good. For open ended tasks
you would just-- I'll just leave it there,
I'm working on answering it. For an open ended task, you just
break down as much as you can, start working on it, it
becomes other things, just add those back
more to the backlog. There's no reason why you
can't use this in research, or really anything else that
follows just kind of a pattern to it. For the open ended
one-- oh, here's something that comes up
fairly frequently actually. Occasionally, we
have features that are so big and complicated that
we can't even do the breakdown. A lot of analysis needs
to go to even to doing the breakdown for them. They're just big
and hairy and yuck. In that case, we take
that sticky for them and we say this is going to
be the design document task. And now instead of
actually implementing it, what we do in
the implement step is we write the design document. And well first in
the breakdown, we break down the design document. First we're going to research
all these different things, we're going to have to talk
to these different people, we're going to come up
with an architecture, then we're going to write
up the design document. So we break it down and then
we move those stickies through. The validate step
becomes reviewing that with the rest of
the team, making sure we didn't miss
anything and what not. And then by the time
the whole thing is done, now we actually have
a fully fleshed out design for that big thing. And now we can actually
do the breakdown. So that's an example of an
open ended sort of thing. Did that answer the open
ended task question? So that's assignment,
so I will talk about assignment in a moment. Was the rest of the
question answered for you? OK. Ah. I'll go here. All right, the Kanban cop
still didn't show up, I'm OK. So let's talk a bit
about assignment. So how do you assign tasks? Well tasks comes up, someone
has finished something. There's an open slot,
the WIP limit is two, but now there's
just one in there. I can fit in
another one, we just pull the next one in
priority order in, ta da. We're set. And who gets assigned to that? The person who's available. And then they just work on it. Typically we put that
person's initials on it so we can keep track
of who's doing what. But that's all there is to it. Now occasionally,
of course, there are tasks that only
certain people can do. Maybe it's doing that
complicated design, maybe it's a particular feature
area that's really tricky and you need some new super
experienced in that area. So what do you do then? You have a few
different options. One, you could
move it into track and wait for that person
to become available. It's blocked, you can't
do anything about it, you're tracking until
that person is available. And then you're getting
all over that person to finish up what they're doing. You could obviously have people
swap what they're working on, of course. My preferred approach
to that situation is to assign it to the
next available person, even though they're
not qualified. The reason why I prefer that is
that I hate having bottlenecks, and I hate being dependent on
a single person for any one particular area of
what we're working on. That's scary to me. It's scary because that
person can get sick, that person could win the
lottery, that person may have a baby, that person's
parents could get ill, who knows. Stuff happens, and if
the success of my team hinges on one individual,
I've got a problem. So I'd much rather assign
it to who's ever available. And then I'll have the
person who's better qualified basically buddy up with them. Now they got their
main assignment, they're not working on
this thing full time, but they're there to do all
the design reviews and code reviews, they're there to
give them advice and so on. And that way I'm going
to bring someone up to speed on it so now
I don't have this area with a single point of failure. Does that answer the
assignment question? She actually had to go. We're good? Still kind of over here. The following question of
this was, what about long term projects? If we are assigning different
tasks to different people all the time, you want some
continuity with those projects. Typically that works out by
itself because in the breakdown you've got this whole stack
of stickies here for that. And usually we
have more than one. I have one here because
it's one person. But often people
just keep peeling off that stack as they finish stuff. So the same person tends
to be on it the whole time. But if the flow of work
is such that things are getting held up
because of one person, we need to be flexible. And we'll get back
to that normality where one person who's
the real expert on is working on all the time
very quickly after that. But we don't want to
hold up our customers, we don't want to
hold up our partners, we don't want to hold up
the whole thing just because of one person. That's not a good place to be. Does that answer the question? All right, let's to how large a
team and let's do large scale. So how large a team can you do? There are documented
cases of people having Kanban serving
a team of 70 people. That's a lot. They need a big room
and a big board. But they do it and their stand
ups are less than 15 minutes. Because their stand ups
aren't about what did you do yesterday? What are you going
to do tomorrow? Because you know,
it's on the board. That's already been
documented, and they've already moved around their stickies. So that doesn't
take up any time. The only time that you
spend in the daily stand up, especially with that large
of group, is talk about issues that we talked about earlier,
where someone's blocked. You focus on the blocking
items, and that's usually a small percentage of the
overall items on the board, so it doesn't take
that long to cover it. However, that's an
awfully big thing I can tell you for the teams
that I've run Kanban with, they've been in the range
of four to 10 people. And I like it that way. There's a lot of
camaraderie on the team, people can cover for
one another easily. Talking about the Kanban
doesn't take very long at all. It's just a nice size. And it's a multi-discipline. These are
multi-disciplinary teams, running through a
bunch of things. You could use it within
the same discipline, and there are teams in Xbox
that are all the same discipline using Kanban, but it doesn't
work quite as nicely, really. It's better, I think,
cross-discipline. In terms of the
number of disciplines, that you can have
using Kanban I've seen five, six different
disciplines using it. I know for my own teams, we
have typically three on any one given team. But I've also seen designers,
obviously testers, things like that. A bunch of different
disciplines. You can have as many steps
as you like, as well. I'm showing you three
steps here, plus a backlog. But you can have as
many steps as you want. Just how you run, it's
very flexible that way. And you can change
the board at any time, because it's stickies and white
board, it's not like in stone. Did that answer the question
for how large a team? All right so how do
you handle large scale? Obviously if you're
running something as big as Windows, or
Windows Phone and Xbox, something of that
scale, you're not going to just have a bunch
of stickies on a board and manage them. Of course not. So there we're going
to do a whole bunch of top down analysis
with the executives, who are going to
determine what is it that the next version of
Windows is going to have. What are the main scenarios
it's going to have? What are the main
differentiation in the market we're going
to have from our competitors and also our previous versions? All that sort of thing. We're going to a ton
of market research, we're going to have
tons of designers, we're going to have a bunch
of business development people, sales,
marketing, the whole bit. They're all going
to get together and they're going
to talk about what are the big themes, what
are the big scenarios we're going to support. Once they do that, at the
same time, the organizations themselves, individual teams
of-- as I was mentioning 4 to 10 people--
they're going to come up with all the cool stuff
that they want to do. Plus all the stuff,
the technical debt they're going to want fixed. So they're going to
bubble all that up as technical opportunity,
and then that gets mixed in at the top with
all of the high level stuff that we're going to do. And then there's meetings
about that and everything else, and you kind of cull
it down per group. Basically at my level
is where it gets culled. For each group, what are they
actually going to focus on? Now you've got a
set of stuff you're going to focus on,
from that-- this is the part of the
scenario you're working on, of these scenarios
you're working on. Here's the technical
debt that got approved that you can go ahead and fix. Or here's the amount
of time that we have that we can dedicate to that. However that looks,
that particular release. And so now we've got a bunch
of stuff we're supposed to do. At that point then we go
through the same thing that I just talked about here. We go ahead and prioritize
our backlog, we order it and everything else,
then we have discussions with the other teams. You know, the other teams
that are dependent upon us, to make sure we're lining up. My favorite way of
doing that is putting it on a huge board that's laid
out in time, in time sequence, and the different teams on
different rows of that board. And you put up your things. You don't need a precise
estimate for this, just kind of what month
things are landing. And then everyone
has a hissy fit and you meet with each
other and all that. And you rearrange
things accordingly, and eventually you get to a
point where everyone's like, OK that seems legit, until the
next horrible thing happens and the whole thing
gets tossed out. And then, now you
have your ordering, you put that onto
your backlog, done. So that's how we do it
at very large scale, and then we'll revisit that
every few months to make sure we're still
on the same page. And of course, we're revisiting
the specific ordering of the backlog every day
as new stuff comes in. But that's basically
how it works. All of that, it's a lot
of work, for something the size of Windows. You know, that often
takes a few months to do. So we don't do it every
month or anything like that. We're doing that big
operation once a year, and then the resetting
maybe once every few months. Excuse me, does that
answer the question? All right, adapting from X
and setting expectations with stakeholders. All right, adapting
from Scrum or waterfall. I say adapting there
very specifically, because, as you can see, it's
not dramatically different. When I had a waterfall
team switchover, the way I described
it to them is that OK we're going to
put the work on a board, and everyone was like oh, OK,
we'll put the work on a board. It's not that crazy thing to do. So we're going to put
the work on the board, we're going to have
these WIP limits, but all we're going
to do is exactly what you're doing before, when you're
doing traditional waterfall thing. We're going to spec
stuff, we're going to implement it, we're
going to test it, just like you did before. The only difference
is we're going to do a small batch at a time,
rather than a whole crud load of things at once, we're going
to do just a few at a time. Otherwise it's the same. Oh, and by the way, we're
going to track it on a board. They were like, oh. OK, and then they do it. And within a week or two,
it's like they've been doing it their whole lives. So it's pretty straightforward. For Scrum, for the Scrum
teams, I said great. I just want you to
put on the board, I want to obey the WIP limits. They already had a board
that they were tracking a lot of the same stuff. So you're going to have
WIP limits from now on, but you can do all the
things you're used to doing. You can do your sprint
planning, and you can do your sprint reviews,
you can do retrospectives, and demos. You can do all that stuff
on the same schedule you were doing before. You don't have to change a
thing, just start keeping it on a board, that's all I want. If you want to drop
any of those things, you can because you don't
need them, but I understand, you're used to Scrum. It's all good. Keep doing them. And they did, they
kept doing them. And slowly but
surely they realized they didn't need to
do them, and so they stopped because they
were wasting their time. So then they slowly
but surely stopped having the sprint
planning and stopped doing all those other
things, and just did the basics here because
that's all that was needed. But it was a very simple
transition for them. And, like I said, it's
more of an adaptation. You're just kind of
adding something in, that's pretty simple,
pretty intuitive. And then using it,
and then slowly but surely you
realize you don't need any of the rest of that stuff. If you like the idea, all this
stuff and all these questions that I've answered
today, as well as the ones that are left
here, I do in fact talk about in the book. I know it's hard to believe,
it's so thin, but in fact I do. There's a
troubleshooting section that talks about-- I
basically modeled it after when you get an
Xbox and you open it up and then there's a quick start
guide and a troubleshooting thing, and then there's
more details online. I basically modeled
the book the same way because I figured people just
want something quick to use. And it's so simple. So thanks very much, and
I'll stay for more questions.
