Here is a complete transcript of my interview with
Jim Benson. If you'd like to check out the
podcasts of the interview you can find them here (
Part 1,
Part 2,
Part 3)
Interview Transcript - Jim Benson November 2014
David : Hi. This is David Prior for Projects for Work, and
I’m very excited to have Jim Benson back for another interview and you’ve been
on the road for quite a while. Isn’t it right?
Jim: It is where I live.
David: So thank you for taking some time out for this. So
we’re going to talk about a couple of things today with the first is about the
newer of your books Why Limit WIP.
Jim: Okay.
David: Right. Can you – I guess before we get in that, for
folks who may not be familiar with the work that you in it and the Modus
Cooperandi, can you explain a little bit about your work and the main focus of
your work?
Jim: Sure. So at Modus Cooperandi we help people and
organizations actually understand the work they’re doing so they can manage it
better. We do this primarily through visualizing work and making sure
that people are working at a level that is not just as a sustainable pace as
agile we’d say but that they’re working actually within their capacity.
So how to measure that capacity, how to understand it, how to figure what
impacts that capacity, so if you want to raise it, you actually have to do
something to raise it and then how to build cultures of continuous curiosity
and improvements. So cultures that noticed when things are wrong or
things could be improved and actually set out to change improve them in a
systemic and humanistic way.
David: Cool. And if people look up Personal Kanban yours is
the first name that they’re going to see as well so you’re also pretty famous
for that.
Jim: Yeah.
David: All right. So you got the new book Why Limit WIP and
what’s – I’ve got a lot of sort of deeper questions about the book but first,
what is WIP?
Jim: Okay, so WIP is Work in Process such as what you are doing
right now. You as a team, an individual, or an organization.
David: And the premise of the book is that we’re all trying to do
so too much at once.
Jim: Exactly. That we’re all overloaded in some way, and
that overload has noticeable, immediate, and deep impacts on quality and the
ability to deliver.
David: Okay.
Jim: And the ability to actually enjoy your work because it –
it’s just bad. It feels bad to be overloaded.
David: So do you – I would say at a work level and on a personal level,
I feel overloaded all the time but I have noticed that to a certain extent,
there’s an addiction to the rush of that feeling overloaded.
Jim: Yeah. I think that there’s there’s that
addiction. There’s also the opposite which is that when we don’t feel
overloaded we feel like we’re not doing enough. So we feel guilty when we
have any leisure time. So basically if we were – if we were all
automobiles, we would feel like we all had to be running at 100 miles an hour
all the time in order to be useful. And I’ve pose that that’s not the
healthiest way to live.
David: So I was – one of the things that I was thinking about when
I was reading to that was I’m wondering if it’s sort of an evolution in how we
deal with things and use our brains. I mean everybody says you need to be
more in the moment, you need to take time out, be reflective and get into
things deeper and I can’t remember the last time I sat down and just listen to
an album and didn’t do anything else to really get into it. But we’re so
focused on this kind of sorting the mail all the time.
Jim: Right.
David: Maybe – is it possible if we’re just processing everything
differently and that this is a permanent thing because of the internet and
everything else?
Jim: Well, the internet has been a wonderful and terrible thing
for human beings. I stop and think about it what it took for my father
when he was an entrepreneur and businessman to get something done versus how
long it takes me to get the same amount of value created. And because of
the internet, because of the immediacy of communication, because of how quickly
I can get somebody – a beautiful and complex document describing an idea, I can
create value much faster than my father or my grandfather. But my father
and my grandfather also used to do things like go fishing. And so there’s
a definite trade off in how we’re living because we have so many options and so
many opportunities that if we don’t seize them, we feel like we failed.
David: Yeah and you mentioned you can create value faster, but we
also consume faster. It’s like we’re eating the food without ever tasting
it anymore. –
Jim : Oh, definitely.
David: So we eat more.
Jim: Definitely. Yes. And my – commensurate to that,
my cost of living right now is ridiculous compared to what my relatives have
been throughout their days.
David: So we’re burning the machine just that much harder.
Jim: Yeah, yeah. Basically we’ve just turned it up to 10
or 11 or –
David: Okay, so this leads me my first question about your
book. So in the book you talked about, the fact that we’re all kind of at
an individual and a company level, everybody is so busy processing that they’re
not getting to a deeper understanding of what’s actually happening. And
like for me, it was like I work in a mail room. I sort mail but I never
take it anywhere.
In the book, you’ve got this guy Jason Hold who – the Willy
Wonka of mansion, who comes and helps kind of cut through this but just saying,
“Stop it. You’re going to do last and you’re going to finish
something.” If I’m a mid-senior level manager and I have read your book
and it’s like the late brooks of the clouds and just lit me up and I totally
get it, how do I deal with this when I go back and then I have to convince
senior management? There’s hundred projects left. Screw that.
Let’s just do three.
Jim: Right, right. And it’s incredibly hard. And so
just to back up a little bit, so the book itself is half business novel and
half discussion of why limiting work in process is if not a silver bullet, at
least a bronze bullet. And being able to have individuals, teams, and
organizations be able to better understand what they’re doing, focus on what on
what they’re doing, and complete it more quickly and with quality.
Because we have so many options right now, we are constantly trying to exercise
all of these options simultaneously.
And so the corporate level without [inaudible 00:06:34] is
way too many projects in a project pipeline. And it’s not – the
frustrating thing and the difficult thing is that all of those projects have
some value, and that’s why somebody wants to do them. So it’s intolerable
to see them there and not be able to act on them. However, what we don’t
know is what the capacity is of our software creation machine that we
employ.
So therefore, since we don’t know its capacity, we just keep
dumping more and more and more work into it and then we’re overloading it but
we’re not understanding why. And a lot of this is because knowledge work
happens in the brain or on a computer, so it’s completely invisible.
Bosses and workers have no idea what the impact of taking a
new task on is because they view that new task in isolation. Oh, I could
do that. But they don’t see that they have a large amount of commitments
already that are going to stop them from doing that. And when you tell
somebody else who comes to you and says, “I have this really great idea,” and
they’re excited and they want to do it you say, “I can’t. I’m too
busy.” That makes you a whiner and that’s not politically
advisable. So you take on the more work even if you do feel like you have
to much work.
So when – the problem is, is it – all these options are very
exciting. They’re very interesting, and they feel very necessary to
somebody who’s growing a company. And if they don’t understand that there
really is a capacity issue, they’re going to keep dumping things into the
process. The problem is that they’re not going to see that by you telling
them that. So you have to be able to show them. You have to be able
to create some kind of visual control that shows how work is flowing through
your system, the rate which it flows, and the impacts of that rate has on the
number of things that you can do at a time.
David: So you’re going to have to start doing experimenting and
tracking key times and things like that and finding a way to show that to
people.
Jim: Yes, but the –
David: Delays that could cost on projects.
Jim: Yes, so you can do cost of delay. You can do through
put analysis. You can even show how the current utilization strategy in
the organization is leading to higher defects because it’s forcing too many
people to do too much work. And you can do that in reports but people
have learned to distrust reports in the written word over the years. And
so basically what they will do is they will take your report, and they will
interpret the report also as a political tool.
David: Okay.
Jim: And they will interpret it by their own confirmation bias.
So they will get the report. They will have an idea what’s really
happening, and they will read your report in that filter. But if you can
build something like a Kanban, it doesn’t have to be a kanban but it can be
something like a Kanban that actually shows over time the impacts of the amount
of work coming in and what is it eventually produce whether that’s leading the
bottlenecks or work starvation or increased defects or incredible delayed cost
or mid-year collisions or integration problems. All of these things are
actually visible if you make a system that shows work flowing. And if
somebody’s watching that, it’s a lot harder for them to argue with it and it’s
more likely to give them an epiphany “Oh, I see this we really can only put so
many of these sticky notes through this columns at a time.”
David: Right.
Jim: And then we see the certain amount, the whole system works
out.
David: So it’s more like providing them with a way of reporting
that doesn’t allow too much room for misinterpretation.
Jim: Exactly.
David: It’s just a straight up. This is what it is.
Jim : Yeah, you want to show them the movie. You don’t want
to tell them what you think.
David: Yeah, okay. So one of the things that you just
brought up was the fact that people are constantly being given more to do, and
this is something I’m maybe more looking for advice on because I ran into this
in classes all the time and people say, “Well, they just keep adding more and
more, and we don’t have a choice. We have to do it.” And I think on
the one end, people get – it feels good to be given a lot and told you’re
important enough that you have to do this. So people have this – I think
it’s like an addiction to it. You want that rush because you feel
stressed, but I want to look at these people at a time and just shake them and
say, “Stop saying yes to stuff you know you can’t do.” They can tell you
to lift a thousand pounds if you know you can’t lift it, it’s irresponsible to
say yes.
Jim: Right.
David: But that’s an empathetic way of responding to a request for
now so –
Jim: Right. What they don’t know is they know they can’t
lift a thousand pounds and they probably know they can’t lift five hundred
pounds. But do they know if they can lift a 125 or a 126 or a 137 pounds?
David: Right.
Jim: So because they – because we don’t know ourselves where the
end of our capacity is, we treat our capacity as infinite just as much as
anybody else does. And one of the other things is even though those
people are complaining about that, let’s say that they’re – each of these people
are complaining about [inaudible 00:12:12] and said, “I’m working on five
projects right now, and it just feels like too much.” And you take out
your project gun and you say, “Which project should I shoot?” They’re
going to say, “Oh my God. Don’t shoot my project.”
David: Right.
Jim: So – because they’ve got – they’ve already sunk part of
themselves into that project. And we do like what we do even if we’re
overworked. And so once we start to build something, we want to see it
get built. And one of the – one project that we had – I talked about this
one a lot actually. It was a – everybody in the company was working on
literally five projects or more, and they were engaging in third-tier support
and they were doing side projects that they weren’t telling anybody else
about. So nothing was getting done.
And of course, because I wanted them to limit their work in
process, I have said, you know what? Why don’t we do where we take each
team and make it a discreet unit and each team is just working on one project
at a time? We’ll shell the other four, and we’ll get to them after we
finish those projects. And two things happened. One is that the
management freaked out. They said you can’t script our portfolio like
that. And they said, well, nothing is getting done. So would you
like to finish something? And then the engineers – the software engineers
themselves completely freaked out because they had all these some costs in each
of the projects.
David: Right.
Jim: So I would say finally each team had a Kanban, so is it
okay if I – here’s what we’re going to do. Your Kanbans look beautiful,
but they’re all lies. And they said, “Yeah, we know they’re all
lies. It’s okay.” So underneath your Kanban, I want you to put a
piece of paper and then just put post-it notes for what you’re working on your
other projects. And so the team started to do that. They had a
Kanban, and then underneath they’re starting to put the post-it notes for what
they were working on and elsewhere. And it looked like a hula
skirt. It was just like wall to wall post.
And so it looked so stupid that everybody just stop and
said, “Okay. We get it. We have to limit our work in
process.” But I tried to tell that to them verbally, and they wouldn’t
buy it. But the moment they saw it visually, –
David: You showed it to them.
Jim: They’re like “Oh crap.” That just looks stupid, and
I’m that.
David: So I had this thing in classes where somebody mentioned
something that I’ve seen happened once where I got an organization to create a
Kanban and exactly what you just described happened. They looked at all
the amount of stuff they had in-progress and the extra stuff. And this
person in my class described the same thing happened to her. That it was
so disturbing and overwhelming to look at that the response was “Yeah, we’re
not doing Kanban.”
Jim: So I love that response, it’s the ostrich with the head in
the sand.
David: Don’t look down, it won’t [inaudible 00:15:26]
Jim: The ostrich looks up, there’s a dog coming. He puts
his head back in the sand. So I’m – this is one of the – this is the
classic dieting problem. I’m feeling weak. You should go
exercise. Yeah, that’ll be – that’s a good idea.
David: Tomorrow. I’ll do it tomorrow.
Jim: Do it tomorrow. In my talk in Frankfurt yesterday, a
day before yesterday. I had a slide that said that human beings took
poison so picture of all of these drugs. And that we drove aggressively,
and then we got certified in things. And so we basically, we always
engage in behavior that’s bad for us. And so what the barrier that you
want to breakthrough is not convincing people that they’re doing too much work
or that you’re giving people too much work to do. It’s the – it’s not
that painful to get to a better place and one of the problems with people who
have been through hard transformations –
David: Right.
Jim: Transformations to wrap or transformations to scram where
you just grab everybody –
David: I was about to say transformation to agile, yeah.
Jim: Yesterday you were doing something and today you are doing
something entirely different.
David: Right.
Jim: It’s the – the whole point of what we want to do with the
Kanban is do exactly what happened to those people. I want you to look at
this, and then I want you to say, “Oh my God. That is ugly.”
David: Right.
Jim: And then you have –
David: What am I going to do about it?
Jim: Yeah. You have three decisions at that point.
You can either run away from it. You can do something from it or to it or
you can basically just freak out. And the problem that you mentioned in
the beginning which is – that your – the people outside your organization are
pushing or your team are pushing work into team. This is one of the
problems that we have engendered by having a team focus over the last 20
years. So we’re focused so much on teams that we removed them from the
rest of the company. And we’ve allowed organizations to say things like
“I don’t get what’s going on in IT.”
David: Right.
Jim: That should be the thing that’s intolerable to us. So
the nice thing about the board is when we put the board up, and we start to
actually use it even if it’s painful and ugly we see what’s happening and other
people see what’s happening.
David: Okay.
Jim: And you can make a decision about it, and your decision can
be – do scrum forever. Your decision can be go back to waterfall.
It can be I would rather build ball bearings. But – or I would rather
slowly and methodically and incrementally create a process that actually works
for my team, which is opposite of what I would like to say.
But one of the things I tell people a lot is we seem to
think that business – you know there’s a saying, “It’s just business.”
Well, saying “It’s just business” is exactly like saying it’s just marriage,
except worst.
So if we think – if it’s hard to go home and communicate
reliably with one person that we love more than anyone else on earth why do we
think we can go to work every day and communicate well with thirty people we
barely care about? So we need to understand that working with other
people is totally necessary and not easy. And the systems that we build
needs to promote communication in the team and outside the team as opposed to
hinder it.
David: So how do you trigger the – I mean the awareness should be
as obviously a positive thing, how can you trigger action? Is there a way
to do that? If I work with people and I know that they can see it, this
is – we have this giant Hollister, this is really bad. But we have to do
it.
Jim: Yeah, yeah and so –
David: Get them pass that.
Jim: Well, so there is one thing – so with that particular
group, when you’ve got 15 teams of people all staring at the same problem and
then you have crazy person like me standing in front of them saying, “You can
fix this, and the fixes are fairly easy.” Conceptually they are difficult
because you’re so – you’re in so much pain because over the years things have
been so poorly managed. But truthfully, all you guys really have to do is
just do a reasonable amount of work at a time and give yourself some breathing
room so that you can understand what you’re doing. You can do it better
and you can complete it. And then we get back to the original thing that
you said which is how do you tell somebody no.
David: Right.
Jim: You shouldn’t have to tell somebody no, but right now you
can’t because you have no tools to tell them no.
David: Okay.
Jim: What you should tell them is I want to continue working
with you, and I love your ideas, and I want to build these things. Now,
where in the queue shall we prioritize this? Is it a new feature?
Is it a project in itself? Is it just a task that I need to get done or
that somebody needs to get done? Is it an emergency? Is it nice to
have? Is it a need to have?
Let’s actually figure out– let’s do some things that we’ve
been afraid to do for several years. Let’s actually prioritize it for
real. Let it interrupt us if it’s – if it’s that important. But
let’s really treat work with the respect that it deserves while we’re also
treating the individuals with the respect that it deserves. So the
beginning of the Agile Manifesto, the first word in that caplet of the Agile
Manifesto is the word “individuals.” But everything we talked about in
Agile is about teams.
David: So having respect for – you said having respect for the
work and the people and trying to be aware and conscious of choices that you’re
making.
Jim: Yeah, yeah. And then also having – funny thing
happens when you put the board up and you visualize everything is happening –
where the works coming from, who’s doing what and when. As a coder, I
will notice that something I coded is stuck in testing and I own a little of
that. That piece of code is a little piece of me. And before it was
just – it would up into some black hole and then after a while someone comes
back and say, “I’ve got a problem with your code.”
David: Right.
Jim: So then you get like my code, you know you must be your
testing and I know what I was doing when I was coding it. But if you see
it, just go over there in the car and just sit. After a while you’re
going to say, “Why is that car just sitting there?” And you go to the
testing people and say, “Hey, do you need help in this?” We’re really
stuck on this. We want to facilitate ownership of the product from cradle
to grave by everyone who’s involved in the product?
David: Okay.
Jim: And if you don’t have that, then you’ll never have the
insights necessary to say no.
David: All right. So they have to all work on it together.
Jim: Uh-huh.
David: Cool. You also talk about utilization, and I’ve been
running into more and more. It seems like recently people are focused on
utilization and a couple of Agile tools are now saying they can help you kind
of level people and make sure they are fully utilized.
Jim: Yeah.
David: I would argue it’s probably not healthy and I would assume
that you would agree that they need some downtime as well but when you talk
about Kanban overload, is there a way to measure that and consider it as a
factor in utilization? So that I could say well, here’s a project that
should take 50% of my available time from an hours’ perspective but mentally,
it’s going to take up this much more.
Jim: Yes, well that’s definitely part of it. So Tonianne,
my co-author, has this story where in Washington, D.C. there was a bunch of
historians and they were sitting around reading and historians actually have
bosses and their boss walks in. Their boss actually was Newt Gingrich,
walked in and looked around and said, “I don’t pay you guys just to sit around
and read.” And then we walks out and they’re like, “What do you pay us to
do?” Because they were thinking right that’s what – that’s what they do
for a living.
And so there is that part of it but the other part of it is
I have spoken at more conferences than I can count and more time -- or have
given a lot of classes and I have never had more than one or two people in
audiences of hundreds raise their hands when I’ve asked the question “Who here
needs more to do?”
So utilization is by no means a problem in suffer
development. The problem is that we have no clarity into what’s actually
being done, how much effort it actually has to take, and what the work is to
actually complete something. So there’s a for years there’s been this one
study that we’ve gone back to that says 83% of all features in software are
rarely or never used.
David: Right.
Jim: And so we say well, we should be better at figuring out
what that 17% are and that’s absolutely true. But, sometimes or all the
time I would actually argue when you’re inventing something new, you need to
build several versions of it and try them out to figure out what the right one
is. And it doesn’t make those options that you’ve discarded waste, and it
doesn’t mean those people are wasting their time or underutilized. It
means that discovery in software development is a major part of my development
process and it’s not just coding testing integration in earliest.
David: Okay.
Jim: So utilization is a very tricky subject because we are
trying to move. Right now, if you walk up to any team and there was a –
imagine on the wall there’s this knob and it says “utilization” and it has no
markers.
David: Okay.
Jim: So just a blank knob on a blank wall. And
somebody says, “Go change utilization for the better.”
David: They’re going to turn it up every time.
Jim: Yeah, you’re going to turn it up or you’re going to turn it
down, but either way you don’t even actually know how much you’re turning it up
or turning it down because you don’t even know the gauge on which the knob has
been set. It’s just a blank knob. So right now, what we’re doing is
we are trying to impact a variable because we are frustrated but not because we
actually have the information that we need to act.
David: Okay. What about the push – I mean even – even in
Agile companies like Agile Consulting Companies, there’s a push at people
booked at a 100% of the time and they say well, if your whole team is working
at over 80% capacity for the entire month or a quarter then you can get a bonus
or whatever but that means that those people never have time to get better.
Jim: Well, and I would argue actually is what that means is
you’ve just created a lot of technical debt. So people don’t – because we
don’t understand the work and because we don’t understand the capacity, we also
don’t understand the impacts of overloading the system. So we don’t
understand at what rate do we start to see dimension returns; where is it that
we start to see additional cost of delay; where is it do we start to see
additional defects and escaped defects; and how often are things coming or used
stories coming back because they’re buggy; how often are we building features
that we never needed in the first place; how often are we building features
that are built like an engineer. We’ve built them but not like a customer
would use. So higher utilization usually means greater number of lines of
code written.
David: Right.
Jim: But greater amount of crop.
David: Well, true. Well, so when I gave a personal comment
recently and somebody thanked me for having a [inaudible 00:28:43] it’s okay to
take naps. And one of the things that – you just got off this big long
trip you’ve been flying for a while. And you are going to need – I’m
assuming you’re going to need some time to recover.
Jim: Yes.
David: Where you’re not doing anything or you’re not doing –
productively contributing to some output because you need to have time to
rebalance from being gone and being on a flight. But people don’t
consider that to be valuable time.
Jim: Right, right. It’s a –
David: How do you deal with that?
Jim: Well, so let’s say – let’s say that for a moment that you
are a smart phone. And somebody talks to you until you have 1% percent of
battery left, and then you say, “Hey, I’m a smart phone and I need to be
charged.” And somebody says while you’re being charged, that’s not
productive time.
David: Right.
Jim: And so it’s like, no, I am the most wonderful and most
complex machine on the planet. But I’m still – I still need to eat.
I still need to sleep, and I still need to go to concerts and to look at sky
from time to time.
David: Right.
Jim: And we need to recognize that the this is the thing is that
because our work is knowledge work and it’s highly creative, and we’re using
the most resource intensive part of our body because our brain burns a lot of
calories. So when we’re thinking, we’re working pretty hard. It’s
people say you’re just sitting around all day but you are burning just as much
calorie –
David: [inaudible 00:30:23] telling me I’m sitting around all day
and you just figure out of the wire into my head.
Jim: Right. Well, so that’s another part of balance right
is the – as organisms, we actually do need to get around, get up and walk
around. We need to walk up and down some stairs. We need to eat a
certain amount of fruits and vegetables and grains and meats. And if we
don’t do these things, then we’re going to create crappier and crappier
code. And –
David: But we’ll have more of it.
Jim: Yeah, [inaudible 00:30:55] that’s why we will have more of
it. But the thing is for a brief beautiful period of time there, we
didn’t have a lot of bandwidth and phones were pretty stupid. So we were
back in – back where – all of a sudden we’ve reverted back into this kind of
glorious age that we were at when we had Apple tools and [inaudible 00:31:18],
where we had like 16K and you couldn’t do very much.
Now, unfortunately, we’re backed-up to where we can bloat
our phones and we can bloat the internet just like we bloated desktop
applications in the ‘80s and the ‘90s. Success went up a par. But I
– so we can’t limit our WIP by – the technology won’t let us limit our WIP that
way anymore.
David: So we have to become mature about what we’re doing somehow.
Jim: We do but mostly what we have to do is realize that our
attempt at optimization of utilization is actually a direct de-optimization of
the people who are actually doing the work. And you can’t just optimize
part of a system. So when you are creating software, you have the human,
their body. You have the human, their brain. The human, their
psyche and you have their time and their energy and blah, blah, blah, blah,
blah. So right now, we’re just optimizing for time that is a highly local
optimization of an incredibly brittle system that will not function with that
focus – with that optimizational focus.
David: Cool. So there’s – I mean I guess people are looking
at it from a very simplistic standpoint instead a more healthy holistic way of
understanding what actually takes to get viable stuff done.
Jim: Exactly. And I mean it’s – because one of the hardest
things about this is I – even just with the word holistic is that when you
start to take a systems thinking approach to knowledge work and then you start
to have to deal with the soft sides of things that people are uncomfortable
with – being polite, having empathy. Understanding that if somebody
doesn’t go home for five days to visit their daughter, they’re going to become
a real pain in the ass. That starts to feel mushy and granolaee and
crunchy. And that’s the real danger here is that there’s nothing but hard
science behind this but the elucidation of it sounds very haggy. So –
David: I think – I think the hard part is it makes total sense but
it runs counter to what people have grown up thinking from the idea of
everybody works in a factory all day.
Jim: Yeah –
David: [inaudible 00:33:43] the machine.
Jim: And it’s very anti-calvinistic and we still live especially
in the US but even in Europe and in some ways, Asia’s even worse. We live
in a very Calivinistic society where there is work to be done and you got to
get out and do it. And the problem is there used to be work that you had
to get out and do because if you didn’t repair that fence, all of the cows
would leave. But now it’s you have to get out and do this 45 projects
because I thought of them.
David: Right.
Jim: And it’s like –
David: And that makes some valuable because you they were in your
thought.
Jim: Exactly. And so we have to realize that just as you
couldn’t send your son out in 1920 to build 17 fences in one day. You
also can’t have somebody go out and write 6,000 lines of code every single day.
David: Cool. All right. So the book is called Why
Limit WIP. You can get it at Amazon, and if you’re subscribing to
that new unlimited Kindle thing, it’s even free.
Jim: Yeah, yes it is.
David: Cool. So I want to ask you about the school and the
new stuff you have gone on because that’s pretty exciting as well.
Jim: Oh you bet. So really quickly, we are in the process
of preparing for a launch of something called Modus Institute and it’s at
modusinstitute.com. At least it’s flash pages now. And we are
building an online school that will be teaching next generation project
management techniques. We’ve gathered together 30 of the best sought
leaders and practitioners and lean software development and modern or I guess
whatever we are calling management today. There’s no word for it
yet.
And this is an online school that has a learning – your own
pace model but it also has direct access to instructors and peers. So we
not only want to build a school where you go and look at videos, which is what
all the other schools have but we also want to build a strong community of
practice. So when people learn about Kanban or they take a class and try
to get in it and they learn about Monte Carlo simulations or metrics or from
Dave Gray learning about the different ways to visualize and brainstorm.
That after they learn those techniques and they start to implement them, they
can have – you can have conversations with peers and with the instructors.
So you’re not just hung out to dry. It’s like a real
university online. And our first class is on managing successful
distributed teams and that will be ready in the beginning of January. So
we’re going to launch in Q1 of 2015, and we’re really looking forward to it.
David: Cool. I think it’s great. I mean that people
that you’ve got to involved I’m psyched about them. I’m hoping at some
point, there’s going to be something metrics-related because you’ve got some of
the stuff Troy is doing is really awesome and Dave as well.
Jim: Yeah. So Troy and Dave [inaudible 00:37:03]. So
that’s one of the things. I mean we just mentioned that there’s the soft
side of better management, and there’s also the hard side. There are real
metrics and by real, I mean actually real metrics that measure how a team is
doing, how an individual is doing, and allows not only them to improve but
allows you to make projections and do away with estimates and move right into
actual statistical probabilistic forecasting. So it’s a – hopefully the
workplace of the future is a place for people actually enjoy going to work and
they get a ridiculous amount done because they’re not doing the wrong things.
David: Well and with this I think also the people – your people –
the people will have access to the instructors one-on-one.
Jim: You bet.
David: That’s great. All right. So this is going to
come out in January. I’ll put up a link to the institute as well.
But when this – when it does go out, I would love a chance to talk to you guys
about it again.
Jim: Oh, absolutely. That would be fun.
David: Cool. All right. So thank you very much.
I hope you get to recover from the travel a little bit, and I hope everybody’s
going to go pick up the Why Limit WIP book and also Why Plans Fail as well.
Jim: Indeed.
David: Because both were helpful. Cool. All right,
Jim, thanks a lot. Really appreciate it.
Jim: Thanks, Dave.
David: Cool.
