Interview with Al Shalloway of Net Objectives

Alan Shalloway is a prolific author and founder and CEO of Net Objectives. I first met Al while living and working in Seattle, and would frequently see him at different conferences and gatherings.

Since this interview was recorded, there has been an interesting debate of the Scaled Agile Framework (SAFe). In order to better understand the SAFe framework, well known and respect Scrum Trainer Ron Jeffries attended a SAFe training course. Ron Jeffries wrote about his experience in this blog post. Although Ron has his reservations with SAFe, his respect for Alan is quite clear:

His Agile values and approaches are quite good. That meant that his sections of the lectures, and his answers about what he’d do in real cases, shifted the balance from what I believe we’d have gotten from the other instructor alone.

Al responded with a well reasoned and thoughtful reply.

… I do not agree the best way to achieve scale is always by getting the teams working well. As with most things, an approach depends upon the situation you are in. If the types of projects you are working on don’t require teams of more than 30-50 folks, I’d probably take Ron’s approach, because SAFe is likely too big for them. But many projects are too big or complex to unwind. In this case, looking at the big picture and getting teams to deliver in 2-week cycles may be the right approach.

I would encourage you to read both articles articles in their entirety. Alan’s latest blog post can be found here, and you can connect with Al on Twitter at @alshalloway.

This is a short interview, because I goofed and stopped recording after about 30 minutes. Even though the recording ends abruptly, I thought the start of the interview very interesting and worth sharing. Here it is:

Transcript

[music]

Interviewer: Let me, very briefly give your background about what I was
trying to do. Maybe a couple of years ago, I felt like I was losing touch
with the people in the Scrum community. My wife and I, we moved out here to
Australia about four years ago. And Australia is a long way from anywhere.
And I felt like, I was starting to lose touch with people, and there were
new people coming into the community that have not met and were people that
I had not seen for a long time, such as yourself. And so, what I wanted to
do was, I wanted to find an excuse to reach out and talk to people.

Al: And that is cool.

Interviewer: Yeah, and I am of these people that needs an excuse to do
things. So the excuse that I created for myself was, that I would do
interviews and I would do interviews to ask people, about how they came
into the Scrum community. Just to chat about, where they came from.

Al: Okay, and in my case may be, how I got out of the Scrum community. I
guess am still in it, just not in the Scrum Alliance community.

Interviewer: Yeah if you are willing to talk about it. Personally, I
would be really interested to hear about that story. I do not know the full
details, I know some of it, but I would love to hear about the full
details.

Al: I got in really early and if you are recording now that is fine, I am
cool if you are.

Interviewer: Yup, yup.

Al: That is fine, yeah. So I got in really early, I do not remember
exactly when. But I was doing Agile, well I knew that is what I was doing
because I think I was doing it beforehand, and did not even know that is
what it was called. But as early as 99, when I heard Martin Fowler talk
about extreme programming. I thought “Wow, this is cool stuff.” And by 2000-
2001, we were doing Scrum. I do not know when Ken’s book came out, but
whatever year it came out, I read it. I was at all the early Scrum
gatherings. Actually, we sponsored one of the early ones when. Like I
remember one of the gatherings we went to, there were like 50 people, that
might have been the first one. And the first two or three or four years, I
was really avid about Scrum because at that time, there was no good way to
explain, why doing things in this steps make any sense. I mean intuitively,
I had been doing it for a while. But from a business point of view, it was
difficult to explain. And Ken was really good at explaining.. And I thought
wow, this is really cool. This adjusting and responding and building small
pieces, and this discipline. Agile and Scrum were at that point, not quite
synonymous, but iterations.

