NICK WALKER:  Welcome to Manage This, the podcast by project managers for project managers.  Every couple of weeks we meet and discuss what matters to you as a professional project manager.  We get into the nitty-gritty, the real stuff of the job.  And we do it by talking with some of the greatest minds in the business, people who have seen it all and lived to tell about it.

I’m your host, Nick Walker, and with me are two guys who will be the first to tell you that yes, you can live to tell about it:  Andy Crowe and Bill Yates.  And Bill, we here at Manage This have reached a milestone and lived to tell about it.  We’re celebrating our 50th podcast today, and there’s no sign of stopping.

BILL YATES:  Isn’t it amazing?  Fifty.  To go back and look at the conversations that we’ve had, it’s just amazing that we’ve piled up 50 of them.

ANDY CROWE:  When you’re married, you have a golden anniversary at 50.  So maybe we should think about that.

NICK WALKER:  We’re golden, yeah.

ANDY CROWE:  Yeah.

NICK WALKER:  Well, to help us celebrate, we have in the studio today someone close to the heart of the Velociteach organization, and with good reason.  Alan Zucker has more than 25 years of experience as a leader in Fortune 100 companies.  He has delivered thousands of successful projects for them and managed multimillion dollar programs with hundreds of resources.  In 2016 he founded Project Management Essentials to provide training and advisory services.  He holds numerous certifications.  He’s a certified project management professional, is an ITIL Foundation certificate holder, a Scrum Master, a scale Agilist, and an Agile-certified practitioner.  He’s frequently called on as a keynote speaker and is also an adjunct professor at Northern Virginia Community College.

Alan, welcome to Manage This.  Now, you are knee-deep in a world that for many is probably still a little foreign.  I’m talking about the world of Agile practices.  And I need to confess right off the bat that this world is not just outside my playing field, but it’s on a different planet from my playing field.  What is it about Agile that makes it so different?

ALAN ZUCKER:  You know, I think the really interesting thing about Agile is, if you step back, it’s sort of how we learned to play as kids.  You know, when we were kids, you’d go to the beach, and you’d make a sand castle.  You wouldn’t, like, yeah, maybe draw a couple lines in the sand and say “This is where we’re going to be,” and “This is where we’re going to digging.”  We didn’t have detailed plans.  And you just start building.  It’s like, yeah, I like that.  Let’s build a little bit more over here and a little bit over there.

And that’s sort of the way Agile is.  And I think there’s a real natural rhythm to Agile.  And I think that particularly, when you look at traditional project management Waterfall, it became very rigid and became very highly structured, and it really wasn’t effective in terms of particularly developing software, which was really most of my background.

NICK WALKER:  So if Agile is the way you describe trying to get into a kid’s mind, it seems like it might be intuitive.  Have we sort of learned to not be like a kid anymore?  Have we grown up too much?

ALAN ZUCKER:  You know, I think so.  I mean, I go back, and I think about my own experience.  I came to project management – I have a master’s degree in economics.  And my first job out of school I was developing a model for a company, developed it in Lotus 123 Release A, a million years ago.

ANDY CROWE:  Wow, we’re going back.

ALAN ZUCKER:  I’m older than Bill.

BILL YATES:  Barely.

ALAN ZUCKER:  And, you know, the way Bill did, I was working with a guy.  I was an economist.  I was working with a guy who was a senior economist.  And I’d build a little bit, and I’d show it to him, and I’d build a little bit, and we’d fix it, and we’d test it, and I’d learn new functionality, and I’d build that in.  And that’s how I learned to manage my first project.

And then when I had my first real job, I had a job at the U.S. Treasury.  And I was managing the Treasury bill, note, and bond auctions.  And this happened to be when Salomon Brothers decided to cheat on the auctions.  And I was working with the Federal Reserve Bank of New York to automate the auctions.  And there I was, in my late 20s, as the Treasury project manager.

And we built that project, or we developed that application, this is back early ‘90s, mainframe application, using a lot of Agile  techniques.  We used prototyping.  The guy that was the lead developer at the New York Fed had a screen prototyping program, and we’d draw all up the screens.  And then he’d have me look at them.  And then he’d program a little bit, and we’d test.  And we built that application in less than six months, which for the Federal Reserve and the Treasury Department is land speed time.  Got a little bit hit up by the General Accounting Office for not following the prescribed process, but we had the application built.

