How Lean, Six Sigma and Agile all work under the same umbrella at xerox

Business901 Podcast Transcription
Implementing Lean Marketing Systems

How Lean, Six Sigma and Agile all work under
the same umbrella at Xerox
Guest was Patrick Waara of Xerox Corporation

Related Podcast: Adding Value in Development

Adding Value in Development
Copyright Business901


Pat has been with Xerox for nearly 25
years. He has both a BS and an MS in
computer science from Michigan
Technological University. He has held a
variety of jobs at Xerox, including
developing user interface systems for
Xerox's DocuTech and Systems Architect
for Xerox's iGen3, all dealing
with software development and systems.
Pat also works at St. Joseph's
Neighborhood Center, which provides
medical, counseling, dental, and social
services to the uninsured, where he
utilizes his software and Lean Six Sigma
skills to support their IT and process
infrastructure that he installed during a Xerox sponsored leave of
absence. He is currently a Software Design for Lean Six Sigma
Master Black Belt Candidate and a Lean Six Sigma Black Belt
Candidate where he is teaching Lean, Six Sigma, and Agile
techniques to Xerox's software development community
improving software development capability.


Joe Dager: Welcome everyone. This is Joe Dager, the host of
the Business901 podcast. With me today is Patrick Waara, who is
a Six Sigma black belt candidate at Xerox, and also handles
teaching the software design and Agile methods for the Lean Six
Sigma candidates. Patrick, could you go ahead and explain your
position in a little more detail.

Patrick Waara: I am a software design for Lean, Six Sigma
Master Black Belt candidate. And what that means is I am
teaching software or software engineers agile and lean software
development techniques. I do teaching and coaching here within
Xerox, trying to improve our software development techniques
and utilizing agile and lean techniques to do that. In parallel to
that, I am also getting my traditional Lean Six Sigma black belt.
But, I primarily focus my time working with software
development, because my history has always been in product
development, software development.
Joe: Well, one of the reasons that brought us to this podcast is
during the development of the Work Center 7545 and the Work
Center 7556, there was a lot of discussions on the agile part and
the scrum part of the process that you worked on. Could you tell
me about some of the things that happened during that project?
Patrick: First of all, most of our software development
organizations have adopted Scrum as their project management
technique, particularly in the software development area. And so
they utilized the three rules of the scrum team, the scrum master
with the product owner and they carry on the various events with
the retrospective and the demo and the planning, the iteration
planning and all the traditional scrum events. In this particular
case, there was an incident where one of the teams was falling
behind and it was through the utilization of the retrospectives and
the demos that they were able to borrow from another
organization to essentially do load balancing so that they could

come in and help that other team to actually meet their
deliverables. It was the usage of the scrum that enabled that kind
of mentality for them to see the problem and go in there and
quickly try to fix it.
Joe: Is that how you introduce the concept of swarming? Is that
as you attack the problem, let's say?
Patrick: Yes, I don't know if the attacking was part of the
swarming part. But if you want to talk about swarming, in nature
swarming is essentially how certain groups of animals, bees and
birds and fish and things like that. How they can all react as what
seemingly is a single organism, without any command and
control. There's no leader that's telling them you do this and you
do that. Somehow they all kind of figure out what's the right
thing to do and they go off and do it. So, there's been some
discussion lately around how Agile and Scrum in particular has
some of those swarming principles or characteristics. I think it all
boils down to both of those environments utilize self-organized
teams.
Scrum is all about how a team organizes themselves around
what's the best way to deliver the commitment. Nobody is in
there telling each individual programmer you do this, you do that,
you do it this way. The team self-organizes and they figure it out
and they say "OK, this is how we're going to solve this particular
problem, let's go to it."
I guess there's a lot of similarity to the... That's how it works in
the animal world sometimes. When things like hives or swarms of
fish, can just go off and figure out what's the right thing for them
to do.

Joe: Do you have a task room? Or a room where the team
resides in?


