How is Agile relevant beyond IT? Alan Zucker explains how agile roots are in the Lean manufacturing movement as he shares about the application of agile practices for non-technology projects. He talks about agile as a mindset, the Gemba Walk, House of Lean, transparency in teams, value stream mapping, and much more. Recently Alan launched a new Velociteach InSite course: Agile Beyond IT, a hands-on application of agile practices for non-technology challenges.

Table of Contents

01:59 … Agile Beyond IT
03:09 … Blurring the Lines between Traditional and Agile
06:04 … Fusion Cooking and Project Management
07:21 … Agile as a Mindset not a Methodology
10:19 … Self-Organizing and Self-Managing
11:32 … Empowering Team Members
12:36 … Iterative and Incremental
15:12 … Iterative and Incremental in Non-IT Projects
15:21 … The House of Lean
17:43 … Transparency in Healthy Teams
19:22 … The Gemba Walk
22:53 … Agile Manifesto beyond IT
24:59 … 12 Agile Principles beyond IT
27:41 … Dignity
28:49 … Value Stream Mapping in Non-IT
31:39 … Advice for New Leaders
32:57 … Get in Touch with Alan
34:19 … Closing

ALAN ZUCKER: Another is trusting the wisdom of the team, recognizing that you don’t need to come up with all the answers, or potentially even any of the answers; that your strength lies in bringing out the experience and knowledge of everybody else on the team.

WENDY GROUNDS:  You’re listening to Manage This.  My name is Wendy Grounds, and with me in the studio is Bill Yates.  This is the podcast about project management.  We are excited to bring our guest to you today.  This is actually someone we’ve had before.

BILL YATES:  Yes.

WENDY GROUNDS:  Alan Zucker is joining us.  He’s a certified project management professional.  He’s an Agile Foundation certificate holder, a Scrum Master, a Scaled Agilist, as well as a keynote speaker.

BILL YATES:  We have a course that we are launching.  This one is called “Agile Beyond IT.”  It’s a part of our self-paced training in InSite.  Alan created the “Fundamentals of Agile” course for us, and the feedback was always positive, and sometimes he’d get the comment, “I don’t work in technology, so how does this apply to me?”  Well, that’s something that he’s dealt with a lot in some of the consulting and other training that he’s done for organizations.

For several years Alan’s helped clients use agile principles and practices in diverse non-technology fields, everything from construction to not-for-profits.  These experiences are the basis for this class.  And he pulls some of the concepts from the agile principles and says, “Okay, here’s the principle.  How can we apply this beyond IT?”  Very practical, great advice.

Alan has got multiple agile certifications from PMI, the Scrum Alliance, Disciplined Agile, and Scaled Agile.  He’s created courses for us.  He instructs for us.  He is in the classroom.  In fact, as we wrap up this session today, he’s going to begin a four-day PMP prep class for us.  And we’re delighted to have him with us.

WENDY GROUNDS:  Hi, Alan.  Welcome to Manage This once again.  Thank you for joining us.

ALAN ZUCKER:  Hi.  It’s great to see you guys again.

Agile Beyond IT

WENDY GROUNDS:  Now, we’ve just mentioned that you have completed a course for us, “Agile Beyond IT.”  And we’re very excited to publish this one.  It’s an excellent course.  Could you give us a little bit of a background for this and why you picked that name for the course?

ALAN ZUCKER:  Sure.  So a few years ago I created a “Fundamentals of Agile” course for Velociteach.  And it’s been very popular.  But as we were looking at some of the comments that people left, people were saying, “Well, this was a really great course, but it was all about technology, and I’m in a non-technology area.  How can I use agile?”  So we had some conversations, and we put together a course for people that aren’t in technology. 

And it just so happened that around the same time I was thinking, how do I begin to sort of coalesce and distill some of the ideas I had around agile because I’ve been working with very non-traditional organizations and teaching them agile techniques to better manage their work.  Like I’ve done a lot of work with nonprofits, and that’s really been very interesting to show them, hey, you can use these agile techniques.  And they love it.

Blurring the Lines between Traditional and Agile