One of the core of Agile is the Agile team.  And you’ve got a self-managing team, self-contained.  You’ve got all of the resources on the team available to deliver the project together.  And there’s a notion of team accountability, and everybody’s bought in.  And they’re committed to delivering this project.  So that’s a big difference.

There’s also the idea that the team is self-managing.  And I think a lot of people really sort of struggle with, well, what does it look like to be a self-managing team?  And I think it’s really the idea that that team feels accountable for that delivery.  They don’t have managers that are micromanaging.  They’ve got managers that are focusing on what can I do to help you get this project done.  And I think those are some of the key things about the team.

ANDY CROWE:  Well, it’s interesting, you just brought up something that maybe makes some project managers’ heads kind of melt a little bit.  Bill, there’s no formal role of project manager necessarily on an Agile project.  And if they are, there’s no project manager on the team, embedded in the team.

BILL YATES:  Right.  And these, you know, you go back to the Agile Manifesto.  It says you’re going to have self-organized teams that are made up of motivated individuals.  So who’s motivating them, if you don’t have a PM going, come on, guys, be motivated?

ANDY CROWE:  Cracking the whip; right.

BILL YATES:  So a part of self-management is this motivation aspect, and the other part of that principle in Agile talks about trust.  So who has influence over that?  If there’s not a PM in that role to create a motivated team built on trust, so who takes care of that in the playground?

ALAN ZUCKER:  So, you know it’s interesting because there’s a big controversy about what’s the role of the PM on the Agile team.

BILL YATES:  Right.

ALAN ZUCKER:  And one of the – an officer at a company that I worked with was like, no PMs.  And it became a real issue.  And even when you read the Agile Practice Guide, they’re very not clear about the role of a PM, which I thought was very interesting.  But I still think that you need someone on the team that’s going to be the team leader.

BILL YATES:  Right.

ALAN ZUCKER:  And it’s not going to – you change the way how you lead the team.  It’s not going to be that directive leadership style, but it’s going to be that collaborative leadership style.

BILL YATES:  Right.

ALAN ZUCKER:  You know, I spent a good bulk of my career, I spent 14 years at MCI.  And telecom was really a great place to be.  And it was an entrepreneurial culture.  And there, as a senior manager, I managed all the financial reporting systems for the consumer business unit.  My boss was the director of the accounting group.  And she would give me very general directions.

One of my favorite projects there – and we were Agile before we knew it there, as well.  Back in the late ‘90s we were entering the local markets.  And my boss gave me about a 15-page product description that had come out; and she said, “Go to this meeting and find out what’s going on.”  And we were going to partner with another company to offer national long-distance service.  I came back from the meeting, told her what it was about.  I said, “I got one question for you.”  I said, “Do I assume that we build our own reporting?  Or are we just going to get the reporting from the vendor?”  She said, “Let’s assume that we’re going to have to – we’ll build our own reporting.”  That was all the direction that I needed and I got.

At MCI we had – that was the first time we had a PMO for anything.  We had three people in our PMO.  But the way we got our work done, it was all networked.  And people from the different groups got together and figured out how were we going to solve this.  And I think that’s really, when we talk about self-managing, self-motivating teams, that’s really a big piece of it.  It’s, yeah, we had people that had formal leadership roles.  But we knew how to work and play together and get things done without being told.

ANDY CROWE:  You know, one of the real benefits of doing it that way – you triggered a lot of thoughts as you were going through this – is you get the decision-makers and the key stakeholders together, embedded in the team, and they resolve problems there on the spot.  Whereas one of the problems in a Waterfall project, especially in a really bureaucratic organization where people aren’t empowered – and that’s a key to Agile teams.  They’re empowered to make decisions, to prioritize things.  You do it in an organization where people are not empowered, and you do this traditional model, things have to get escalated up.  Somebody’s worried about making a decision.  They don’t feel like they have the authority.  So they escalate it up another level.  People spend their entire lives in meetings, going through lists of things and trying to make decisions, when really the team’s perfectly capable of making a good decision and living with it, if you’ll just empower them.