I remember, I would describe Agile as iterative, incremental and
integrated. That if you are doing those three things, that was the essence
of
it. And Agile and iterations, these were sprints, to use the Scrum
terms, they were connected. The thought of what Kanban and flow is now,
that just never occurred to me or anybody else I think. So I was actually
really into the Scrum community. We had a lot of CST’s, like other people
did. I never became a CST because basically, I was doing other things, and
I was the CEO of Net objectives, still am. And being a CST seemed to be,
not where I should be focusing because then, there was a very limited
number of CST’s in those days, it was very difficult to become a CST in
your company.

And basically, but I had a couple. We did a lot of Scrum training. I
did other kinds of Agile training. And this went on for about three or four
years until 2004-2005, when two things started bothering me. One was, we
kept running into organizations where Scrum would not work, and it would
not work for any number of reasons. And one of the reasons was, if it was
big, there was no way to create a common vision to get people to work
together. And as Scrum as Scrum, we never could figure out how to get that
to work. In fact, we never did, we did other things right from the very
beginning. I go back to my early writings, and we talked about, I cannot
remember what we called it, but it was some group, that now is actually
kind of, you could think of it as a separate group of product owners,
talking to each other. But I forget what we called it back then. But it was
the early stages of some, high-level contextual view of, how to manage
multiple teams of multiple projects, working together.

So one thing was, this lack of vision, to create, for people to come
together. And the other problem was, there were times when Scrum as a team
method framework, would not work. Iterations were just not the right
approach. Having cross functional teams, were not the right approach. And
all I would ever hear was, “No Scrum will always work, you just have to
follow it.” And I am like, “Well, that does not make any sense. There are
times you do not want to follow it. There are times when you have key
people and you cannot get somebody with the experience you need, on every
team. Then what you do?” And nobody was listening to me. It was very
frustrating. And what started happening is, I started bringing the notion
of
Lean in because I started seeing that Lean could create the bigger
vision. I did not know how to solve this problem with key men or key women
or whatever. But there were some things about Lean that seemed very
appealing. And I started talking about it in the community, and it was
really bizarre because, when I was talking about it in the community, I
would get a positive response. But I would be with Scrum folks, but if I
were talking about it openly, I was slapped on the wrist all the time. And
eventually that led to me being thrown off the Scrum development group
because it could not slow me down because Ken did not like me talking about
it.

So that was a piece of it. The other piece of it is, I really still
do not like the way the SCRUM certifies trainers, because what happens is,
companies make investments, get a CST and then the CST leaves. I thought,
that was a bad business model. I told Ken, that was a bad business model.
The moment he came up with a CST program I said, “This is not a good model
because, it serves the individual, it does not serve the organization.” And
then every year you would see people getting CST and then leaving the
company, setting up their own shingle. And I just personally did not like
it, even though everybody was making a lot of money out of it, it did not
seem right. So those two factors really had me decide, “Well, I got my
hands tied when I am in this community, so I am going to go elsewhere.” It
did not change my opinion to Scrum. I think Scrum is a really good
framework, for teams to work in. We do a lot of Scrum. We teach Scrum all
the time. We do safe silver partners, and it’s based on Scrum. But I do not
like the way it was being organized to expand, and that is basically why I
left.

Now I admittedly, I might have left in a calmer way or, might not
have did something, I am maturing. But that was my main thing you know, it
was not Scrum itself. So, I also got to say, I really like what Ken did
was, Scrum.org. We had been talking for years, that you needed to do team
training and not certified Scrum Master training and when he started doing
that I said, “Good for you, that is what you should have been doing for
years.” I had been talking about that as well to no avail. So I think there
were certain resurgence of technical practices into Scrum and it is a team
training now, instead of a Scrum Master training, is really important.
Because if you think about it, if you have only got two days to do
training, if you spend any time on how does a Scrum Master be, that is time
less, for, how does the team be. So, if you want to be, if you want to do a
three-day training, that explains all the Scrum Master role and all the
team role, that is cool. But most people do not have that kind of money or
time. So I think, Scrum.org actually is moving in the right direction, with
how they are going. They are also going through the rep approach, where you
have materials and people get sort of being able to do that. So, I guess
Ken’s learned some of his lessons, because I am not interested in working
with Scrum.org, but I have got to say, but I like the model. It is a whole
lot better, than what I saw, when I was with the Scrum Alliance, and then
broke off.

