Today John examines an article titled “Why project managers need to lose control” by Jason Coghlan from opensource.com. John mostly disagrees with this notion, believing that ownership across the team is more important.

Podcast: Download

Subscribe: Apple Podcasts | Android

Highlights

  • A quick primer on waterfall versus agile software delivery
  • Where I agree with the article and where I think it misses the point
  • Is the project manager really the “last line of defense”?
  • Delays often happen because people or teams aren’t willing to accept full responsibility
  • Plans as a blueprint for success, not a weapon
  • Extreme ownership matters no matter which methodology you use
  • Teams that completely owned the process and dragged me along
  • The real crux of it all is responsibility

Resources

Related Episodes

Credits

All songs licensed under Creative Commons

Transcript

This transcript was created automatically and may contain small errors.

Today I want to talk about an article I came across on opensource.com about a year ago. It’s titled, Why Project Managers Need to Lose Control. Software-driven projects are rarely predictable, so project managers should loosen up and become more agile. Naturally, this title rankled me a little bit. I’m a project manager.

Well, and I’m also a coach, but the project management part of me runs deep. In fact, it runs probably within the first year of my first job in my career, auditing, bank auditing and financial stuff. I don’t think it ever feels good when someone tells you you need to loosen up, although I’m sure there’s people I work with that think I need to loosen up. That’s okay. So, Before I get into this, talking about this article, if you’re not— this article is really focused on software development methodologies.

You don’t have to know, understand, totally understand them to hopefully get something from this. So just as a quick primer, waterfall software delivery is a very traditional software delivery development model where things move in people call phase gates. So before one thing can continue, something else has to end. Typically, a waterfall-driven software release would run over a fairly long period of time, where long is 4 months, 5 months, a year, year plus.

The idea behind waterfall is that you plan everything very carefully, And then you don’t start working on it until you’ve very carefully planned it. Then you develop it, write the software, and you don’t test it until all the development is done. And then you do the testing and then you fix whatever’s wrong and then you release. But the problem with this software model is over this long duration of time, particularly in today’s day and age of cloud software and things rapidly changing. If you develop that slowly and you lock in on things at a very early point and then release them at a very later point, it’s very possible that your product could miss the mark.

That’s waterfall software delivery. Agile software development focuses on the notion of Always releasing. So, much shorter software release cycles. I worked with teams where the software release cycles were as short as 2 weeks or 3 weeks. The idea is that at the end of each iteration or sprint, you have something that’s shippable and releasable to a customer.

If you haven’t, if experienced this, this might sound far-fetched and impossible, but yet it is. I’ve witnessed it. It’s really cool when it works well because you are constantly adding features, releasing them, getting feedback, and building on what you’ve previously done, previously released and done. Sometimes the challenges of agile software is getting started, so sometimes that initial first release is not done in 2 or 3 weeks. It’s done over a series of months.

The most closest experience I have with this is OpenShift. I was there pretty much on day 1 of OpenShift and how that all got started. And there was, there was a period of several months before we did our first public release. And then after that, we were every 2 to 3 to 4 weeks, we’re releasing new features to production that were publicly consumable. One of the key aspects of having, though, successful agile software releases is a fairly robust testing framework, commonly referred to today as continuous integration.

Yes, you’re doing very rapid software development, but you also need to be able to rapidly test that software as well. And that is usually best done with test automation or automated tests. Or if that doesn’t make sense to you, basically instead of someone manually making sure the software does what it’s supposed to, they have written other programs that then exercise the underlying software. So all this to say that I am a huge fan and advocate of Agile software development, particularly when it’s done well. And when it’s done with some level of rigor.

I say some level because there’s an Agile Manifesto that came out many years ago that defines many different things that are supposed to happen with Agile software delivery. There’s also different forms of Agile software development, Scrum.

The other ones are escaping me, but there’s a whole bunch of different ones, Extreme Programming, Anyway, there’s lots of different ones. My experience has been that a team never fully embraces a particular methodology. There’s always some part of it that they don’t like or don’t want to do or doesn’t think applies to them. And then sometimes that’s called Scrum, but, you know, we’ll do this, we’re doing Scrum, but we’re not doing these other things. On the other hand, I have also seen situations where Waterfall was kind of the best option.

And so, if someone came to me and said, hey, John, we want you to be a program manager or project manager for this particular product, we’re going to let you choose the software development methodology, I would choose Agile hands down. So, just to be really, really clear, I think Agile is a better way to go in today’s day and age. On the other hand, I’ve been in other— I have been in situations where I think that waterfall was ultimately best for the team based on the way that the teams are structured, the organizational politics, and the level of responsibility that various team members were willing to take. So going back to this article, I don’t know the author. By the way, opensource.com is run by Red Hat.

So, uh, obviously I work at Red Hat and so there’s some affiliation between me and the website. I don’t know this author. I don’t even know if they work at Red Hat. Um, I don’t know the motivations for the article or where they’re coming from or the context of their software development. So these are just simply my reactions to the kind of the face, uh, the surface level of the article.