Patrick: Generally, yeah. Most of the teams have what we call a
common room, where they will get together and do the majority
of their development. The common room is usually several tables
put together and everybody's workstations there. On the walls
they'll have information radiators. They have their burn down
charts and their task boards, so they can see what's going on in
the development and where they are at that particular iteration.

That way, there is a much higher bandwidth communication
between each of the developers. If somebody has a question,
they just ask across the table, instead of having to send email, or
an IM, or walk down the hall or something. So it just facilitates,
more cooperative development when everybody's in the same
area.
Joe: So in the old terminology that maybe other terminology
that would be kind of like a war room concept?
Patrick: Back in the day when we used to use war rooms, that
was more, at least the way we experienced it here was, the war
room was more of a place where peoples status their work. The
information would all be up there, and people would come in.
They would status where they were. You know, that's where the
planning took place. The common room, I think, is more where
the work takes place. So the people are actually in there getting
their work done. Which I think is slightly different from, the way
the war room used to be.
Joe: You actually have your task board, you have your iteration
plan, and it’s visible to anyone. I guess that would enable other
people to come in and help, and get up to date really quick. They
can just stand and look.

Patrick: One of the central pillars of any kind of empirical
project management like this is there has to be transparency. You
have to be able to see what's going on. In order for you to then
be able to inspect and adapt, which is the other two pillars that

you need to have. Without this visibility, people won't be able to
see where there are problems or where there are issues. Through
the retrospective at the end of the iteration, there's also that
same sharing of information.
Joe: You said the other two pillars were, inspect and adapt. Was
the first pillar then transparency?
Patrick: Yes. Information needs to be transparent. You need to
be able to see what's going on in your project or your process.
Otherwise things are hidden from you. And if things are hidden
from you, you can't react to them.
Joe: How do you go about teaching something like that? Do you
just throw them in a room and talk to them about what they're
able to do? Or, are you at a point now that you're just
introducing, let's say a new person with some basic instruction
from you, into that room? Like one at a time, into a group of five
or six or seven?

Patrick: Well the instruction, the way we roll out and deploy our
training is, we traditionally start with some training. We do our
agile training under the lean six sigma organization. We have a
certification process, and a green belt and a black belt process
that goes along with this. First of all we lay out the principles. We
lay out the lean principles by Womack and Jones and the lean
software development principles by Poppendieck. We want to
make sure that everybody understands the principles behind the
practices that we're then going to teach them. You don't get into
a cargo cult mentality, where people are just following particular
practices because that's what they were told to do. You know,
you want people to understand why these things work and why
it's important.

We get into the actual practices around the traditional Agile
development things. You know, Agile modeling, continuous
integration, customer driven development, pair-programming, all

those Agile practices. We also start teaching around Agile project
management. In particular we talk about Scrum.

Once we have that training done, then we do like a coaching
workshop, where we actually start implementing the concepts
that we just taught them, on their actual code. We'll work with
them through a project that they'll bring in.
They will be able to implement everything they just learned on
the real code. It's real work; it's a real project, so that kind of
gets them introduced to it. Then, since every organization is
different, it largely becomes a matter of them trying to figure out
what's the best way for them to implement it.
That's where I become available as a coach, where I can come in
and try to help them solve any of those kinds of problems.
Joe: You're in the front end a little bit, helping them, but then
you're also in the rear part, keeping the team together and
solving the problems that may come up from a team concept.
Patrick: Yeah. I won't even say I'm in there solving the
problems, but I'm there trying to help them solve their own
problems, create an environment where they can apply the
learning and apply the techniques. It really boils down to applying
a plan-do-check-act cycle on all of the things that they're dealing
with. Whether it's the product development or whether they're
tackling issues in their environment, creating common rooms or
dealing with infrastructure issues.
Joe: When we sit there and talk, you walk them through the
Lean, the Six Sigma, and the Agile process, is there one of them
that's kind of the umbrella over the other three?
Patrick: I would say that the Lean principles are pretty much
the umbrella that we put over all of this, really looking at making
sure we understand what the value is and what your value