Now the other thing we have done and it is funny because I have been
accused of liking one thing or promoting one thing. And what is ridiculous
about that, is I am the only guy who does everything. I mean think about
it. I do Scrum, I do Kanban, I do XP. I used to be an accredited LKU
instructor with the Kanban method. I still do the Kanban method. It is just
one tool I have in my toolbox. I’m the only guy carrying around six tools,
when everybody else’s got two or three. And they think they have a variety.
So my thinking actually, the big umbrella for me is Lean. Lean is kind of
mindset and a framework. And it is based on just a few key principles that,
I guess the essence of Lean for me goes back or the foundation, not the
essence. There is a difference, on what it is built on, goes back to
something that I have been doing for, 30 years and that is Deming [sp].

Look to systems, trust that people are basically good, and if you put
them in a good environment, they will do good work. If you put them in a
bad environment, you will suppress them and they will not get good work
done. And that, you do not need to, try to cajole [sp] them to do good
because they naturally want to do good. But you have got to remove what is
in their way. And that takes improving the system, but it also takes good
management. It is not something that people by themselves can do because in
a big organization, there are lot of impediments that the individuals
cannot do. But create the right environment, then let them do well, self
organize within that environment. And then Lean, builds on that foundation,
by adding the notion of, do not stop the workflow. When you start work,
keep it going until it is delivered. Well the only way you can do that is,
if you have got small batches. So, Lean talks about just in times, small
batches. It actually talks a lot about testing, which most people I do not
think, realize. Because most of the books that I read about Lean, do not
talk about testing.

But if you go back to [inaudible 00:10:51] book, the production
system, he talks about this thing called autonomation. And he means
automation with a human touch. And of course, manufacturing is a lot
different from software, so do not try to do this in software, what they do
in manufacturing. But take the essence of it. The essence of it is, things
should run well, and when they do not, then you stop and figure out what it
is, get it to run well again and then you continue to skim through the
system, once something goes wrong. But you should not be testing things in,
and you should not be having to manage the process, it should flow
smoothly, as you do things. Excuse me, just allergies.

Interviewer: It is all good.

Al: So, the more I study Lean and the more I talk to different people,
outside of the core Lean community, a lot of things fit into it. Like Bob
Charette actually, I did not know this, but he actually was the one who
coined the term Lean software development. He wrote a paper, I think it was
in the 90’s.

Interviewer: Oh, really?

Al: Yeah, Mary and Tom did not coin the term, even though they are the
ones who get all the credit for it. Charette wrote, and I do not remember
what year it was, it could have been, as early as 89, but it was definitely
no later than ’99. I think it was a late 80’s. He wrote an article called
Lean software development, and I did not know who Bob was, until about five
years ago, at the first Lean Kanban conference. He was there, not was the
second one, it was the whatever was after Miami. It was that one and he was
there. And he told me this, and I was talking to him. He is a risk viewer,
this guy is just amazingly smart. Probably, the number one risk guy in the
country or the world. And he was telling me about this. And he tied that
notion together. And if you start studying, if you start taking the
principles, the foundation I should say, these principles from Lean and
Deming and apply them to software, then the practice will show up
differently. But basically, the ideas work on a small value pieces, as you
can, and make sense from a deployment point of view. And do not work on too
many things, so you have to stop work.