So in some ways I think the, the, the title is a little provocative. Um, and, you know, in a way of kind of drawing attention and readership. And so, you know, maybe that’s just built in here and I’m overreacting to that. I don’t know. But I thought that there were some, some assumptions here, maybe that are inherent in the author’s perspective on waterfall software development that I don’t agree with.

And so we’re maybe, maybe we’re just not even starting from the same place. And I just realized I completely failed to note the author’s name. The author is Jason Coghlan, and this article was published on September 21st, 2016 on opensource.com. I’ll link to it in the notes. So quoting from the first part of the article, quote, being accountable for the planning, execution, and delivery of a project is demanding.

Managing people, facilitating communication, resolving conflict, and mitigating risk are prerequisites to completing on schedule and within an agreed And within an agreed budget. Add to this the often unpredictable nature of these factors, and it’s little wonder that project managers feel a great burden of responsibility.

See, I think this is interesting because as I approach the project that I manage, I look at responsibility as completely shared across the team. I have a responsibility to do Everything that I’m accountable and responsible for, and so does everyone else. So now granted, I have worked with project managers that fall more into the camp of it’s all up to them. They, they will absolutely and utterly turn themselves inside out to, you know, get every single team to do what needs to be done to ship the release on time. I’m not one of those project managers.

I will give a lot of latitude for people to kind of do what they’re supposed to do. If anything, I’ll focus all my efforts on trying to make sure it’s super, super clear who’s responsible for what and making sure that they are clear on exactly what they’re responsible for doing and when they need to do it. Again, not based on a schedule that I have prescribed. But based on a schedule that I’ve collaboratively developed with the team. So sometimes this actually comes up in interviews that I’ll do when I’m interviewing a new program manager, and I’ll ask them, tell me about the last time you let something fail.

Sometimes people kind of seem to know where I’m going with this, and other times the question is totally foreign. And what I’m looking for here is, does the person subscribe to the notion that It’s all up to them, that they have to move heaven and earth for a project to ship on time. I think there’s sometimes a place for that, but I think that it is basically a long-term strategy for massive burnout, is to think that every product release, it’s the project manager’s responsibility to turn themselves inside out and do everything humanly possible to get every single team to do what they’re supposed to do. I mean, at a certain point, For me, it all comes back to that personal responsibility and delivering what each team is responsible for. So as I said just a little bit ago, yeah, I totally see this as it’s the team’s collective responsibility to deliver the release on time and in scope.

And then quoting a little more, those suited to such a role are acutely aware of this responsibility and it’s something they take on quite willingly. They perceive the role of a project manager as a guardian presiding over a project in order to protect it from failure. They are the last line of defense, willing to take the fall should something go wrong. It’s an admirable position of leadership they seek to adopt, but the responsibilities attached to it can become overwhelming for even the most seasoned practitioners. That’s why I think they need to lose control.

And again, well, he’s kind of saying, I guess, what I’m saying there, which is It is a path to burnout. But again, is the project manager the last line of defense? I like to think that the project manager is maybe the last line of common sense in the nicest way, but in the sense of the last line of objectivity of we have committed to this amount of work in this amount of time. Historically, we haven’t been able to do that. What’s going to be different this time?

Can we really accomplish this commitment that we’re about to make? And again, that idea of losing control, what does that really mean? Maybe it means to not hold on so tightly, but to completely lose control, I think of as having no control. You’ve just thrown caution to the wind. So next, the author looks deeper into the idea that project managers cling to waterfall software delivery as a preferred model because it gives them comfort and predictability.

I would say it gives the perception of predictability, but as he points out in other parts of the article, there are a number of things in a software release that you can’t control. The unexpected always happens. It can feel comfortable to know that you have a plan, and I think that sometimes the teams I’ve worked with, they have looked at my insistence on a schedule or particular dates that I’m wrapping my security up in the plan when really what my motivation and what I’m trying to get at is these are the dates. Can you make them? Are you able to make these dates?

And maybe in some cases I haven’t been clear enough to say, I don’t think you can make these dates. I think these dates are ridiculous.

In the realm though of adding predictability, sometimes I’ve seen waterfall or schedules like this to be the only thing that you can turn to because individual people or teams are not willing to accept full responsibility. They will, in the context of say waterfall versus agile. So in the software development world, people that do agile tend to look very disparaging on waterfall, kind of like it’s this dinosaur methodology that we should have all outgrown years ago. The irony, I guess, I’ve seen in some of these situations is that the people that are doing waterfall that think we should be doing agile often don’t want to do a lot of the formality that then comes with agile software development. So whether that be daily standups, frequent releases, backlog grooming, evaluating velocity, like how fast, really getting the metrics dialed in, in terms of how many user stories or features are we able to release?

How much work can we do in a given amount of time? And are we actively tracking that, aware of what’s going on, and managing ourselves accordingly to that? And are we willing to be fully accountable for the outcome? That’s the part that I’ve found sometimes to be missing. Then quoting from the article, faced with commercial pressures to meet deadlines and work within the bounds of restrictive procurement rules, project managers are also adverse to change.

They seek predictability and produce project artifacts like Gantt charts, interface designs, and technical specifications that endeavor to precisely define project outcomes. They see them as a blueprint for success and use them as a weapon against anything that may threaten it. I think that’s a little dramatic. Uh, I suppose there are some project managers that do that. I’m not one of them.