BILL YATES:  Alan, I’m going to quote Alan at Alan.  There’s a key concept that you share early on in the course.  And I’m going to quote it:  “As the profession evolves, successful project managers will be pragmatic and select the best practices based on the project context.  In other words, the lines between traditional and agile project management will blur, and we will pick the best tools and practices based on our project’s needs.”  I love that.  I completely agree with that.  But let’s dig into it a little bit further.  How do you see the lines blurring?

ALAN ZUCKER:  So I think if we look at project management or the history of project management, traditional project management really came from construction, really from engineering and the expectation that we can design something and build it.  And if you’re looking at an office building, that’s what they do.  Turns out that my son-in-law is a construction project manager and has worked on some big buildings here in the DC area.  So you’ve got your designs and your specs.  You bring in the guys that do the excavation, and the concrete guys, and they pour the floors.  And then you bring in the plumbers and the carpenters and three different types of metal workers.  And it works where you’ve got a good design.

Agile started in software development.  And agile works really well there because we’ve found and we know that we cannot fully articulate what we need upfront.  So the idea of iterating through and getting feedback and moving forward works well.  And I think that for a lot of us, if we begin to think about, well, what are the best practices from either side of the spectrum, we begin to pick and choose and say, well, it might make sense to do a daily standup, even if I’m working in a traditional environment.  Or that maybe we need to do more structured risk management on our agile projects.

BILL YATES:  Yeah, those are good.  I love the concept of bringing the best out of both and blurring those together.  Now  whenever we talk about this, I’m sure we have some purists that are really on both sides, both camps.

ALAN ZUCKER:  Yeah.

BILL YATES:  Who do you think’s going to get more upset by that?  You think the Agilists or the Waterfall teams are going to be more upset by that?

ALAN ZUCKER:  I think you’re going to have folks on either side that aren’t going to be very happy.  I think that the people on the Waterfall side, you know, if you’re working construction there’s probably less that you would adopt from agile.  And the things that we recommend would probably be, “Hey, that’s a great idea.”  I think the Agilists sort of came in as the insurrectionists 20 years ago.  And I think they are beginning to slowly move to say, well, there are things of value from traditional project management.

Fusion Cooking and Project Management

WENDY GROUNDS:  Alan, in your course you compared project management to fusion cooking.  Can you explain that for us?

ALAN ZUCKER:  Sure.  I think that originally one of the ideas I was thinking of or the titles of the course I was thinking of was Agile Fusion, or Project Fusion.  I like the idea of blending and mixing.  So I think in the course I talked about this great sushi restaurant that I go to in Mexico, where they’re making traditional sushi, but then mixing in Mexican spices and peppers.  Or there’s a place here in D.C. where there’s Eggs Benedict, and then they use Beef Bulgogi as the topping.  And I think it’s just the idea that there is all these really great ideas that we can share and we can mix.  And if we don’t think about things in this very compartmentalized way, just phenomenal, inventive, creative things can happen.

BILL YATES:  You make me think of I like watching Bobby Flay, the famous chef Bobby Flay.  There’s a show where people are trying to come on and beat him.  And he’s always taking some traditional recipe and adding his own style, and it’s usually some kind of like a serrano pepper or something that he adds to it that just takes it to another level.  And the judges love it.  So there’s that idea of fusion.

Agile as a Mindset not a Methodology

There are so many little pieces that we can pull from agile practices that are very applicable and very helpful in those environments.  And that’s what I appreciate about the course.  We’ll get into the details.  But instead of saying, okay, you must do this, it’s more of a, hey, consider the mindset behind this.  Consider the mindset of agile in this and what is something from that.  If we look at that mindset, how can we take that and move that into the way that we’re managing projects?  A vital point that you make is that agile, don’t think of it as a methodology as much as a mindset.  Talk more about that.

ALAN ZUCKER:  So I came to project management from economics.  I have my master’s degree in economics.  So I was the accidental project manager.  And back in the dark ages, back in the 1980s, I was working for a firm that was doing environmental consulting work.  And I was working with a senior economist to develop a model of what would happen under different environmental regulations.  This was the dawn of the computer age. I built this massive model in Lotus 1-2-3 Release 1A.  And he had some ideas about, well, this is how the model should work based on some previous experience.  And I had a little bit of experience with personal computers.