I love David Anderson’s phrase, “Stop starting and start finishing.”
I actually came up with myself just the other day. It just hit me,
finishing, it is “Stop stopping.” Do you know what I mean? You are working
and then like, you stop. And you stop because you need somebody else or
just because you do not know something or you stop because the bug happens
and the testers are not there or whatever it is. You have a stoppage in the
workflow and that is bad. So it is like, stop stopping, how do you set it
up so you do not have to stop, so you do not have to keep stopping. And
these mantras really guide you, no matter where you are. Then Scrum, if you
view it as part of the Lean world, becomes a lot better because you can see
how to extend it. And I am happy to say that the Scrum community is finally
acknowledging it’s a manifestation of Lean. I have to admit, I still get a
little irritated, I get less and less as time goes on because I am maturing
a little bit. But I get a little less irritated every year that, back six
years ago, when I was saying this, I was told, “No it is not. No, it has
nothing to do with Lean and all that.” But it is at least good now that it
is being said that it is Lean. It is a partial implementation of Lean
thinking and it is quite good. And when you actually acknowledge that and
see that, then when it does not quite work, you can use Lean thinking to
get you to the next level. That is why, I am not trying to say Scrum is a
part of Lean or kind of Lean, so you will do Lean. I think, that is how you
can enhance Scrum. In fact, I am doing a webinar in about four weeks, on
enhancing Scrum with Lean. Because then when you get stuck, you can say,
“Why do I have iterations?” And there are a variety of objectives, there
are
reasons you have iterations.

When I am having trouble doing this one, maybe instead of just not
doing it, instead of don’t do Scrum but, I am going to look at, what is the
intention and how can I use Lean to get a better intention. There are two
kinds of Scrum buts in a sense. One is, “Well, we are doing some Scrum, but
it is too hard to do it this way, so we are going to, we are not doing
that.” And that is an accommodation, and that is virtually never good. Or
it could be well. “We are doing Scrum, but we cannot have fully cross
functional teams because one guy is needed for three teams.” So what we
have done is we have setup a Kanban work for this person, so we can be
sure, he crosses the three teams. So you know, that is good Scrum work
because you are getting the intention of it. So, that is kind of my
approach, is I am always trying to figure out what works, and then pull
from, whatever mindset there is. But if you just pulled from the mindset in
principles, it gets too theoretical. I mean, I am good with that, but most
tell me what to do. I need to know what to do.

Interviewer: Something practical, something.

Al: So then, yeah exactly. So that you want to, “Well, here you use this
part of Scrum or you use that part of Kanban”, but it is really, you are
just solving the problem-based on the laws of nature, of software
development, as a phenomena. Anyway, that is kind of what I do.

Interviewer: So you mentioned briefly through that, you mentioned
talking about using Scrum within Lean or I cannot remember the exact words.

Al: Yeah, within the context of Lean.

Interviewer: Within the context of Lean, yeah.

Al: So think about this. So one of the biggest problems people have with
scaling Scrum, is the inside the team, it works well. But across teams, it
has difficulties. So how do you solve that problem? Well, Scrum of Scrums
has been attempted.

Interviewer: Not terribly successful in my experience.

Al: Yeah, I have a standing request for anybody in the community to give
me one success of Scrum of Scrum working. And so far, I have got none.
Nobody has come to me. So it is like, just stop talking about it please
because if it does work, tell me and if it does not work, let’s stop
talking about it. But the reason it does not work, is inter-team dynamics
are quite different than intra-team dynamics, when it comes to decision
making. See, Scrum of Scrum works really well, when it comes to
communication. That is fine because then, you are just letting people know
and it is not a bad method. So, how would you coordinate teams? Well, does
not mean you do not do Scrum? Does it mean you have to do command and
control and a high big view, and the answer is no, of course not. You have
to use Lean at the high-level, to manage workflow. So you say, “What is the
biggest, what is the business increment we’re trying to deliver?” Think of
it from a corporate point of view, deliver value quickly. Now, how do I get
my teams to deliver value quickly? Well, maybe if I need to break the work
up, I need to break it up into way that teams can work together, so they
are working on the same things at the same time. Because if their working
on unrelated things, like in the first sprint, and then they work on
unrelated things in the second sprint, you cannot integrate, you cannot
test, if you have got it working.