stream is and how information and value flows through that
process, because you have that and, of course, pull and
continuous improvement and perfection. Those principles then
drive all the other things. When you start looking at, "So what
does that mean to software?" and then we can draw from
Poppendieck's work and say, "All right, well, how does that apply
to software around eliminating waste and creating knowledge and
all those things?" it all flows back, though, to these Lean
principles of really understanding what value you're creating and
how you can make that flow through your system as seamlessly
as possible.
Then, because it's Lean and Six Sigma, the Six Sigma part, we
really focus more then on making sure that there's a focus on
defects, and good tools and good measurements on eliminating
defects, because, while Scrum and things focus on slow, you also
need something that's going to focus on building that integrity in
and making sure that you're building quality in from the very
beginning and not just trying to test it at the end.
Joe: So you use a lot of what you would say DFSS, or design for
Six Sigma, too, in the process.
Patrick: Here at Xerox, we do Lean Six Sigma and we do design
for Lean Six Sigma. We combine both methodologies and really
see them as being very complementary and really working very
well together. We apply that both in traditional Lean Six Sigma as
well as design for Lean Six Sigma.
Joe: When you do that you're borrowing the best from either a
little bit, or using the appropriate tool at the appropriate time.
But when the tools overlap, do you have a favorite type? Are you
using DMAIC? Are you using PDCA? How do you determine what
to use there?
Patrick: Well, I guess it really would depend on the problem
that you're working on. If we're really focusing on the

development side, then we're really focusing more on a PDCA
methodology. Which is what Scrum really is, right? Scrum is just
a plan-do-check-act methodology. Because any product
development is really a knowledge-creation process, it's not a
well-defined process, so all you can do is continue to go through
multiple learning cycles, which is what the iterations are in your
Scrum methodology. To make a plan, do it, check your results,
and then add the net result and continue to build the knowledge.
Now, if we were, on the other hand, trying to solve an existing
problem, well then, DMAIC might be the right approach. Then
which tools you draw from that, whether it's Six Sigma tools or
Lean tools, it's really going to boil down to what problem it is that
you're working on.
Joe: The other thing that we talked about is that you spend
most of your time in the Agile side? And when we get into the
Agile that can be a culture in itself?
Patrick: I think I know what you mean. Sometimes I
characterize it as the Agile movement. There's a lot of talk and
thinking around Agile. But the way we've characterized it here is
we recognize the similarities between what the Agile movement
has and the practices that Agile is bringing to the table and how
they draw from the same principles that Lean is bringing to the
table and Six Sigma, for that matter. We look for the common
thread between the two, because Xerox has a very strong culture
of Lean Six Sigma and design for Lean Six Sigma, so it's very
natural for us to look for how what's been called the Agile
movement is really very synonymous with the Lean Six Sigma
principles. We blend those two things together here at Xerox. I
wouldn't just say we're strictly just Agile. We really like to blend
those things together.

Joe: When I looked at Agile, and like you had mentioned before,
it's very much like a PDCA cycle is what it is. But people in the

Agile field, in the software field, I think what is different than
when I see Lean and typical manufacturing-type structures, or
even in service-type instructions, is Agile places so much more
emphasis on feedback and that quicker development cycle than
what you see the emphasis placed on traditional Lean and Six
Sigma type projects. Do you agree with that?
Patrick: I'm not sure that there's a significant difference
between what we do in Lean and what we do in Agile. Certainly,
when you look at the original origins of Lean, it came from the
manufacturing environment. Manufacturing environments have
predefined processes, right? You know what's going to happen at
every step, and you know what you're trying to do at the end, so
you really look at this predefined process and you're saying, "OK,
how can I eliminate waste from this process?" You don't need the
same kind of knowledge-creation loops in that kind of a process
that you'd need in a product-development process, like software
development that's using Agile.
You are going to need tighter iterations and more feedback in a
product-development environment, because you don't know. It's
not a defined process. Now, when you take the Lean principles
from the manufacturing process and you start bringing those into
a product-development environment, then you start needing the
same sorts of feedback loops. Because then it boils down to "We
don't know what we're doing next.
We're not following a recipe. Now we're creating a brand-new
recipe." When you're creating a brand-new recipe, you've got to
learn more, and so you have to have a lot more feedback into
that whole cycle.
I think whether you're talking pure Lean or whether you're talking
Agile, you both get drawn into the same conclusions, that when
you don't know what you're doing, you need feedback.