ALAN ZUCKER:  Yeah.  I think that is really – the empowerment of making decisions and trusting people to make those decisions is critical.  And it’s the people that are on the team that know best.  You know, a director, a VP, they don’t know all the nuance and all the detail.

BILL YATES:  Right.

ANDY CROWE:  Yeah.  And the thing is, the team can represent the team’s interest.  The team can have the customer embedded, and they can represent the customer’s interests, and all of those things.  I agree.  I don’t know, I wouldn’t know, I wouldn’t say that directors and VPs – they have a different perspective.  They have their perspective.  And they don’t need to be gummed up with those tactical decisions.

ALAN ZUCKER:  Absolutely.

ANDY CROWE:  They need to have somebody they can trust.

ALAN ZUCKER:  Yeah.  No, I agree.  And really I meant it’s the detail, the details of the nitty-gritty of how the process works.  And I think the other big piece, and you brought it up, and we should have brought it up earlier, is the notion that the customer is actively involved and engaged in the team; that the product owner is sitting there every single day with the team and helping make those small decisions.

BILL YATES:  That’s so key.  I think of projects that have struggled that I’ve been a part of in the past.  And if you do the root cause analysis, one of the key factors that falls out is we couldn’t get the customer’s time.  They were not available when we needed to have key decisions made.  We were having to make decisions in the dark and make plans in the dark.  So that element of an iterative or Agile approach is very appealing to me, given some of the experience that I’ve had with some past projects.

ALAN ZUCKER:  Yeah.  And when we went through an Agile transformation at one of the companies I work with, we had someone that, before the transformation, she was on the business side.  She was the requirements analyst.  She wrote the business analysis.  She wrote all the requirements.  She was always frustrated.  She’d, like, write the requirements.  She’s like, “Those darn guys in IT, they don’t understand what I want.  They’re just….”

ANDY CROWE:  Right.

ALAN ZUCKER:  We did the Agile transformation, she became the product owner.  She’s sitting with the team.  And she’s like, “You know what, it wasn’t those darn programmers that didn’t understand.  My requirements weren’t that good.”

ANDY CROWE:  Right.

ALAN ZUCKER:  And she became one of our leading evangelists for the transformation as we moved into other groups because she saw how that collaboration between her as the business owner and the development team made such a huge difference.

NICK WALKER:  As the outsider here, let me jump in with a question.  It seems to me that maybe, with Agile, there might be more potential or danger of conflict or disagreement among team members.  I mean, on the playground, if you don’t like what’s going on, you can take your toys and go home.  But you’ve got to work things out, those conflicts out.  Is there more potential in an Agile situation with conflict among each other?

ALAN ZUCKER:  Well, it’s funny.  A good friend of mine who’s from the great state of Texas said that his father would define conflict as a county where there was at least two people.  In everything we do there’s going to be conflict.  It’s how we manage the conflict that matters.

And one of the really good things that you do when you set up an Agile team is you set up, at the beginning, you set up your rules of behavior, your rules of normative behavior.  And everybody agrees this is how we’re going to work as a team.  You set up how we’re going to resolve conflicts, how we’re going to handle differences.  Are we going to show up at meetings on time, or are we going to show up at meetings habitually five minutes late?  And setting those things up explicitly and getting the team to be self-governing with that is really an important part of how do we handle our conflict.

BILL YATES:  Alan, this reminds me of some of the past conversations that we’ve had.  And you’ve described, I think it was at MCI, you talked about an element of the culture that was there that you really enjoyed, which there was a lot of emotion; right?  There were times when you guys would be very passionate in meetings about a technical decision or should we go this way or that way.  But you said at the end of the day, you know, you guys would work it out on the playground.  Everybody stayed.  They kept their toys there, and you guys got stuff done.

ALAN ZUCKER:  Yeah.  I remember one of the projects we were working on there, and we were trying to do an integration.  And it was between the consumer and the business market side.  And about five or six of us locked ourselves in a conference room.  It had this huge whiteboard.  And me and one of the other guys went up to the board.  And he was writing stuff up, and I was erasing it.  And then he’d draw stuff.  And we had developed a relationship over the years.  And we got out of there in about an hour, and people were like, “Wow.  That was a lot easier than I thought it was going to be.”