These are all the dependent things, “First we are going to do that,
then we are going to do the next sprint, that are related to each other.”
Then you are shortening the time, you are cutting out the delay between
building something and then, validating it. So if you say, you want me to
use Lean to make sure that my workflow is quick. I get something started
and done, started and done, then I can now do Scrum within that context,
that is what I mean by doing it within the context of lean. I also mean,
recognize that the reason Scrum works in my opinion, is not so much that
you have self organizing cross functional teams, but by having cross
functional teams. You basically cut out a lot of the amount of work in
process you have, and a lot of delays you have, inherently. Well if you
recognize that, then when you have a backlog for the Sprint, what you will
want to do is, even if you are not managing work in process, you will still
say, “I want to have as few stories open as possible” because it is Lean
concept. Then I will do things just in time, instead of all at once. So I
am doing Scrum, but I am doing it within these kind of rules and things
like that. That actually helps a lot.

There was one thing that crossed my mind, I was talking to you, just
to kind of float it through, but it was just as good a concept. To explain
this about Scrum within Lean, but I guess hopefully it will come back. That
happens to me, at times. If I said everything that was on my mind, you
would have about three conversations going on at once. Sometimes something
goes through there, and I can’t say it, I cannot remember what I said.

Interviewer: Happens to all of us.

Al: Yeah, well you see the other thing about this is then, if you think
about it, if you do Scrum or if you do Kanban, you can mix those two
together, as long as they are within the bigger picture of concept, context
that you are working on. So that is what is really good. So in a lot of
ways, the intention becomes, does not matter if you call it Scrum or
whether you call and Lean or whether you call it Kanban, the real question
is, why are you doing it. And the labeling is, just so you can talk about
it like a process pattern. So to me, Scrum is a process pattern. Kanban is
a process pattern, Kanban method is a process pattern and XP is a process
pattern. But that assumes, you are coming from the perspective that in
fact, there are laws of nature, of software development out there. Not
everybody agrees with this by the way. This is where Ken and I would
disagree, if we ever talked about it. We have never had that option. There
are many in the Scrum community, that do not believe, you can talk about
workflows and value streams, without causing a lot of problems. I
personally think you can, because I have seen it, I have done it, it helps.
But there are a lot of people that think you become mechanistic if you do
that. And it is possible, to become mechanistic.

I think Kanban method can become mechanistic. I have written about it
in a blog I call framework myopia, where, if you focus on one thing, then
you tend to ignore other things.

Interviewer: That is right, yeah.

Al: And our whole physiology, I usually do not try to study psychology.
Actually I study psychology and physiology a lot because, just as a hobby.
I think it is really fascinating stuff. I got a background in psychology, I
have always been interested in psychology but. It is interesting, if you
study it, you will notice, the body, the brain, our whole physiology, our
whole cognition, is geared around focusing on one thing. We are designed as
beings, to focus on one thing. And we have some sensors that give us
peripheral vision and things like that, but in fact when you notice, if we
are in a fight or flight response, things just gel down to what we are
afraid of, we give our full attention to that. So the danger in software
development in my mind, is when you start focusing on one thing. And you do
not notice the other things. You just do not even see them. It is not like
to see them and discount them, they would never show up in your cognition,
in your consciousness. And that is what I meant by myopia. Because myopic
people, they see something, but it is very limited and they cannot see
around it. And we are kind of becoming that way.

So, that is my latest rant, is I’m trying to get people. How do you
see what you need, and then how do you learn how to see what you need next?
And this is something that neither Scrum nor the Kanban method talk about.
Scrum just as we’ll start removing impediments, but they do not tell you
how or what. Kanban method says, work in process and you will figure it
out. Okay great, but why should I? Because you are smart and we respect
people. And I am saying, well if you respect me, you would not make me
reinvent the wheel. See that is another difference in attitude. I respect
people, I do not want them to waste their time figuring out what other
people have figured out. To me, that is wasting their time. So there are
differences and those differences are actually, it is not the difference in
Scrum or Kanban or Lean. It is the difference in those mindsets, how do you
help people, how do you learn, how many things do you focus on? Are there
rules to software? What are those rules? Those are the differences.