So we would build a little bit, and then we would troubleshoot, and we would go back, and we would review.  We started out with a model that was, I don’t know, maybe half of an alphabet long, and ended up with one that was so big, it was three alphabets long, and we had to bring in the data files one by one and run them and then aggregate them because of the capacity of the computers.  So that was really my first experience doing software development.

And then I went to work at the Treasury Department, worked with the New York Fed to automate the Treasury Security Auctions. This was 1990, 1991.  And my lead developer said, well, we’re not going to use the traditional approach.  Said I found a tool that would allow us to sort of do screen mockups and screen prototypes, and that’s how we’re going to build the application.  So we mocked up some screens, first just drawing things on paper, and then putting it into the tool, creating a little bit of scripting behind it.  In six months the system was essentially built.  And if we were doing traditional methods, we wouldn’t have been into the design at the six-month point.

And so I was doing all these agile things, and I realized that how we worked together and how we organized the work is more important than a particular methodology.  Then let’s consider that the founders of the Agile Manifesto represented about a half a dozen different frameworks and methodologies.  And they were really looking for what are the commonalities that we have in terms of the themes.

Self-Organizing and Self-Managing

WENDY GROUNDS:  Alan, we also talk about agile teams as being self-organizing and self-managing.  Where does this idea originate?

ALAN ZUCKER:  So the idea of self-organizing, self-managing teams comes from a classic article in the Harvard Business Review.  I think it was mid-’80s.  It was two Japanese professors, Takeuchi and Nonaka, and they wrote this article called “The New New Product Development Game.”  And they talked about some of the leading companies like Fujitsu and IBM and Honda, and how they would create these teams that they would specifically put offsite and say, “Figure out how to solve these problems.”  And that’s where the word came from.

And I think that when we talk about agile concepts, I think the words “self-organizing, self-managing teams” is probably one of the ideas that’s hardest to understand and hardest to wrap our heads around.  And rather than thinking about this as a group of people where there’s no decision-making because we’re all trying to reach consensus, really think of a situation where we have a vision of what we’re trying to achieve, and we’re empowering people to figure out the best way to solve those problems.

Empowering Team Members

BILL YATES:  I think that word of “empowering,” that really resonates with me.  It’s no longer as a team member, I’m not just sitting there waiting for Alan to tell me what to do.  Well, he’s my project manager.  I’m going to wait.  I’ve done the stuff that’s on my list.  We’ve got a team meeting on Friday.  So unless I hear from him before Friday, I’ll just sort of document a few things, clean up a few things.  But he’s my manager.  I’m going to wait until he tells me.  It’s just it’s a different mindset with agile.

ALAN ZUCKER:  Right.  And I think that really ties into the idea of unlocking the creative energy of our team members.  If we’re working in knowledge work, which almost all of us are these days, we need to recognize that the folks that work for us are at least as well educated and probably as smart as we are.  And if we tell people what to do, then they’ll do what we tell them. But if we invite them to be part of finding the solution set, we’ll come up with lots of different ideas.  And for most of the problems we’re trying to solve, there is not just one simple solution.  But I think that’s a real critical piece in terms of adopting the agile mindset.

Iterative and Incremental

WENDY GROUNDS:  Alan, when I started working on this podcast, my project management knowledge was very limited.  I heard the word, and that was about it.  So a lot of it has been learning as I go along the job.  And I have absolutely enjoyed going through your course, and I’ve learned a lot from your courses, as well, on project management.  But I try and pop questions in for the rookie project manager into our podcasts, things that I would want to know.  I’m sure there’s other people out there that would like to know, as well.  And one of my questions is what do the terms “iterative” and “incremental” mean?  How would you describe those words?

ALAN ZUCKER:  So I’m going to actually just even pull that back even a little bit further.  I think Agile is a very natural way of organizing projects and organizing how we do things.  One of the metaphors I use is kids playing at the beach and building a sandcastle.  If you watch kids building a sandcastle, they don’t have a plan, and they don’t map it all out.  They start building.  And that’s the idea of being incremental.  We will build things in pieces.  Iterative is where we learn from what we’re doing, and we adjust, or we adapt, or we do things differently going forward.