I will say though that I have seen some really amazingly important and powerful conversations happen when there has been product specifications. There’s kind of a tug of war that I see in software development with this, where you can have a software specification that’s over the top detailed. It’s too detailed. Then you can go to the opposite extreme of, we’re just going to write user stories and do stuff. User stories are a way of defining software requirements in the Agile context.

And everything will turn out fine. I have seen in cases where the software specifications were documented that it led to a lot of good conflict, a lot of good discussions, a lot of good, like, wait a minute, that’s not what I thought we were doing. I thought we were doing this other thing. Product specifications done well, I think, can be a really, really strong communication tool. But yeah, are they a safety net?

No. Do they guarantee success? No. I don’t think there’s anything that can guarantee— the only thing that I think can guarantee success in a software release, no matter what methodology you’re using, is extreme ownership. Basically taking complete and utter responsibility for the things that are yours and helping out other people where you can.

Continuing, quote, but the more project managers seek certainty, the more they endeavor to control the factors that may affect it. Those that receive the most attention tend to be the people around them, those responsible for producing the outputs a project requires. Suddenly, strict boundaries constrain the project team and managers encourage that team to avoid deviation. They direct all the team’s effort to appeasing stakeholders expecting a predefined outcome. I haven’t experienced this.

I think this, Probably applies to more political hierarchical organizations. And I haven’t seen so much of that in my time at Red Hat. So yeah, I don’t see— I have not seen waterfall as constraining the team to just deliver something that’s way out of touch. Skipping ahead, the much better alternative is to take a more agile collaborative approach. Where responsibility is distributed, failure is not feared, and change is recognized as a constant.

It’s a more common sense approach that better accommodates the human factors that so strongly influence the success or failure of a project. So I think inadvertently he’s kind of saying what I’m saying there, which is, yes, it’s that shared responsibility. Everyone is responsible, not the project manager. And so maybe, maybe the, I don’t know, I’m just kind of thinking out loud as I’m going here. Maybe this article is more suited for project managers that feel like it is all up to them, and those are the ones that need to lose some of the control.

But I also think there’s a number of different factors here. I don’t think it’s just simply the project manager needs to lose control and everything will be fine. I think it’s more complicated than that, and it also depends on the responsibility level that the team is willing to accept, and the individuals on those teams. So the author concludes with a section titled, quote, Begin with Culture, and that project managers need to have a change in mindset. They need to overcome the desire for prescriptive approaches.

The author concludes with a section titled Begin with Culture. First, the need for a change in mindset, and then also to overcome the desire for prescriptive approaches. Fortunately, more managers are recognizing the appeal of agile approaches to project management, and they’re heavily promoting these across the business sector while adoption in government is strengthening. People acknowledge agile approaches as a good way to increase value, foster a great level of engagement with users, produce better products and services, and increase the well-being of the teams who produce them. And a little further on, the key message for project managers seeking a change is that you need to work on developing the right mindset, both for yourself and for those around you.

Facilitate more collaboration, empower individuals to take on more responsibility, and encourage your teams to become more self-organized. Stop obsessing about plans or processes and lead your projects Rather than trying to control them. And this, I think, is the most challenging part of all of this, is the leading— is what does it look like for a project manager to, quote, lead a project if the responsibility is to be shared across the teams? And what do you do, and can it work— spoiler alert, I don’t think it can— when the teams don’t want to accept responsibility? So kind of the whole notion of extreme ownership, which I’ve talked about in a few previous podcasts and I’ll link to.

So I will say conversely, I have also seen teams that totally own the process. I had to— so I guess what I want to say here in closing is I’ve seen kind of both extremes. I’ve seen teams that were unable or unwilling accept responsibility and totally own everything. And I’ve seen teams, and so for those teams, it was more like I was kind of trying to drag them along. Then I’ve had the opposite experience where teams totally did own the process and owned everything.

And I was, they were dragging me along, it felt like. In other words, I tended to be trying to keep up with them to understand, okay, what are the guidelines? What’s the process that we’re trying to follow here? And then Once we were kind of synced up on the process and in agreement, then I would facilitate that process across the Agile team. So, again, I think the core takeaway, the core crux of all of this is responsibility.

Are the people, are the teams, is the team willing and able to be fully responsible and accountable? And if so, You can totally do this. If they don’t, can the project manager on their own completely change the force and focus of the team? I don’t know that I’ve ever seen that happen. My experience is it takes at least a co-conspirator, someone on one of the teams that make up the project teams that can kind of be a copilot or a, you know, co-captain with the project manager, then I have seen success.

But where it’s just solely the project manager, I have not seen that be successful. But I’d be curious to hear your own experiences. If you, I don’t know, if you agree with me and you’re like, yep, John, totally agree with you. That’s the way it’s always happened for me. Or if you have counterexamples of the complete opposite, I’d love to hear that too.

And in particular, I’d be curious to know What were the keys to succeeding, to success? Like, in other words, what made it work? What ways were you able to help the team assume that responsibility and accountability and essentially, you know, take on extreme ownership?