Interviewer: And so you mentioned, just briefly about rules of
software. That software has natural rules. Could you expand on that a
little bit? Because that is kind of interesting.

Al: Yeah, there are not a lot of them, but there are a few that are
reaching. So one is, if you start work and then stop it, and then you pick
it up later, that will cause more work to be done. And people call this
task switching, and it is not. You test switch every morning, you go from
seeping to waking. So if I work on something Monday, and then I put it
aside and I pick it up on Tuesday, task wise. If I stop working on
something Monday, and I pick up something else on Tuesday, I task switch.
If I work on one thing a day, that is minimal task switching. But if I work
on project a on Mondays, and then I work on project B on Tuesday and then
project C on Wednesday and I come back to A on Thursday, I will not be as
efficient, as if I work on A Monday and Tuesday and Wednesday, until I
finish it. It has to do with short-term versus long-term memory. And it
creates additional work for two reasons.

One is, I do not remember where I was, but what is worse, someone
else might have been in my code or somebody else might have changed the
requirement and I cannot get the response I want, fast. So that is a rule
of software, that if you delay the work flow, where it is not in your
advantage to do so. I mean sometimes, “Oh my brain is fried, I have got to
set this down.” Okay, and that is good. But I am talking about
interruption, talking about, I am working on something, I stopped, I go do
something else, I am not coming back to it, that will cost me time. If
requirements age, if I get some requirements today, three months from now,
they are not as good. That is not your opinion, that is not my opinion,
that is just the way it is, those are the things I am talking about. If I
work on really, really big things, in parallel with each other, it will not
work as well as, if I get something done and finish it.

The Agile community and the Agile manifesto refers to some of these
things. But it does not make it clear and explicit enough. For the example,
finished code is a better measure than have I got some artifact in front of
me. Yeah, it is not my opinion it is not your opinion, it is just the way
it is. That is what I mean when I say, it is not our opinion about it. We
have nothing to say about it. You can like or dislike gravity, but it is
still gravity. How you talk about it, might make you more effective in
dealing with gravity. But whatever phenomenon is out there, it will pull on
your, regardless of what your opinion about it is. So there are things like
that in software, that a lot of people are actually denying. They are
saying, “Well it is complex.” And I am not using complex in the Cynefin
model or even, they are not exactly consistent. Cynefin or [inaudible
00:26:01] talks about it being, “You cannot get cause and effect.” And the
answer is, it is actually not what it means. It is not what complexity
means. There are patterns to complex things, and you can get some cause and
effect, you just do not get exact predictability. I can guarantee you, if I
go into a movie theater and scream fire or scream bomb, or shoot a couple
of shots in the air, I am pretty sure, they are going to leave, and
screaming and yelling is going to happen to.

What exits they go to, I cannot predict that. But there are certain
patterns of behavior, you can definitely predict. So, even complex systems,
there are rules. The cause and effect may not be totally clear, but that
does not mean there is nothing. It just means we do not necessarily
understand it, but we can sometimes see big pictures of things. So this is
an area, that people have pretty much ignored, not everybody. Don
[inaudible 00:26:56] book, I have not read it. Principles of lean product
development flow, this is like a bible of software engineering. It is just
an amazing tone, definitely read it. It is Don [inaudible 00:27:08],
principles of. It is [00:27:11] book. I thing it is, principles of Lean
product development.

Interviewer: I will look it up, I will look it up on Amazon post it to
the community.

Al: Yeah, it is not an easy read, I will warn you. Principles of product
development flow, second generation Lean product development. But it is
brilliant, it is a brilliant book. Lots of equations, lots of graphs and
stuff. But it is not hard to read, I think is very clear, but you have to
read it carefully.