So if you see kids playing on the beach, building a sandcastle, they’ll build something and say, hey, guys, what do you think?  And they’ll be like, eh, and maybe they’ll knock it down and start over.  And so that same principle of let’s build things in small pieces, let’s get feedback and use that feedback to drive things forward, is really one of the critical concepts behind Agile.

BILL YATES:  I love the analogy, and I just think about seeing kids at play and what we can learn from them.  And you’re absolutely right.  And it’s funny, too, from my standpoint.  I can remember watching our own kids playing, and one of the boys would figure out a better way to form something with sand where it would withstand the pressure, and just the right combination of water and sand and maybe some shells.  And then the other kid would watch, and they’re like, okay, got it.  Then they’d go replicate the same thing.  So there’s like a natural learning that takes place.  They’re not worried about IP or mutual nondisclosures.  They’re just playing and figuring out the best way to get things done.

ALAN ZUCKER:  And that’s one of the basic Lean principles, Bill, which is amplifying the learning.  And the other principle that you just talked about is the self-organizing or the self-managing teams.  When the kids are at play, no one wants to be the head of Sandcastle A.  And if you’ve got one bossy kid, everybody else leaves.

BILL YATES:  Yeah.  That’s true.  You take your shovel and go somewhere else.  There’s plenty of sand on the beach.

ALAN ZUCKER:  Yeah.

Iterative and Incremental in Non-IT Projects

BILL YATES:  So this idea of iterative and incremental, those are foundational concepts for agile approaches.  How can we take that approach in non-IT projects?  What are some examples that we can think of for that?

ALAN ZUCKER:  Sure.  Let’s just think of something really simple.  Let’s talk about writing a report or a book or something like that.  Imagine that book is 10 chapters long, 100 pages long.  And the traditional way of doing it is I’m going to go off, and I’m going to spend six months or whatever writing the book.  Then I turn it over to you as my boss to review.  And now you’ve got a hundred pages. 

And an agile approach is, as I complete each chapter, or even maybe even each section within the chapter, I’m going to share it with you.  You’ll provide feedback.  And so if you didn’t like the way I was phrasing things, rather than having to make those changes on a hundred pages, I’ve learned after five pages or 10 pages, and it flows through, which also reduces the cost of rework.  And the cost of rework, it goes up exponentially, the further from the source.

The House of Lean

WENDY GROUNDS:  There’s something else that I wanted to find out more about was Lean.  You talk about Lean, and you talk about the House of Lean.  Can you describe what that is?

ALAN ZUCKER:  Sure.  So Lean is also a set of principles, and Lean actually came from Toyota and Toyota’s Lean manufacturing model.  And I’ve seen Lean described different ways.  But one of the metaphors I really like is the House of Lean.  And so the roof of the House of Lean is value.  And that’s because we really want to focus on delivering things that are valuable to our customers.  The base is leadership.  And leaders really need to create the right environments for teams to excel and do well.

Another component is systems thinking.  And that’s a very fancy way of saying we need to consider the entire process and how everything works end to end to avoid optimizing a specific piece.  So typically what happens is we’ll speed up the piece of work in one area, and all that does is create a problem somewhere else down the line.  Another thing that is really valuable is focusing on recognizing that people matter and having respect for people and culture.  And I think today that’s even more important than it was 60 or 70 years ago, and the idea of continuous improvement, of always trying to get better at what we do.

Transparency in Healthy Teams

BILL YATES:  As you think through these pillars or these foundational concepts, it’s easy to see how those apply, regardless of the tool, the framework that you’ve chosen to manage your project.  There’s a lot to pull from Lean into that.  For example, let’s talk about transparency.  I know that’s one of the pillars.  How does transparency show up in healthy teams?

ALAN ZUCKER:  So transparency shows up in healthy teams lots of different ways.  One is that we just actually are physically displaying the status of the work on the walls.  And by physically displaying it, it changes our relationship to our project.  Our traditional ways of looking at a project are that the PM has the Gantt chart on their PC, and maybe the team looks at it once a week.  But if you’re creating a Kanban board or a task board, and everybody’s looking at the work every day, you can’t hide from it as much.