But you’re right, we had a culture there where we would go toe to toe.  We’d be mud wrestling out in the courtyard to figure out what the right answer is.  But afterwards we’d be hugging and moving on because we came up to the solution.  I’ve been in other environments that are more structured, more bureaucratic.  And we didn’t fight.  We didn’t have aggression.  But we never made decisions, or the decisions were made in the break room either before or after the meeting.  And so it was a way – it’s how you manage conflict and what that culture that you have to get you there.

ANDY CROWE:  I used to work, Alan, with just a stereotypical – I know this is going to probably get us some mail – a stereotypical Philly guy.  And his style of negotiating with me was, “I’m not winning if you’re not losing.”  And he was a tough negotiator, but I always walked out of there feeling like I had had to donate blood and body mass in order to get out of the negotiating with this guy.  It was really intimidating.  And then, you know, you do find situations where you can go toe to toe, and then go back, and everything’s okay.  It’s all about how you’re going to reach consensus, what does that mean is a lot of it, yeah.  A lot of this group decision-making techniques.  That’s something Agile’s given us a lot of.

One of the interesting things that I’ve found with Agile, and this is a true philosophical shift from the way that I was brought up doing things.  The way I was brought up doing things is you assemble a team of specialists, and each person knows their way.  It’s like an old World War II movie, or what was it, “The Eiger Sanction” with Clint Eastwood, you know, where he has to climb the cliff.  But everybody’s got a function and a role.  Or “Mission Impossible,” that’s a good current one, you know, everybody’s a specialist at something, explosives and hacking and espionage.  Agile doesn’t really do it that way.  They have a kind of a different approach.  Talk to us about that.

ALAN ZUCKER:  So in Agile you really want to have a team where it’s generalizing specialists.  And I think one of the things that we’ve gotten into in IT in particular is that we’ve got specialists, and we’ve got everybody siphoned off in their different groups, and we hand off work through our ticketing systems, and there isn’t that sense of collective ownership or even that sense of the collective thought of, really, what is it that – what we want.  And one of the things when you talk about Lean is imagining the whole.  And when you’ve got a team that imagines the whole, they think about the problem end to end, and it creates greater strength across the team.  I mean, you may not have that same core, that deep sense of I know how to be the best EBA there is.

BILL YATES:  Right.

ALAN ZUCKER:  But, you know, I understand how we’re putting this thing together as a solution.  And you don’t have the handoffs, and you don’t have the frustrations with the handoffs where it’s like, I have this small change, but I’m going to ship it over to this other person and wait for them, wait a couple days for them to execute the command or change the database table or set up the environment for me.  I can do that, and it’s a lot – it’s much more efficient, as well.

ANDY CROWE:  You know, this is one of those areas that I’m struggling to get fully in synch with the Agile community on.  I’m doing an Agile project right now where I’m actually sitting on a team as the product owner.  And it’s an interesting time.  But this idea of generalizing specialists is challenging, and I’ll tell you why experientially.  You go back, way back in time, I was a C++ Windows developer.  And if you go back to around 1994 and ‘5, I knew everything I wanted to know about how to write in Windows, how to write C++ Windows software.

I was a team lead on a project.  And then a guy took me aside and said,  “Hey, you’re going to have to write your own device driver to communicate with the mainframe.”  It was a TN3270 driver, and he said, “You’re going to have to do it.”  And I know more had any idea how to do this.  And I’m sitting back in a room.  We were colocated, and there were five of us.  And nobody knew where to begin.  Early days of the Internet.  We were trying to research this.  And the guy made it sound – he was so flippant about it, you know, “Just write your own driver,” you know, and oh, okay well, you know.

And then suddenly – so we did.  We had to bring in a specialist who knew this stuff.  And this guy, I mean, that was his life.  He came in, he was able to do it.  Now, he couldn’t do what I did.  But there is no way, to this day, it was still a black art, seeing what he actually did and how he did it.  And so there are times – here’s my point.  There’s this idea, if you’re all just working on an application, then yeah, it’s good that you can do some UI work, and I can do some backend work and some communications work and those types of things, and we can cross-functionally fill each other’s situations.  But there are plenty of times when you’re going to need a full stack developer, and everybody can’t be that.