Interviewer: You have got to give it your full attention?

Al: Yeah, it is not something you. You have got to give it your full
attention. But if you give it your full attention, then you will understand
it. It is very well written. Whereas I have read some books like, the Gang
of four book, when I first read that, I was like, I was giving it my full
attention and I was hitting a brick wall. But six months later, I got this
insight, that broke that the whole thing open for me. But I read that for
months saying, “I know that there is some good stuff in here because I can
smell it, but I do not see it yet.” That was an interesting, that was a
design patterns book. That was a book that was really up to, has
brilliance. Then when you break the code, it becomes, “Oh my goodness, this
is such an amazing book.” But it was very difficult to get to that point.

Interviewer: So just taking a quick step back, just to trace through
your path, through Scrum and through Lean as well. You mentioned right at
the very start, you were introduced to extreme programming by Martin
Fowler, and then you moved into the Scrum community. At what point were you
thinking heavily on Lean? Because I seem to remember that we chatted at
Amazon on, in 2008 and you were already starting to think quite heavily in
the Lean fashion.

Al: It was about 2004-2005, that I started getting into Lean in a big
way.

Interviewer: So that was quite early on actually?

Al: Oh yeah, yeah. Because the basics of Lean, I had in 83. I used to
study Deming, back in 84. It was actually 84. So when Mary, I met Mary
before the book came out. She was also in the Scrum community and we
chatted a lot, back then. So I made the connection with her back in 2002-
2003, heavy in 2004. And so Lean made immediate sense to me. It was like,
“Wow, this just explains a whole bunch of stuff.” And I could never get Ken
interested in going down that path. And every time I would talk to him, he
would say he was interested, and then when it actually came time to action,
it was always well, “No, I am doing my thing.” We never could agree. And
then, for a year or two, I was like, “Man, I really hope the Scrum
community will absorb Lean and move in this direction.” But since nobody
was interested, then after a couple of years I started thinking, “Well I am
going to talk about this. I am talking about it inside the community and
nobody else is doing anything about it.” So apparently, it was okay to talk
about it inside the community. But once I started talking about it outside
the community, people did not appreciate that. Because they could not
control it, I guess.

So when we started in 2008, I had already been doing Lean for a few
years. My problem and it was right about that time that it started shifting
for me. My problem was, I just had Lean as a theoretical framework, that I
could sometimes intuit solutions out of. And I did, there were some things
that we did, that were really cool, really remarkable. And when I look back
on it, I recognize, I was managing flow well, and a variety of things like
that. But it was not until I started doing Kanban, which was right around
2008, that I started having a set of practices, that would implement these
principles. Then I understood the principles, but I did not understand, how
you would actually manifest it. On hindsight it is like, wow, I do not
quite see how I missed it, but I did. So I have David to thank for that
because he made it really clear. Actually, he did not invent Kanban, but he
was the one who promoted it. There were a couple of hundred people like
Orbis and Microsoft, who invented it. But you know, the same way that Ken
did not invent Scrum, Jeff did. Ken formalized it and so, around 2008-2009,
all of a sudden I had a way to make Lean work, from a practical point of
view.

And at that point though, I did not truly appreciate the importance
of teams. So I kind of went from heavy Scrum to heavy Lean. And then I do
not know, couple of years ago, I went back to, more mid-range. Believing,
teams are great, always try to get to them if you can. And jump as far as
you can, but you do not over jump. So, the Kanban method rather, of always
doing incremental improvement makes sense, if that is all you can do. But
it does not make sense if you can actually rearrange workflow, use minimum
business increments or whatever. And this is where David and I started
splitting up to some level, as I started talking about. “Well the Lean
method is great, but it is just one of many things.” And he did not want to
hear that. So, basically what happened to me… [voice stops abruptly]

[music]

Comments are closed.