Transparency is also how do we show up in terms of talking about problems and issues?  And in traditional cultures, or traditional management cultures I should say, we try to hide our problems and hide our issues and hope that we can fix them later on.  But if we’re being fully transparent about when we’ve got a problem, then we can tap into the entire team, have everybody help us figure out what’s going on.  Or if we have an issue, let’s be honest about the issue.  Issues, as we all know, aren’t like a good wine.  They don’t get better with time.  They’re like mushrooms.  They just get stinky and rotten.

The Gemba Walk

BILL YATES:  Yeah.  That’s so true.  Another concept that you brought up in the course, I was not familiar with it, but it’s so similar to like Management by Walking Around and other techniques.  It’s called the Gemba Walk.  Describe the Gemba Walk.

ALAN ZUCKER:  So the idea of the Gemba Walk, it literally means go out and see.  And so when we’re developing products or delivering services, it’s a matter of going out and seeing how our customers are using that product or how they are responding to our service.  It’s literally get out of the offices and go out and talk to the people.  And one of the things that you’ll find is that the preconceptions that we have are just wrong because when we are developing something, or building something, we come at it from an expert’s point of view.  And so we’re coming at it with all these implicit assumptions.

Several years ago I was working with an HR department, and they had just replatformed all of the processes for doing all of the HR transactions.  And there was a big problem.  The CFO was like, “Why do I keep getting these emails?”  They invited my team in to go and look at it.  And something really simple.  You know, you’d go through the form to offboard somebody, and at the very bottom of the form is where the links were to the frequently asked questions. 

So you fought your way all the way through the form, and then it’s like, “If you have questions, go here.”  It’s like, can’t we just move that up to the top of the form?  Or how they word it.  It was “You must do this if you haven’t already done that.”  And I said, “If you just turn that sentence around, it would reduce a whole lot of anxiety.”

It just so happened that I had someone leaving my team at the same time, so I had experienced all these issues with the process.  Small things.  But if you’re in HR, or if you’re in whatever field you’re in, and you’re designing something, you know how it’s supposed to work.

BILL YATES:  Yes.  So funny that you’re mentioning this.  I just recently had an experience like that with a form, and it was for an absentee ballot.  So I was filling this out.  It’s from our state, I’m sure.  Think about all the thought that went into that because of course there’s a chance that people could get sued, or agencies could be called out for this.  And I’m looking at the form, and it’s simply two pages.  The first page makes sense.  The second page, as I look at it, I’m like, I don’t know that there’s any reason that I need to have this second page.  It’s asking for some of the same information.  But it’s only if somebody else is going to fill out or vote on my behalf, you know, if I’m not physically able to do that.

And I’m looking at it, going, there should be a clear direction on the first page saying do I even need to fill out the second page.  Only in these conditions.  So then I’m thinking, well, I’ve got to send the form in.  If I only send in page 1, maybe they reject it.  But what do I fill out on page 2?  So somebody needs to do that Gemba Walk and actually get in the shoes of the customer and fill out the form as if they’ve never seen it before.  And it’s a hard thing to do.

ALAN ZUCKER:  Yeah.  And it also brings in another component, which is, if we look at agile writ large, it’s this universe of different concepts and ideas that start to play together.  So from Gemba you start, get into customer centricity or design thinking, the idea that we can create easy prototypes to get feedback from our customers versus assuming that they’re going to understand what we want.

Agile Manifesto beyond IT

BILL YATES:  So true.  One of the points or the sections in the course that you have, you take the Agile Manifesto, and you describe these, and you show how they’re relevant to other projects.  So the Agile Manifesto was written by technologists to find better ways of delivering software.  But we know that those values can be relevant beyond IT.  So can you share some examples of how those values are relevant to people that are constructing buildings or building a ship or some other physical product.

ALAN ZUCKER:  So I think if we look at the Agile Manifesto, you’re right, it is very technology centric.  They talk about building software.  But if we replace software with solutions or products, then almost all of the concepts translate over, or even the first one which is individuals and interactions over processes and tools.  I had a friend who was working with an insurance company years ago. One of the things she was doing was getting them to move from a rules-based way of dealing with customer interactions to a values-based view.  And so the difference is teaching people or teaching our employees what we want and what we value and letting their best judgment guide what we should do.