Joe: One of the things that have been introduced lately in Agile
and under the Agile umbrella, I guess, would be Kanban. The
essence of Kanban, one of the great advantages, is managing
work in process. Have you implemented any of that at Xerox yet?
Patrick: In our product-development environment? Not really.
Whether you're talking about a Kanban process or whether you're
talking about a Scrum process, either one of those processes are
really just looking at managing your flow. They both have pluses
and minuses. They both have their advantages and
disadvantages. In the Agile community, there's an ever-raging
debate about which one is better and which one should be used.
From my perspective, it really doesn't matter. If you focus back
on your Lean principles about what value are you creating, what's
the process that is used to create it, and how can you make that
process flow, Kanban and Scrum are both just answers to that
question about how you can make value flow through your value
stream as fast as possible?
Which one you choose is really almost unimportant. As long as
you're really focusing on the fact that you're trying to get value to
flow through your process. The principle of making that happen is
more important than the actual tool you use to make it happen.
Joe: I think you really hit the nail on the head. Because it's all
about what you do well and what tools you can use to accomplish
flow.
Patrick: Yes, exactly.
Joe: We started talking a little bit about swarming. It's about
putting a lot of people on a single task. When that happens at
Xerox, what are the results of it, and kind of some of the
negatives of that?
Patrick: Well, the plus side of course is that things get done.
The biggest problems that happens, of course, is when you have

too many people doing too many things, nothing gets actually
finished. We call it dog piling. When you dog pile everybody onto
a single backlog item, that thing is going to get done. If you're
working on the most important thing, you're getting the most
important things done. That's really what's important is finishing
things, getting things completed, so that you can then move on
to the next thing. That's the real advantage of putting everybody
on one single task, the top priority task.
I guess the downside is sometimes people might be idle in that if
they're not immediately able to be working on something because
their contribution, maybe they're blocked or something like that.
There's a perception that since they're not busy at that moment,
they should be working on something else.
So that perception can make a lot of people say "Well, maybe
they should pick up another task, something else that's not the
most important thing and start working on that." That's a slippery
slope because then all of a sudden you start building up your WIP
again, and once your WIP starts building up, we all know what
happens. I guess that the downside is you might not be fully
utilizing your resources, but if you do fully utilize your resources,
then any kind of a slip up causes a huge delay.
Joe: What you're saying is that swarming may not be as
efficient, but if your priority is flow, you disregard the efficiency a
little bit?
Patrick: Yes, exactly. The analogy I always give is it's a relay
race, and you want to focus on the baton. How fast is that baton
going around the track, not how fast is each individual runner
busy at any given moment, it’s how fast is that baton going
around the track. That baton is the value going through your
system. You want to focus on "How fast is the value flowing
through my system?" Not "Are all my resources currently fully
utilized?"

The measure of efficiency should be "How fast can I get value to
go through my system?" Not "How utilized are my resources?"

Joe: When you use your different agile techniques, what's your
typical team size? They're all different sizes depending upon the
project or how do you try to break that down?
Patrick: Depends on what you mean by team. So each Scrum
team is around seven plus or minus two people, somewhere in
that sweet spot range. But then, of course, each project has
multiple teams working on that project, so any given product
would have anywhere from, I don't know, could be five to 15
different Scrum teams working on it. It really just depends on the
size of the actual project.
Joe: Sure. But your typical Scrum team has seven people on it,
like you said, plus or minus two?
Patrick: Yes.