ALAN ZUCKER:  Yeah, no.  And there are times, there are times where you need that specialist.  You need that person that knows specifically how to execute this piece of the tech stack.  And Agile wouldn’t be averse to you bringing that person in.  But the notion that the team has that broad sense is really the key.  And it’s really funny because a little bit after that, when I was at MCI, I was on one of the first groups that was doing a data warehouse.  We were doing a client server, data warehouse, executive reporting system.

I came in, I was starting out as the project manager.  I got involved, and I started doing the data modeling.  And I didn’t know anything more about data modeling than I did about putting a man on the moon; but it’s like, “You’re the data modeler.”  And then I learned how to do PowerBuilder.

BILL YATES:  Right.

ALAN ZUCKER:  And I knew enough to be…

BILL YATES:  Wow, yeah.

ALAN ZUCKER:  Yeah, I knew enough to be dangerous.  But it really helped me work much better with the rest of the team that were doing the really technical pieces.  I couldn’t do all of it, but there were pieces I could do.  And it really gave us a lot more core.

ANDY CROWE:  One of the reasons this is so important to Agile, though, is that the team makes the commitment.  Individuals don’t make commitments.  And the team makes a commitment to a certain amount of work during an iteration or a sprint, and you’re committing to help each other to get there, one way or the other.  And so now you don’t need people in silos, you need people who are cross-functional.

BILL YATES:  That’s so true.  And I think of, as a member of an Agile team, the more that I know about everybody else’s role and what they do, then the better off I am, and the smarter the decisions are that I make.  I think if I’m a pure DBA, and I’m thinking, okay, the easiest way to add this new functionality, I’m going to add three more fields to this table.

Now, they’re all connected to other tables.  There’s all these dependencies and everything.  If I know the impact it’s going to have on Fred, who’s sitting over here in testing, and Angela, who’s got to then document and roll out the plans to the customer, explain to them, it just makes me think through and, okay, who’s going to optimize this?  You know, I don’t care, I’m just going to add fields to the table.  I don’t care about the performance, impacts that it has.  But I need to.  So the more awareness I have of my team members and the impact that it’s going to have on them, the smarter the decisions that I make.

ALAN ZUCKER:  And the other piece is, used to be that if you’re the DBA, you’re sitting on a whole other floor.

BILL YATES:  Right.

ALAN ZUCKER:  Maybe in a different state.

BILL YATES:  Yeah, right.

ALAN ZUCKER:  Now the four of you are sitting in that room.  And if you mess up, if you do something with a table that messes up Fred or Angela, you’re going to know about it by the end of the day.  And they’re going to be like, they’re going to be giving you that feedback.  We need to change our – you need to change your design.  And that’s the other wonderful thing about the colocation of the team and having everybody there, and they’re discussing the issues, and they’re discussing the problems in real-time versus passing design documents back and forth because we just really can’t describe some of that stuff very well in words.

BILL YATES:  There’s a large financial organization that I’ve done some work with, we’ve developed work for and delivered training.  And I had the chance to be onsite at one of their locations up in the Northeast.  And they have blown out all the walls, and now they have collaborative workspaces.  And there’s, yeah, I mean, we all know there’s good and bad to that.  But the beauty is they had, just like you mentioned, they’ve got all the different roles on these subteams that are right there, literally on the same table.  It’s a big long workbench, and they’ve got their monitors up, and they’re looking at their monitors, but they’re also looking at each other.  And they’re seeing when they’re doing things that are impacting positively or negatively their teammates.

ALAN ZUCKER:  Yeah.  It’s really important.  I mean, I remember at one point when I was at MCI, my development team was one floor above me.  And I wore out the treads on the stairs between the third and the fourth floor.  I was upstairs every hour, at least.  When they moved across the street, the level of the communication and the collaboration really went down because we just weren’t talking face to face.  And that collaboration, that face-to-face collaboration I think is really one of the gems in Agile.

BILL YATES:  I’ve got to ask Alan something.  So let’s say I’m a project manager who’s been more ensconced in the traditional approaches.  And now I’m looking at Agile going, okay, I want to figure out some things.  So could I just grab a couple of maybe some checklists or some templates for Agile and just kind of run with it and call myself Agile?

