AGILE VS TRADITIONAL? Breaking the False Binary with Alan Zucker
Host: Kumar Dattatreyan
Guest: Alan Zucker
Kumar Dattatreyan: Hi, everyone. Kumar Dattatreyan here with the Meridian Point. And today I'm really pleased to introduce to you and my audience, Alan Zucker, who brings over 25 years of Fortune 100 experience where he has led agile transformations for over 170 project managers and delivered thousands of successful projects using both agile and traditional project approaches. After pivotal roles at MCI Communications during the telecom revolution and Fannie Mae during their transformation, he founded Project Management Essentials in 2016. Alan bridges the worlds of traditional project management and agile, authoring over 150 articles and teaching at UVA and University of Georgia. He's passionate about intentional hybrid approaches that focus on what works rather than dogmatic frameworks, bringing practical wisdom from managing multimillion-dollar programs to help organizations navigate today's evolving landscape. So without further ado, let me invite Alan to the stage. Hi, Alan. It's great to have you on.
Alan Zucker: Great to be here, Kumar. Thank you for inviting me.
Kumar: Of course. Yeah, this is going to be a good conversation. Actually, you and I have known each other for quite a few years.
Alan: Yeah, probably a decade or so.
Kumar: Yeah, at least 10 years. I know we didn't work together while at Fannie, but I knew of you, and I think you knew of me when I was there.
Alan: Well, you were part of the Agile COE, so you probably had a lot of other people that you were focusing on, but I remember you very well.
Kumar: Yeah, it's interesting how the circles that we travel, we tend to bump into each other quite often. You know, you've described MCI, that's one of your earlier experiences, as fierce, competitive, entrepreneurial, and agile, a decade before these concepts were codified. What made that culture so special and what lessons from that disruptive upstart should today's organizations remember?
Alan: So it's funny. Probably if you're under 35, you have no idea what long distance phone calls are. But for those of us that are older, long distance, you know, back until the mid-80s, there was one company, Ma Bell. And MCI just upended that entire industry. And it was a startup. It was disruptive before the internet. In fact, we were one of the big internet startup companies. And I think there was a lot of things that made MCI special. One is this idea that our role was to disrupt telecom, to knock over AT&T and the seven baby bells, as they ended up being. And it created a culture that was entrepreneurial. It was risk-taking. The idea that we could break into the telecom market was one thing, but that permeated the entire culture. And I remember at one point we were updating the employee handbook and people were invited to provide input to it. And one of the call-outs that I submitted that got published was, you know, the great thing about the company is that on any given day, anybody could do something amazing. And it created that culture where people at all levels of the company were empowered to do amazing things. And it was fun. It was internally very competitive in a good way in terms of finding the right solutions and getting things done.
Kumar: I think that's probably a common thread with companies that are disruptive in nature, right? Is that they tap into the talent of the people that work in the company, empower them. And that word is also interesting—it's as if when you go work for a company your power is stripped from you and it's somehow not yours anymore. And the companies that manage to not make that so, that you know you have your own agency, you have your own voice, and we want to hear it—those are the companies that tend to be more successful and disruptive. Would you agree?
Alan: Oh, absolutely. One of my favorite stories, and when we talk about empowerment to me, a way we show empowerment is through decision-making. And we were getting ready to launch, we were entering a partnership to launch long distance service in all 48 continental U.S. states. And I was senior manager in the finance department. I ran the financial reporting systems. And my boss was the director of accounting. And she said, here's this product description. Go to this meeting. Find out what it's about. And so I went and I explained it to her. And we were working with a vendor. I said, should I assume we're going to get our reporting from the vendor or do we build our own? That was the only question that I asked her. She's like, we should build our own. You know, we did it. And that was crazy because we signed the MOU right before Thanksgiving, full national launch in April.
Kumar: Wow. That's pretty rapid.
Alan: Yeah. Well, but that was what we were used to. And the company also did not have a top-down management structure. It was really a network structure. And so, you know, people who knew we had all worked together and we knew how to organize and get things done. And it was the first time we ever established a PMO for a big project. And there were just three people and they were really mostly making sure that everybody was coordinated and attached to each other.
Kumar: Yeah. So you were lean and agile before those were really terms that people understood to mean anything. I want to go to this question from the audience, right? From Strategic Bravery Coaching. I don't know what your name is, sir or ma'am. If you would leave your name, that would be amazing also. And you're right. Many with agile experience have been laid off. Where do we go from here? And in some ways, and not to pivot completely from the topic, we're talking about disruption. And in many ways, agile is being disrupted. By what, I'm not sure, but agile is being disrupted. So this is a good question. Where do agilists—and I will just share my experience in a minute—but I wonder what you might have to say to this person. Where do we go from here?
Alan: That's a great question. And it's actually one of the things that I started talking about and actually spoke at the Dubai International Project Management Forum about back in January—this notion that we need to start talking about project management differently. And I think that if we go back to the early 2000s, even into the, you know, 2010s or so, there was a sense of like, we've got our traditional ways of managing projects and we've got agile. And there was this rivalry. I mean, let's let's be honest. We saw that at Fannie Mae. And I think what we ended up seeing was there was a lot of bad agile. And one of the articles I wrote is don't blame agile for bad agile. And I think we saw, you know, one of the things I saw is that a lot of organizations would completely invert the first value statement—individuals and interactions over processes and tools—and they implement agile processes. We have daily stand-ups. We've got a Kanban board. We haven't changed the way we work. And I think that project management really is at another inflection point. And, you know, I feel bad for a lot of folks. You know, we had a lot of friends, you had a lot of friends probably as well that have been let go that were scrum masters or agile coaches. And I think that the things that we provided in terms of building culture, helping teams needs to transform a little bit. And I'm not sure what that next wave is. One of the things that I've been writing about that I'll be speaking about at the University of Maryland PM Symposium in May is this idea of going back to basics, looking at the things that we know that work, looking at hybrid as a way of how do we blend our traditional and our agile practices for what makes sense for the given projects that we're on?
Kumar: Yeah, I think that's really useful because today I and some of my colleagues are supporting a big client and their transformation to these agile ways of working. And I feel it. I feel the tension between the more traditional and the more agile, you know, ways of working and the practitioners and leaders that are in those different camps. And really what I found, and I'm curious to see what you think, is that if you're too dogmatic about it, then you can't really find a common way to work together. It's got to be, you got to use what works best for you and your situation and your organization. And I feel like that's something that I've kind of learned over the last, especially since the pandemic, because, you know, prior to that I was very into the deep sort of Scrum methodologies and stuff like that. And then working with a bigger client and watching what they're trying to do and realizing that there's pockets where that stuff will work and other places where it won't. And so being pragmatic, but at the same time still finding a way to incorporate value-oriented thinking, breaking things into smaller chunks, making sure that you're validating and getting feedback loops in place to make sure that you're moving in the right direction, you know, all those things, whether you call it agile or not, you know, those things make sense. And I think that that's where we're starting to head back to, right?
Alan: Yeah, you know, and I think, I think, you know, you talk about breaking work down and just thinking about that from a value perspective. And I mean, we were doing that at MCI 10 years before the Agile Manifesto. And it was almost like, well, of course you'd break the work down into small chunks and organize around those. And it was just, it was like, yes. And so it's funny because once the Agile Manifesto came out, it's like, you know, I had one friend describe it. He said, I read the Agile Manifesto and it was like, oh, so this is what I've been doing.
Kumar: Yeah, yeah. I mean, that's true for so many of us that have been involved in agile and project management is that, you know, those things make sense. You know, they make sense to the people that are more pragmatic and are looking at ways to do things efficiently and so on. Before I got into IT and technology and all that stuff, I used to run restaurants.
Alan: Oh, really?
Kumar: Yeah, and I like to tell people that's where I learned how to be agile because you have to. You have no choice, you know. You're coming in the door every day, every minute of every day, and they expect service, quality, and experience. And if they don't get those things, and the product life cycle in a restaurant is in minutes, not weeks or months or years. It's minutes, right? And if they don't get those things, they're not going to come back.
Alan: Similarly, like, I joke that my first agile experiences—my master's degree is in economics. And out of graduate school, I was working for a small consulting firm doing EPA and OSHA work. And the guy I worked with was a senior economist, really smart guy. And we had to build a model. And we did it in Lotus 1-2-3 Release 1A. And I didn't know anything about Lotus. I learned it on the fly. He had done similar kind of work, but never in this industry. And I, you know, started off with a simplistic model. And then we built it and built it and built it. And I'd show it to him probably half a dozen times a day sometimes. And it was the iterative and incremental development approach.
Kumar: Yeah. Yeah. I learned about agile when I—one of my first, I was a PM actually for a company. And I had two small teams that I was working with. And one of my developers actually gave me this book called The Agile Primer. And I remember reading it thinking, oh, this is what we used to do in restaurants. Yeah, we should do that here. It makes sense. Let's do it. And so I convinced my boss to get some consultants to come in and help us sort of convert. And that's how it started my journey. But back to the podcast. The Disruptor Method, we created that about four years ago. And around the same time, we started this YouTube channel. And when we first started the YouTube channel, it was really about just getting out there and me and my partners talking about agile topics, you know, like a lot of people do. And we quickly tired of that because it's like, you know, there's only so much you can talk about that hasn't already been talked about. So especially my partners got tired of it.
Alan: It's funny you say that, because I was thinking, like, I used to listen to the Agile Uprising podcast, and I think they've become less and less frequent, and the freshness of the topics is less so much.
Kumar: And so what I thought I would do is let's explore sort of instead of agile and lean and all that stuff that may turn people off because they had a bad experience with it, I decided I'm going to shift the focus of this channel from agile to disruption, innovation, the relationship between those two things, right? So when there's disruption, you usually have innovation, and if you don't have innovation, then the disruption is going to disrupt you, and you're going to be out of a job or your business, right? And so using that as a theme, I've been sort of reaching out to people in my network and outside of my network to get their stories of disruption and innovation. I'll interview them. So I don't just speak with agile people. I speak to all sorts of people from all walks of life. So I had a relationship coach on a few months ago. He calls himself a parent coach. So he coaches parents of autistic kids. And what he's trying to do is bring behavioral science and coaching together and sort of help these people provide the best possible future for their children. Fantastic. I want that on my show, you know?
Alan: That's great.
Kumar: Yeah. So what I do is usually use this time to, as you can see, I'm recording this conversation, is to probe into your background and things that you're passionate about and come up with a set of—besides biking and hopefully not falling and breaking your wrist.
Alan: And come up with a set of topics or a set of questions around a topic that we can riff around. So, really interesting, you know, when you talk about disruption, you know, one of the places, you know, I worked at MCI Communications back mid-90s to early 2000s. And MCI was an amazing place to be. And, you know, talk about a company that completely changed telecom. I mean, you're probably old enough to remember having an MCI calling card or, you know, even before that, you know, you'd make a long-distance phone call and be like, talk quickly. You know, your parents would be like, talk fast because it's so expensive. And, you know, it was a real, it was a fun, innovative, cool place to be. And, you know, there we were agile, we called it—it's called a modified waterfall, but the product development team was launching a new product every two to three months. And I was running the financial reporting systems and no one's going to be waiting for finance to do a product launch. And so it was like, you know, we learned the pattern of these are the things you got to launch the first month in terms of reporting at the end of the, you know, or the points, the day it's launched, the first month, the second month, et cetera. And that was really, it was just a really interesting organization, interesting corporate culture. And it's funny because I, you know, in a lot of the things that I write, I keep going back to that in terms of thinking through like, you know, what were the patterns that we had? And, you know, I always compare things to it. Like when I got to Fannie Mae, I absolutely felt like a fish out of water because, you know, at MCI, there was minimal structure. And, you know, when I got to Fannie Mae, there was just a ton of structure. I was like, we were more effective. I mean, I probably had a 90% plus, you know, success rate for the projects that my teams managed. And then I go, you know, I go to a big lumbering company where we spent a lot more for resources. And we probably had close to the industry benchmark of, you know, 30%.
Kumar: If you're lucky, on a good day.
Alan: Yeah. I mean, that's interesting.
Kumar: So more process, more—I mean, not interesting. I mean, obviously it makes sense to me and obviously you're in it. It may make sense to other people that are sort of not in that field that the more bureaucracy, the more process you have, the less efficient value can flow through the organization and get released to where it can be used, right?
Alan: So I think there's a couple of things. In fact, one of the articles I wrote about two years ago was Simple Rules for High Performing Teams. And right now I'm drafting up sort of a deep dive into one of the rules, which were—my three rules were psychological safety, empowerment, which is pushing decision-making down and making it simple. And I would argue that when those closest to the work make decisions, they're better decisions. And as a manager, I was the senior manager of the finance systems group. And at a certain point, my group was outsourced to EDS. They're like, Alan, you need to start approving releases. I'm like, how come? Because that's what EDS says. I'm like, I don't—no, we haven't done, you know, we've been working together for the last five years. I haven't approved anything. I'm not going to start now because then we'll just start blaming each other when things go sideways. And my PMs who wrote the requirements, you know, were involved in the testing, worked with the dev team, they approved the releases. I never got involved.
Kumar: Interesting. We were effective.
Alan: And I think that when you have successive layers of approvals, you know, sort of like where we, not sort of, where we had at Fannie Mae, I don't have to—it diffuses the responsibility.
Kumar: It also results in a lack of psychological safety because, you know, the person that's on the low end of the totem pole, they have to get approval from their manager who has to get approval from their manager. And it's like, just make the decision. I don't even consult me. I don't want to, I don't—just tell me what to do. Right.
Alan: Well, the thing is, if as it moves up the chain, everybody's just signing off based on what the person below them said.
Kumar: Yeah. Yeah, exactly. And it's like, well, I'm not, you know, if I'm the lowest man on the totem pole, it's not my decision.
Alan: Yeah.
Kumar: Well, it probably explains why engagement rates are where they are, you know, employee engagement. Engagement rates are in the high 30s, meaning that over 60% of employees are not engaged in the work.
Alan: I actually just finished reading a fascinating article. It was in the last month's Harvard Business Review.
Kumar: Yeah.
Alan: I'm just pulling it up real quick. It's called To Change the Culture—I'm sorry, To Change Company Culture, Focus on Systems, Not Communications.
Kumar: Yeah, yeah, exactly. And one of the—
Alan: It was, you know, new, but the numbers are fascinating that when leaders talk about change, you know, we'll talk about change, we'll have a change campaign, three quarters of them fall flat.
Kumar: But when they change their behaviors, it increases the trust scores 25%.
Alan: Yeah.
Kumar: You know, the Disruptor Method, it captures a lot of what we're talking about. Because that's really our focus. It's decision making, transparency, visibility of the work, empowerment of the people closest to the work. And part of the Disruptor Method is putting in a very simple system in place to change the way people think about the work. And so we're really thinking more about the environment, changing the system, rather than thinking about what they say, right? It's about what they do and how they change the system in order to allow value to flow. I put a link to the Disruptor Method in the chat there. When you take it, take a look at it.
Alan: There's a quiz there.
Kumar: It's a very short little simple quiz, but I'd love your feedback if you were to take it. Okay, we can definitely talk about MCI and your experience there. I'm kind of also interested in this role that you straddled between traditional project management and agile. Because projects are a bad word in agile circles. I work with a coach who is very dogmatic and thinks that way. I'm like, dude, no, not necessarily. Some things need to be a project. You can't get away from it. And so it's important to be pragmatic, but I haven't gotten through to him yet. So how do you navigate that world? And how do you—I mean, is it that you straddle these worlds because of your success in being able to navigate that? Or is it sort of, maybe we can talk about—
Alan: I think for me, it was very organic. I was self-taught as a project manager. I mean, I started managing projects back in the late 80s when the field was very, very young. And I didn't have a lot of structure being imposed on me from above. So a lot of what we would today call agile techniques—collaboration, doing design, build, getting feedback, iterative work—all just made sense to me. And so, you know, and then my experience, you know, when I was doing that modeling work, and then when I was at the Treasury Department, we built a mission-critical application by doing screen prototypes. And I didn't know that it was not a good thing to do. We had a really big—so I was running the Treasury security auctions, and in the wake of the Salomon Brothers bidding scandal, I was asked to be Treasury's project manager working with the New York Fed to automate the auctions. And so I go to New York, and the guy that's my lead developer, and this is back in the 90s where you're wearing suits and ties and suspenders, and my lead developer was wearing suits and ties and suspenders and had a ponytail going down his back. He's like, well, I found this really cool screen prototyping program, and this is how we're going to build the application. I'm like, sounds good to me because I didn't want to be writing requirements for the next six months. And we had the application essentially built. And we were in test within six months.
Kumar: That's amazing. And then I'm like, I love software.
Alan: I love project management. I went to MCI. And again, MCI was like, get it done. And so I learned some methodology. We did RAD, rapid application development, and that as a methodology sort of fell flat. But we modified the things that we did. And then when I started teaching, when I was at Fannie Mae, I learned about agile as a formal framework or methodology. And I'm like, this is what I've been doing all my career. And then when I started teaching, when I put together my own course material, I always sprinkle in, you know, agile material along with a more traditional view. And as I've begun to sort of, as I've begun to think things through more, you know, I've started to, and I don't like the word hybrid, but it's, you know, it's really the idea that we need to use things that make sense. And so I actually wrote an article, I don't know, a couple of years ago now, I call it the Milestone Kanban Scheduling Technique. And rather, you know, because nobody does a good Gantt chart. I mean, maybe there's a handful of people that do a good Gantt chart. Everybody bastardizes that. So it's like, most of us know where those big milestones or deliverables need to be. Think through your deliverables, create a roadmap, and then start managing the work using Kanban boards. And, you know, progressively plan. Because to me, that makes sense for, I don't know, maybe about—it's 90% of knowledge work. Maybe it doesn't apply to construction, but it certainly applies to knowledge work.
Kumar: Well, I mean, that's interesting because I've been thinking along the same lines as you. The main client I support now is Amtrak, and we're trying to move one of their more infrastructure-heavy teams into an agile way of working. And their projects last, in some cases, years. It's not something you can do in a two-week sprint, right? You can't turn out anything in a two-week sprint. And so that's very similar to what you just said. Sort of take the high-level milestones, and those are your epics, if you will, in SAFe language. And the smaller deliverables might become your features, and a lot of the work is outsourced. It's given to vendors, but in terms of internal tracking to see where these things are in relation to your overall roadmap, a Kanban would give you a lot of visibility into those features that somebody is working on, you know, whether it's a vendor or whatever. And if it happens to be the team internal to Amtrak that's doing the work, then it gets decomposed further and those stories get worked on by whoever's doing the work, you know, whether it's one of the teams. And so, yeah, very much in line with what you're thinking, you know, in terms of anything and everything can be visualized in a way that provides more clarity as to where the work is, what's the progress, what's left to do, sort of to marry these two ways that you might work together. And one of the things that I—I'm sorry that the sun's bouncing off the floor from the hallway there.
Alan: One of the things, about a year, year and a half ago, I was talking to this guy. He was one of the big, a lead developer at monday.com. And he was like, well, throughout the idea, like, how would you start measuring progress in organizations where they're using different approaches? And one of the things I wrote in an article, it's like, I called it Earned Work. And it's sort of the idea of, you know, earned value, really just way too complicated. But if you look along traditional approaches and you've done some level of breaking the work down, you know, using a WBS, and if you're using features in Scrum, or if you're using things in Kanban, I laid out a framework that, and I actually, you know, played with it, you know, built out a spreadsheet to put it together, that allows you to sort of get a sense of how am I doing, even if I am in an environment where we're using different approaches.
Kumar: Okay. Okay. Yeah, makes sense. Okay, so I'm trying to hone in on some topics. We can certainly talk about that, sort of the line that you straddle. What about you personally? I mean, you've seen a lot, done a lot, you know, in agile space, project space. How have you been disrupted and things that you've innovated around to survive or thrive through that disruption?
Alan: A good story there is, you know, when I was at Fannie, you know, I was managing, I don't know, about 50%, half or so, if not more, of the PMs in the technology org. And I think it was like 2013, 2014. I was like, agile is something we need to worry about. Not worry about—agile is something we need to do something about.
Kumar: Just curious. This was before Dave got there, or this was before Dave became the lead for agile.
Alan: Yeah, this was before he became the COE because we started doing stuff and then we started trying to partner with Dave at the Agile COE.
Kumar: By the way, Dave was my first coach back in the day when I went and got consultants out to help us with agile. Dave McMunn worked for a company called Digital Focus.
Alan: Oh, interesting.
Kumar: Yeah. Yeah, I actually talked to him a couple of months ago. He's out in California. I think like Penny Mac or something like that. He went out there for a job, I think Penny Mac, but I don't know if he's still there. He just retired.
Alan: Okay, that's what I thought.
Kumar: Yeah. Yeah, he moved. Because he originally moved to, was it Taiwan or Hong Kong?
Alan: That's right, yeah. And then got caught in COVID there.
Kumar: Yeah. But there it was like, we need to do something about this. But we are nowhere close to it. And there were folks on the team who had more formal agile experience than I did. And they got together and they said, okay, here's 20 different things that we could do. And so what I said to my teams were like, okay, pick based on what makes sense for you. You know, pick four or five things to implement across, I can't remember the exact timeline, but start picking things to start doing. And we started implementing those things. And then a little while later, you know, I read the, I think it was either Gartner—probably Gartner. They talked about agile accelerators. And I'm like, that's what, you know, we had about a 50% overlap between what we found and what was on the Gartner list of agile accelerators that we did organically. And that really created the runway for the following year where there was just this huge takeoff in terms of let's do formal agile work.
Alan: Right.
Kumar: Cool. Okay. I will definitely bring that up in the interview. You know, is it, there's a difference I think that you and I both see between governance and bureaucracy, right? And I want to just bring that up because I think in our conversation, you know, I think there's big bureaucracies that have bureaucracy masquerading as governance. And I think there's a big difference between the two. What are your thoughts on that?
Alan: I think you're exactly right. I think that there's a big difference between governance and bureaucracy. You know, governance means we have mechanisms to have visibility and transparency so we can manage the enterprise. Bureaucracy is about control. And I think that, you know, you're seeing that bureaucracy is fear. It's about—people are afraid that they're not going to manage what's going on and so they put in more and more controls. And to me, what I've seen is that usually produces poor outcomes. And I think that when you're trying to govern, you're trying to create the mechanisms and the systems that allow you to see what's going on so that you can provide guidance and direction, but not make all the decisions. And there's a big difference.
Kumar: Yeah. Yeah. And I think maybe the bureaucracy is this need to know what's going on because we don't know what's going on because we don't have transparency. And so rather than putting in place a really simple lightweight system to provide visibility, we put in all these processes and gates and checkpoints to give us some comfort that things are moving forward. But in the end, it doesn't really give us the information that we need to manage the enterprise. And yet we keep persisting because we can point to the process and say, well, we have the process. It's not working? Well, we need a better process. And then we keep iterating on the process rather than actually putting in a simpler, more lightweight, transparent way of visualizing where things are. And that's where, you know, the Disruptor Method comes into play, right? We're focused on that visibility, that transparency, how do we create it in a very simple, lightweight fashion so that leaders can just sort of peek in and see where things are without having to have a lot of meetings and a lot of status reports.
Alan: Yeah. And I think that, you know, to your point, I mean, if you go back to lean principles, you know, we're looking for the simplest things that provide value. And I think a lot of times these bureaucratic structures that we see, they're not providing value. They're just, they're overhead. And so if you can find those simple, lightweight approaches that give you the transparency and the visibility that you need to govern and make good decisions, that's really where the magic is.
Kumar: Yeah. And I think to tie this back to sort of the disruption and innovation theme, I mean, agile being disrupted. Well, and one of the comments that you made earlier is that agile has been disrupted by bad agile, right? And so organizations that have implemented these processes without changing the underlying system or culture, they've created this, they've killed agile essentially. And now people are like, well, agile doesn't work. And it's like, well, no, you didn't do agile. You did ceremonies. You didn't change anything else. And so now we're at this inflection point where, you know, back to basics is sort of the rallying cry, I think, to say, let's get back to what actually works and stop worrying about what we call it.
Alan: Yeah. And I think that, you know, the other thing that I think we're seeing is that a lot of the complexity in organizations is driven by silos. And so when you've got functional silos and product silos and geographic silos and all of these different ways that we organize ourselves, we create interfaces between them. And those interfaces require coordination. And that coordination requires process. And so part of what I think we need to do is think about how do we organize in ways that reduce the number of interfaces? How do we create more autonomous teams that can deliver value end to end? And I think that's part of the back to basics conversation as well, is thinking about organizational design and how that enables or inhibits our ability to deliver value.
Kumar: Yeah. And that's exactly what we're trying to do with the Disruptor Method is create these cross-functional teams that can deliver value end to end. And, you know, part of that is breaking down those silos. And it's hard, right? Because organizations are set up with these functional silos for a reason. They've been around for a long time. But I think that, you know, as we're trying to move faster and deliver value more quickly, we have to find ways to organize that allow us to do that. And that means breaking down some of those traditional structures.
Alan: Yeah. And I think that, you know, one of the things that I've been thinking about a lot lately is this idea of how do we create more fluid organizations? You know, where people can move between teams more easily, where teams can be stood up and stood down based on the work that needs to be done, rather than having these permanent structures that we then have to figure out how to coordinate between. And I think that's part of the future of work, is thinking about how do we create organizations that are more adaptive and more responsive to the changing needs of the business and the customers.
Kumar: Yeah. And I think that's where, you know, the technology can help, right? If we've got good systems in place that provide that visibility and transparency, then we can be more fluid because we can see what's going on and we can move people around more easily. But without that transparency, it's really hard to do that because you don't know what's going on. And so you end up with these rigid structures because that's the only way you can manage it.
Alan: Yeah. And I think that's a great point. And I think that, you know, as we think about the role of technology in enabling new ways of working, I think it's not just about the tools that we use to manage our work, but it's also about the tools that we use to communicate and collaborate. And I think that, you know, the pandemic forced a lot of organizations to adopt new tools and new ways of working. And I think some of that has been really positive. But I also think that we've lost something in terms of the informal communication and the serendipitous interactions that happen when people are physically co-located. And so I think part of the challenge going forward is how do we recreate some of that in a distributed or hybrid environment?
Kumar: Yeah. And I think that's a really important point. And I know we're running a little long here, which is okay. This is a great conversation. One of the things that has happened over the last, since the manifesto was written anyway, the last 25 years is we've become less connected rather than more connected, right? And especially since the pandemic, where most people are working remotely. And your example of just being able to go walk up and down the stairs to meet with your business counterparts, today it's a call over Teams or Zoom or whatever with cameras that may or may not be on. So there's another layer, another barrier to collaboration and communication that we have to contend with. How do you think that is affecting our ability to, forget agile, just conduct our work?
Alan: I think it's made it a lot harder. During the pandemic, I was interviewed for Tufts Business School, and they were looking for people to talk about agile leadership. And the last question was, what do I think about remote and hybrid? And I said, it'll be really interesting in five years to see the companies that brought people back in versus the companies that remain remote and hybrid. It's not that you can't be remote or hybrid. It's just, to your point, it adds a whole other level of complexity of communication and relationship building. And not to overuse the word intentional, but we need to be much, much more intentional about creating relationships when we don't bump into each other at the coffee machine or in the cafeteria. And I think that's been the challenge.
Kumar: Yeah. Another question from Taz. Taz is on a roll here. And this is a good question, though. It's like for all the people that are agilists that have, you know, I was a PMP at one point, but I let my certification lapse. In your intentional hybrid model, would it be wise to brush up on or learn project management skills to complement the skills that you already have? And why?
Alan: Yeah. So PMI, yes. The short answer, yes. PMI just last week published or released the PMBOK version 8. And I haven't gone through it with a fine-tooth comb, but I'm actually pretty impressed with that current version because it moved away from this rigid process perspective, which was editions one through six. Then version seven was these very lofty principles. So it's refined the principles down to a half dozen principles. But then they talked about the things that we need to consider, you know, just a very basic process perspective. And it's not perfect, but, you know, it creates that structure. And I think it's much closer than anything we've seen to date in terms of how do we just talk again about project management versus traditional versus agile versus lean versus—and I think we just need to get back to that. We're managing projects. We need to use the skills that make sense for the type of project that we're doing.
Kumar: Yeah, makes sense. Yeah, some would argue that project is a bad word. We shouldn't call them projects. What would you say to those people? And the reason they might say that is because projects have a definite beginning and end and an agile team just stays together. You know, they're just working on whatever the next thing that has value as determined by, you know, call it a product owner, call it a product manager, whatever it might be.
Alan: Gosh, you know, languages are great because it gives us a common way of communicating, but then words take on other connotations. You know, like I, if you don't like the word project, that's fine. I just, I'm missing a word that I would put in place of it to describe what we do. You can't call it work. Let's just do the work. It's not descriptive enough, right? So yeah, language is definitely can be an ally and also can be a constraint sometimes because we don't have the right word for things.
Kumar: Anything I didn't ask that you'd like to share, Alan?
Alan: I think it's been a wonderful conversation. I mean, I, you know, I'm looking forward to, you know, as I'm beginning to pull out the threads or tease out the threads of this idea of back to basics. So folks want to go to my website or follow me on LinkedIn. I'd be happy to have that because I've been publishing those updates about, you know, once a month, usually the beginning of the month. And I'd love to get feedback on that just so that it's an inclusive perspective.
Kumar: Yeah, that's awesome. Yeah. And I, you know, for those of you that want to reach out to Alan, he teaches often. He teaches at UVA, University of Georgia, but he does a lot of his own stuff as well. And I think that as you sort of put together your thoughts around this hybrid model, intentional hybrid, that may be something that I'd love to have you back on the show maybe to talk about a little bit more. I'll include his information. I think it may already be in the description of this talk, but I'll make sure that if it's not, that you have the information so you can get a hold of him. And Taz, thank you so much for being such a prolific commenter. She asked, am I the only one here? And you're not. There's others watching this on LinkedIn and YouTube. And unfortunately, the Facebook stream didn't work for whatever reason. But there's many others. But you're just the most chatty, which I really, really appreciate. So thanks again, Alan, and thank you all for watching. Have a happy holiday this week, and we'll see you next week.
Alan: Thanks a lot.
Kumar: Bye, everyone.
---
END OF TRANSCRIPT