Joe: And you have a Scrum master for each one. Are there any
other particularities that you develop within a team? Or that you
look for?
Patrick: What do you mean?
Joe: You have a Scrum master. Is there any other hierarchy that
you're looking for within a team or any other type of, you got to
have one of this or one of this in there?
Patrick: You want cross functional teams. That's always
important that each Scrum team should have the people on it
that are required to deliver whatever vertical slice of functionality
that you're trying to deliver for the product. One of the bad
smells you see sometimes when people start adopting Scrum is
they basically take their functional group and they say "OK, now
you're a Scrum team.' You'll hear "I have the database Scrum
team," or "I have the UI Scrum team," or "I have the testing

Scrum team," and obviously that's not going to work well because
when you're done, you don't have a vertical slice of functionality
that's been delivered.
You want a Scrum team that is going to have somebody from UI,
or somebody from the database or somebody from the domain
layer, a tester on the group or whatever, so that each team then
is able to deliver fully functioning pieces of functionality and not
horizontal layers of capability.
Joe: In the process, when you have a Scrum teams, you have a
global Scrum master, too, that's managing all the teams?
Patrick: The way that's usually dealt with is a hierarchy. You
have all your Scrum teams and then you night have a Scrum of
Scrums where all the Scrum masters get together and start
talking about inter-Scrum team issues and dependencies.
Similarly how each scrum team would have a product owner
talking and making decisions about what is going to be delivered
and what's important for that particular Scrum team. They will
then be kind of hierarchical where there will be a product owner
who can then make decisions across each of those teams, priority
calls and say, "this needs to be done before this needs to before
this." Or organize if necessary when there are interdependencies
between deliveries of the scrum teams.
Joe: Sounds like to me that Xerox must spend a lot of time on
team building and team concept training.
Patrick: As part of our training we do talk about the importance
of the team. When you talk about what is a team? You have to
find a common goal, without a common goal, you don't have a
team. We do talk about those kinds of concepts around what
makes a team and what makes a team function well together and
how it really is, it boils down to it's individual behaviors that
really make a whole team function. Particularly in our Black Belt
program, we do spend a lot more time on that kind of stuff, but

we do sprinkle that out throughout our Green Belt training as
well.

Joe: Do you think this concept; is this going into other areas at
Xerox besides just the software development? I mean, into
hardware development and different things like that. Are you
using this team concept and design?
Patrick: In the hardware area, they use less Agile and iterative
development techniques. They focus more on modeling
techniques. Because just like software, hardware is all about
knowledge creation and product development is all about
knowledge creation. Well, iterations in hardware are a lot more
expensive. You don't generate as many iterations, the way that
our hardware people gain knowledge is they do a lot of modeling.
They end up pulling a lot more from the Six Sigma side of things.
They do a lot of design experiments and they do modeling, that
sort of methodology to create their knowledge. So that when they
do their next build of hardware, they've gotten a lot of the
wrinkles out of their design so that it will come together a lot
smoother and faster.
Software is cheap to iterate. Software does their knowledge
creation by iterations and feedback. They just generate another
iteration, get more feedback. So, the same principle of creating
knowledge, but two different ways of actually creating that
knowledge.
Joe: I always get confused sometimes when people are talking
about these different things, these different tools and then they
slide into problem solving. Can you define really a difference
between the regular work flow and problem solving or do you use
that term interchangeably?
Patrick: Depends on what you mean by problem solving, but if
you're talking about root cause analysis, that is built into a lot of