ANDY CROWE:  How does somebody get started; right.

ALAN ZUCKER:  You know, I really think that there’s a lot of training out there.  One of the places a lot of people start is they take their Certified Scrum Master training, which is a two-day course, which is usually a pretty good introduction.  One of the really great things about Agile which makes it difficult is the field is so rich with different points of view.  So I think taking some basic training so you understand the premises of either Scrum – and I’ve actually become a big fan of Kanban lately, and it’s a little bit more difficult to find that Kanban training.

But then, you know, reading.  There’s lots of great books.  I mean, Jeff Sutherland’s book on Scrum is just a great book.  I just worked my way through “The DevOps Handbook” by Gene Kim and John Willis.  That’s a great book.  “The Phoenix Project,” which describes DevOps in really layman’s terms by telling a parable, is also a really good book.  And you start, you know – and listening to podcasts.  I mean, if I can, you know, I listen to, like, Agile Uprising is another really great podcast.  I listen to their podcasts all the time.  Or DevOps Cafe.  And you just start hearing all these different stories, and it really begins to click and make sense.

NICK WALKER:  I’m thinking about my own career in television.  I’ve been in TV a long time.  When I first got into it, we were shooting film for television news; okay?  That’s how old I am.  And we were pretty used to doing it that way, and it was working pretty well.  And then we switched over to videotape editing.  And tough transition in the beginning.  But once we made that transition and saw all the benefits, we said we could never go back.  You know, we’ll never, ever go back to that.  There’s just too many things with the new way.  Have you found that people who have never practiced Agile before and then suddenly are maybe forced into that environment, that they’re saying, oh, I can never go back now the other way?

ALAN ZUCKER:  You know, that’s a good question.  I think that, once you make that transition in your head, it’s going to be hard to go back.  But I think there are still going to be people where they’ve come out of a very, like, engineering-focused background or very, very process-oriented background.  It’s going to be hard for them to make that jump and to really see that benefit.

So I had the experience where we had a team that we took them through the Agile transformation.  We had set up a team room.  Everybody would come together in the morning for the daily stand-up, and then the developers would all go back to their cubes because they were really much more comfortable working alone.  So they were Agile in name only, but they were really not getting that benefit of the collaboration.

So it’s sort of going back to where we started.  You really need to make that mindset change, and you need to feel comfortable with making that change and seeing those benefits.  I was very fortunate.  I was doing Agile before Agile was articulated as Agile.  And to me it makes great sense.  But I’ve seen people that have really come at it from an engineering background, and they struggle because they still think, “I’m a specialist, and I know my thing.  And the most efficient way is to do separation of labor, and that’s the way I was taught.”

NICK WALKER:  Well, Alan, thank you so much for the insight that you’ve brought to all of this today.  We appreciate you being with us here.  We have a gift for you.  We always provide a special gift to all of the people who visit us.  It’s this great Manage This coffee mug in front of you.  It’s rugged.  It will stand up to any playground situation, I think.  So use that in good health.

ALAN ZUCKER:  Well, thank you so much.  And because I knew that you gave out gifts, I have my own gifts for you guys, which are my own Project Management Essentials squeeze toys.  They’re better than stress balls, and I wanted to give a gift back.

NICK WALKER:  I will use this a lot, yes.  Nice.  Thanks again, Alan.  Andy and Bill, as always, thanks for your expertise.

ANDY CROWE:  It’s been great.

NICK WALKER:  And a reminder to our listeners that we try to meet your needs on many levels.  One of the ways we do that is by providing free Professional Development Units toward your recertifications.  To claim them, go to Velociteach.com and select Manage This Podcast from the top of the page.  Click the button that says Claim PDUs and just click through the steps.

That’s it for us here on Manage This.  We hope you’ll tune back in on February 6th for our next podcast.  In the meantime, you can visit us at Velociteach.com/managethis to subscribe to this podcast, to see a transcript of the show, or to contact us.  And tweet us at @manage_this if you have any questions about our podcasts or about project management certifications.  We’re here for you.

That’s all for this episode.  Thanks for joining us.  Until next time, keep calm and Manage This.