It brings back to mind leading customer service organizations. A very positive incident that I had at a leading hotel chain, where they empower their employees.  And I was checking out in the morning, and the maid said, “How was your stay, Mr. Zucker?”  And I said, “It was great, but I had some Internet problems”.  And she got on her walkie-talkie and said down to the desk, “Please put a credit of $50 on Mr. Zucker’s bill.”  I was like, wow, that was an amazing thing.  And this chain has the policy where any employee in the entire hotel can give up to, I can’t remember the exact amount, but it’s a couple thousand dollars in customer credits every single day.

12 Agile Principles beyond IT

BILL YATES:  You took the 12 Agile Principles, you can find them all over the Internet, and you reinterpreted those to apply to non-software projects.  I gained a lot from that.  I like the work you did with that.  If the listeners want to follow all 12, they’re going to have to go online to our website and purchase the course and hear from Alan that way.  But I’d love it if you could just take a couple of those and give us an example of how you take one of those agile principles and reinterpret it beyond IT.

ALAN ZUCKER:  So I think one of the basic ones, or one of the ones that I like the most, is the fifth one. Which is building teams around motivated individuals.  And when we think about management and management theory, and we think about it from a historical perspective, we can really see how some of the traditional values that we created that really go back to the era of mass production and Taylorism and Fordism, really created an environment of command-and-control.  And maybe that made sense in a factory setting, and I’m not actually really sure. I’ve been actually reading a lot on that recently, again.

But, you know, starting in the 1950s you have Peter Drucker talking about knowledge workers.  And knowledge workers used their brains, their minds to solve complex problems.  We see this shift. We hear McGregor talking about Theory X versus Theory Y, and then Maslow talking about Theory Z, which is where you have people where the role of management is actually to help people be innovative and creative.  And we’ve all been in this situation where we’ve worked on teams where people just click, where they work together.  We really should think about, well, how do we create that environment where people feel empowered, and they feel valued?  And if you even jump forward to Dan Pink or McClelland, and they’re talking about autonomy, mastery, and purpose.  People want to feel they’re doing something valuable.

So a couple of months ago, as I was developing the course, I was listening to an Adam Grant podcast. He was interviewing Esther Duflo, who’s a Nobel Prize Winner in Economics.  And she was talking about how people want to work and have a sense of accomplishment and a sense of purpose from what they’re doing.  And when people have that, they can do amazing things, even if it’s just something, some manual work.  Like I remember when I was working in a restaurant and working as a dishwasher.  I mean, like, I had a sense of purpose.  It created grit for me.  But people need that.

Dignity

BILL YATES:  There’s a key word that you brought up which was the word “dignity.”  It’s such a great word because those people that are leading teams, if they can embrace the idea that every person on this team has value and has a special skill set, my job as leader is to bring the best out of each person, and to treat each person with dignity, and for them in turn to treat each other with dignity, including the customer, whether they deserve it or not. 

But I love that word of “dignity” because in my mind it puts everybody at the same level.  And that’s where teams really flourish is when there’s not a superstar.  There’s not a hero coming in at the end.  Everybody’s at the same level.  Everybody’s pushing and has the same passion to create the new product or make the enhancement or come up with a better way.  And dignity is such a key for that.

ALAN ZUCKER:  I agree.  And I think even in any work environment.  My younger brother is a special needs person, and he works at a major bank, and he’s been there for over 20 years.  And that job has given him such a sense of dignity and purpose in what he’s doing, and just completely outside the realm of what we normally think about.

Value Stream Mapping in Non-IT Projects

BILL YATES:  Alan, one of the concepts that I think we can take from agile approaches and apply in all project settings is this idea of value stream mapping.  Talk a bit about that and how that can benefit even those that are leading non-IT projects.

ALAN ZUCKER:  The idea of value stream mapping is really understanding our customer’s journey.  Value stream starts with a customer having a request or a need, and ends with that need or the request being fulfilled.  And it’s really understanding all of those interaction points along the line.  One of the quotes that I love from Deming, and Deming is just a master, is “If you can’t describe your process, you don’t know what you’re doing.”  So when we map out those various steps, we can really begin to see, well, what are the things that make sense and the things that don’t make sense?