your design techniques. When you're trying to figure out why or
how something should work, you're always trying to look for
what's the critical pieces of this. If you're talking about problem
solving as in terms of look, we've got a process or a problem and
if something's broken, we need to fix it. That's an after-the-fact
thing where as product development is much more of we're
creating this or trying to design our systems so we don't get
those problems in the first place. We do segregate the two
disciplines that way. That's really the difference between our
traditional Lean Six Sigma verses our Design for Lean Six Sigma.
Lean Six Sigma says you've got a process and you want to find
what the problem is, you use Lean Six Sigma techniques to do
that. Whereas our Design for Lean Six Sigma says let's design our
products so that we don't get the problems in the first place.
Joe: Are you developing a stronger and stronger of what I would
say agile culture as far as adaptability and quicker work flows?
Patrick: I think it really is becoming a part of our culture here.
The thing with this program from the beginning, I started with
this in I think in 2005, is when I first started trying to put
together the software design for Lean Six Sigma Greenbelt
program. At that time, it was a real push. There was a lot of
resistance; there was a lot of skepticism around whether or not
this is going to work. We started deploying it and a few early
adopters took it on and they started getting successes.
Some other groups start taking it on. They started getting
successes. Now, I think we've gone to that tipping point.
Now, it's really changed the culture of how our company works,
particularly in the software area. In this whole theory of
continuing to improve, I think we can continue to expand all this
as we get further out in the overall development process. In
software in particular, I really do believe we've seen a real culture


shift on how people do their work. I've seen some very powerful
and positive impacts from it.

Joe: I can remember you introduced me to pair programming in
a podcast a year ago. What I have seen in the past year is that
concept taken and used in other fields. Because of the ability of
when you're working with someone or you're working with a
team, you get that instant feedback and kind of a daily PDCA
cycle that you're constantly improving and you're constantly have
a check and balance there. Do you see, in whether you call it
pair-programing or team collaboration; have you seen that being
utilized more and more?
Patrick: I don't have as much visibility into a lot of the other
groups. My impression is in the same time that Agile was really
taking off in the software area. You were hearing about rapid
development in hardware, all the engineering taking place
simultaneously. It was the same kind of concepts and I think they
were growing in parallel with each other without really being
completely aware of each other. I believe that the folks over in
the hardware area are using the same sort of principles and
concepts in their hardware development that software is.
Now, of course, because there are differences in how you develop
hardware and how you develop software and the various
expenses, they're going to draw from different tools but the same
principles, I think, are applied in both areas.
Joe: Now, swarming is an Agile response when someone's in
trouble in the middle of an iteration is when people gather round
to help. When does someone raise their hand or does the Scrum
master determine that you need outside help and talks with the
other Scrum masters. How do you go about that process to bring
in the help?
Patrick: Generally, you'll start seeing -- and it depends on how
big your iterations are. Typically around here, our iterations are

reasonably short. We generally have two week iterations. It's
usually during the retrospective or the review meeting where this
information will come out more across teams.
Within the team, or course, you'll start seeing that in your daily
Scrum. If people are having barriers or they're getting into
trouble, they'll come out in the daily Scrum.
Usually then, at the end of the retrospective, they'll say look
we're behind. What didn't work well? Well guess what, we weren't
delivering our commitments, we've got these issues. What are we
going to do about it?
Well, we need some more help. That's when you can utilize this
Scrum of scrums notion that I talked about before. Where the
scrum masters from the various teams can start getting together
and talking about inter-team issues.
If one of the Scrum master's teams is having trouble, they can
bring that up at the Scrum of Scrums. There at that level, start
discussing what would be the best approach to fixing it.
Often what happens is the Scrum masters will bring that
information back to their teams. The teams will collaborate and
figure out what's the best way to address the problem.
It's this whole notion of again, self-directed teams. The Scrum
master doesn't come down and start telling people, "Hey, you
guys have to go work on this other team." But, it's really more of
an information flow. And say, "Hey guys, this is what I'm hearing
about the project, what do you think we can do?"

The teams will then try to self-direct and figure out what's the
best way to approach. Now, of course, they also need to make
sure that the product owners are all inline with priorities. If the
team that's the farthest behind, if they're the lowest priority, then
that's the thing that's going to fall behind.

If they're a higher priority on the product backlog, those items
will be higher so, just like we talked about this morning. People
from other teams will then go over and they'll start dog piling
these higher issues.
If they need to break it down into smaller chunks, the other
teams can take on some of that work and then they can work on
those higher priorities together.
Joe: Well, it has to take some real openness with all the teams
and all the team individuals to be able to do it comfortably and
the acceptance that they want help and to help others. That has
to be a pretty unique culture, doesn't it?
Patrick: That goes back to that transparency again. In order for
any of this stuff to work, you have to be absolutely transparent
about everything. If you are having problems, you need to make
sure that's visible. That's why their task boards and their
burn-down charts are all up on their walls. That stuff needs to be
visible to everybody because, without it being visible, you can't
inspect.
If you can't inspect then, you can't adapt. You have to be
transparent so that this whole thing works. If you don't have that
transparency, then none of this is going to work.
Joe: The other part that you talked about, the other three
pillars, you talked about inspect and adapt. I think we've covered
"adapt" pretty well in this whole thing. But, what about the
inspect part? How often are you inspecting and who is inspecting,
I guess?

Patrick: The teams inspect daily during their daily Scrum.
They're inspecting to making sure that they're going to be
delivering on their commitments. They get together on a daily
stand-up for 15 minutes or less. Say what have they delivered,
what do they plan working on, and what barriers do they have.

Every 24 hours, if not more, because if they're in a common
room, they're pretty intimate with what's going on. Minimally,
every 24 hours they're together saying whether or not they're
going to make their deliverables.
Then, at the end of every iteration, which is typically two weeks
around here, they do an inspection on both the product where
they do the review. The product owner and any stakeholder,
who's interested, will come into that review and look at the
progress that the team is making and determine if any
corrections need to be made there.
There's that inspection and then at the retrospective there's also
inspection. So there, they're looking at the process to determine
whether or not any changes need to be made to how they're
delivering things.
They're inspecting daily for their delivery for that iteration and at
the end of every iteration, they're inspecting the product and
they're inspecting the process.
Joe: I'd really like to thank you Pat for insightful conversation
about the Agile process and Lean Six Sigma at Xerox. It was very
interesting. I learn something every time that I talk to Xerox. I
appreciate the opportunity to do this very much. Is there
anything you'd like to add to this conversation?
Patrick: No, I just want to say thanks to you Joe. It's always a
pleasure talking with you and anytime you'd like to get together,
it'd be my pleasure.
Joe: Well, thanks again Pat. This podcast will be available on the
Business901 blog site but also Business901 blog site. So, thanks
again Pat.
Patrick: You're very welcome Joe, thank you.



Joseph T. Dager
Lean Six Sigma Black Belt
Ph: 260-438-0411 Fax: 260-818-2022
Email: jtdager@business901.com
Web/Blog: http://www.business901.com
Twitter: @business901
What others say: In the past 20 years, Joe and I
have collaborated on many difficult issues. Joe's
ability to combine his expertise with "out of the
box" thinking is unsurpassed. He has always delivered quickly, cost
effectively and with ingenuity. A brilliant mind that is always a pleasure to
work with." James R.

Joe Dager is President of Business901, a progressive company providing
direction in areas such as Lean Marketing, Product Marketing, Product
Launches and Re-Launches. As a Lean Six Sigma Black Belt,
Business901 provides and implements marketing, project and performance
planning methodologies in small businesses. The simplicity of a single
flexible model will create clarity for your staff and as a result better
execution. My goal is to allow you spend your time on the need versus the
plan.

An example of how we may work: Business901 could start with a
consulting style utilizing an individual from your organization or a virtual
assistance that is well versed in our principles. We have capabilities to
plug virtually any marketing function into your process immediately. As
proficiencies develop, Business901 moves into a coach’s role supporting the
process as needed. The goal of implementing a system is that the processes
will become a habit and not an event.

Business901 Podcast Opportunity Expert Status


How Lean, Six Sigma and Agile all work under the same umbrella at xerox

More Related Content

Similar to How Lean, Six Sigma and Agile all work under the same umbrella at xerox (20)

More from Business901 (20)

Recently uploaded (20)

How Lean, Six Sigma and Agile all work under the same umbrella at xerox