And when we look at how much time it takes for us to actually do work versus the entire elapsed time, that’s where we can see a lot of the issues or the inefficiencies we have in what we do.  Think about a time like when you called your IT help desk.  You placed a call in, and a day and a half later someone actually got back to you.  They came down, took them 15 minutes to fix your PC.  So that eight-hour wait was waste because it only took them 15 minutes to take care of the problem.

One organization I worked with, rather than having that help desk model, they shifted to a genius bar model.  And in a couple of the buildings where they had a lot of folks, they had a room sort of right off the lobby where there were the tech support folks.  And you come in, you might wait 10 or 15 minutes till one was available.  But they’d solve your problem on the spot. 

We can also use our value stream mapping in terms of thinking, well, how do we improve our overall end-to-end process? And one of the things people talk about is shifting left.  And one of the examples that I talk about in the course is there was a new Smoke Meat takeout restaurant here near us, and the food was great.  It was smoked meats, and they had a pop-up fried chicken kitchen in there, as well.

BILL YATES:  You’ve got my attention.

ALAN ZUCKER:  It was great.  It was wonderful.  First time we placed our order, went in, we picked it up, came home, the order was all backwards.  Like we ordered the chicken dinner and we ended up – or the chicken bucket with extra sides, and we got two chicken dinners.  The food was more or less the same, but not quite.  So the next time I go, and I’m like literally opening up all of the food containers before we leave the restaurant.  The people thought I was crazy.  But the idea of shifting left is you keep looking forward in the process and think how are the things that I’m doing either affecting the things ahead of me or behind me.

Advice for New Leaders

WENDY GROUNDS:  Alan, what advice can you give to project managers who are new to a leadership role?

ALAN ZUCKER:  So I think here there’s a couple of things to think about.  And it really all taps into this theme that we’ve been having about people.  So a couple of just quick tidbits there is, one, recognizing that teamwork makes the dream work, that it’s about people working together to create this new product or service, or even if we’re running or working in an operational environment.  Another is trusting the wisdom of the team, recognizing that you don’t need to come up with all the answers, or potentially even any of the answers; that your strength lies in bringing out the experience and knowledge of everybody else on the team.

And then a third is using mistakes as a learning moment.  There’s lots of different quotes out there that success is a poor teacher, and that when we create an environment where people are afraid of admitting mistakes, we don’t get better.  One of the things I do, even in the classroom  as I’m setting the norms for a class, is I say don’t fear failure.  This should be a very safe environment, and you will learn more by making mistakes versus by getting it right.

Get in Touch with Alan

WENDY GROUNDS:  Alan, this has been excellent talking with you.  If our project managers want to get in touch with you, if they have some questions for you, what’s the best way that they can reach you?

ALAN ZUCKER:  Sure.  The best way – there’s actually two good ways.  One is connect with me on LinkedIn.  I’m AlanIZucker on LinkedIn.  The other is to visit my website, PMEssentials.us.  I’ve been writing articles on project management for over eight years now. I’m coming up on a hundred articles.  And so those are great articles for people to review. I also have my upcoming webinars and classes that I’m teaching.  So that’s another great way to catch me.

BILL YATES:  You’re a busy man.  And you are also a recurring guest on Manage This.  And we appreciate that.  It is such an honor.

ALAN ZUCKER:  And I’m also a very happy Velociteach instructor.

BILL YATES:  Yeah, it is such an honor to have you on the instructor team.  Your excellence in the classroom and your connection with students is always something that inspires me.  Thank you for being able to address this with us today.  Figuring out how to apply agile principles beyond IT I think for many people is this big black box of confusion and fear.  And you just open it up and explain it very straightforward.  The examples that you give are spot-on.  And so we appreciate your contribution.  Thank you for your time.

ALAN ZUCKER:  Bye-bye, thanks.

Closing

WENDY GROUNDS:  That’s it for us here on Manage This.  You can visit us at Velociteach.com, where you can subscribe to this podcast and see a complete transcript of the show.  You have also just earned your free PDUs by listening to this podcast.  To claim them, go to Velociteach.com, choose Manage This Podcast from the top of the page, click the button that says Claim PDUs, and click through the steps.  Until next time, keep calm and Manage This.