[00:00:00.330] - Chris
In this episode of Great Practices, I'm talking with Troy Robinson, Senior Director of Engineering with over 25 years of experience in software development. Listen into this episode as Troy discusses the difference between waterfall and agile development methods, how the scaled agile framework, or Safe fits into these models, and what PMOS and project managers can do to help or hurt projects that they manage.
[00:00:27.120] - Chris
In either of these methodologies.
[00:00:29.770] - Chris
Plus, you'll find out why it depends, is an answer you'll need to get used to when it comes to picking the best methodology and ultimately what all successful projects are built upon.
[00:00:41.790] - Narrator
It's hard to say when something is a best practice, but it's much easier to know when something is a great practice. And that's what this podcast is all about. Interviews with CMO and project management leaders who, through years of trial and error, have discovered their own great practices and are now sharing their insights with you. Now sit back and enjoy the conversation as Chris Cobb uncovers another great practice in this episode.
[00:01:10.470] - Chris
Well, we'd like to welcome everyone to another episode of Great Practices. And we've got another great guest on today, Troy Robinson, who is going to be discussing with us some of the various development methodologies. Because when you think about it, PMOS, project managers, we generally work in matrix organizations, so we don't have direct reports necessarily, but we'll borrow resources from functional managers. Sometimes this is going to turn into beg, borrow, steal, whatever it takes to get the job done. And there's definitely pros and cons of not having direct reports, a pro, whole lot fewer performance reviews that we have to deal with, right? But there's also a whole lot less control and there's much more reliance upon influence and persuasion and relationships. And while this next one is not necessarily a con, we also need to speak whatever language the team is that you're managing speaks. You got to be fluent enough in how they converse and how they talk to each other in the way that work flows through their teams. So if you're working with a financial team, you need to understand their domain. If you're working with a marketing team, you need to understand their domain.
[00:02:25.050] - Chris
HR, same thing. And this especially applies to development and engineering teams. So today we are going to get a little bit of a language lesson today from Troy Robinson when it comes to these different development methodologies and helping us really understand the language and the flow of work that can work through these different teams right there. So it'll be enough to know the differences. We'll talk a little bit about the high level of the differences between the different methodologies, the pros and cons, and the trick question, which one is the best? So, Troy, we are glad that you're on Great Practices today, and we'd like to welcome you and looking forward to the session.
[00:03:07.450] - Troy
Thank you, Chris. Thanks for having me on. I know it took a while for us to connect, but I'm so excited to be here and be a part of your podcast.
[00:03:17.940] - Chris
Yeah, I appreciate you joining and I know you're busy, so we'll get right into it. Can you tell us a little bit about who you are and what you do, a little bit more about your background?
[00:03:27.850] - Troy
Yes, as you stated, Troy Robinson, I've been in this engineering field for about 25 years now. Currently I work for a major omni retailer. Most people would know the retailer, but I'm not going to mention the name. So Senior Director and I manage and lead software engineering teams in Dallas, Atlanta, and as well as Bittenville, Arkansas. My background go as far back as my early days as a junior engineer and moving my way into leadership and been in the leadership space for probably the last 15 or so years.
[00:04:13.040] - Chris
Excellent. It sounds like you're going to know what you're talking about here. So we're looking forward to this conversation then, for sure.
[00:04:19.590] - Troy
Yeah, I'm looking forward to the trick question though.
[00:04:23.410] - Chris
It's not too hard. So Troy, what is your definition of a PMO? We start out with that question because everybody has just a slightly different definition of what that is. So what's your definition?
[00:04:34.630] - Troy
Almost call that a trick question.
[00:04:37.260] - Chris
Okay.
[00:04:38.250] - Troy
Because it really depends. I've been in organizations where PMO strictly manage project managers, that project managers manage projects whether they were Waterfall, Agile, or any other methodology. Then I've been in organizations where PMO actually owned finance, as well as some other aspect of getting work done. My ideal, I would say PMO organization is one that actually manages the finances for us, especially on the engineering side, but also in a sense, guide us through some of the roadblocks that we encounter, whether it's within our current or for example, if there's a shared services organization, typically try to bridge that gap for us. So that's my perspective. I mean, there are some good and there are some bad.
[00:05:41.130] - Chris
Yeah, for sure. So it sounds like your ideal PMO is that they're going to clear those roadblocks, they're going to bridge the gaps, and they're going to pay for it along the way by managing your finances. Right. That's your perfect definition. That's good, man. So Troy, you've been doing this for a while now. What are some of the different development methodologies that are out there? What are some of the things that you've seen people use over the years?
[00:06:09.050] - Troy
Yeah, so over the years I've seen waterfall. Right. I think at one point that was the only one we had back in the day. And then there's Agile, and then under Agile you can have Scrum Kanban as well as I think extreme programming falls under that. You also have some others such as Safe, which is scale agile framework, which is just managing agile on a much larger scale.
[00:06:40.150] - Chris
Okay, so which one of these is the best, then here's the trick question. Which one of these that you mentioned is the best path to go down?
[00:06:48.710] - Troy
Well, I think it really depends. Right. I think there are appropriate times to use Waterfall, and today I think most of us try to use Agile as much as we can. I think waterfall, if you have something with strict deadlines that require you to deliver something specifically, I always use the example of government regulatories around drug manufacturing to adhere to those. You can't be Agile because you need to deliver something at the end that's working. Whereas with Agile, you could iterate test and learn. It really depends on what you're doing. And sometimes it's okay to use if we're talking about Agile like Sprom and Kanban, right. I think a lot of teams today use this Kanban board as part of their Scrum methodology.
[00:07:58.140] - Chris
Yeah. So it's okay to kind of blend some of those together right, over time.
[00:08:02.600] - Troy
Oh, absolutely.
[00:08:03.130] - Chris
Go through that. So let's dig into each one of these just a little bit more. And you kind of started with some of the pros and cons. So, first of all, and most of our listeners may know this, but this may be due to some what is waterfall like? How would you define waterfall methodology?
[00:08:18.110] - Troy
Yeah, waterfall is you're really going step by step from idea, business requirements or user stories. Everything is clearly defined. Then I start development, then I test and then I deploy. There may be some going back and forth between testing and fixing bugs or those type things, but it's really very concise steps in the process.
[00:08:50.470] - Chris
Got it. So very linear, right, is what you're saying. Like, you've moved from one and moved to two, three, four, and it's very step based approach. Got it. And like you said, you gave that example of drugs. Right. You've got to have a product at the end. So it's kind of perfect for those types of situations, right?
[00:09:08.450] - Troy
Absolutely. I think a lot of government processes or regulations is very appropriate.
[00:09:17.390] - Chris
So, Troy, what would be a time that we would not use waterfall? What would you recommend for that?
[00:09:24.470] - Troy
I think using Waterfall is appropriate if you're trying to iterate and test and learn and when you're dealing with, say, your operations team and they don't know exactly what they want, agile is probably the more appropriate methodology because it gives you an opportunity to listen and really close that feedback loop tightly so that you're not delivering something at the end of the development cycle that they really will not use or don't want.
[00:10:01.070] - Chris
So if you've got a clear and deliverable in mind right. You got a clear goal. Right. It sounds like that's what everybody's agreed and everybody knows that's exactly what they want. That sounds like when waterfall would be perfect. Right?
[00:10:15.110] - Troy
Well, actually, you still could use Agile.
[00:10:17.440] - Chris
Okay.
[00:10:18.790] - Troy
In a sense, if you're breaking up the work in more manageable pieces got it. Again, it really depends. I would say if you want to still get a feedback loop or close that feedback loop, even if you have exact requirements and there's nothing to deliver at each iteration, you still could do agile. But I prefer if you're in the example, we use the regulatory drug serialization as an example, you do want to deliver at the end, right? So it's best suggest, I would say.
[00:11:11.830] - Chris
Waterfall would be more appropriate and I think we're going to hear it depends a lot, right?
[00:11:17.440] - Troy
That is typically the case. And sometimes we do use a combination of all of them. And when I say all of them, sometimes we do get requirements, but we may develop in an agile way.
[00:11:32.640] - Chris
So let's talk about agile.
[00:11:34.590] - Chris
What is agile?
[00:11:36.100] - Chris
How does that work?
[00:11:38.110] - Troy
So agile is I would say it's a lot more flexible than waterfall, right. And you don't have to have everything clearly defined before you start developing. And usually we start out with working with our product managers or product owners and get user stories, right. And we plan them and then we go into development in sprint, since sprints are typically a couple of weeks. But in agile, actually sprints can be whatever time frame you set. If you're doing more frequent sprints, you can deliver and get feedback pretty quickly.
[00:12:27.710] - Chris
Got it.
[00:12:28.210] - Troy
From the end user before you proceed to the next sprint, which is actually part of the ceremony of agile as well, is getting that feedback.
[00:12:41.730] - Chris
So what would you say again? Pros cons, when to use, when not.
[00:12:47.050] - Chris
To use, what would you lay out for?
[00:12:49.670] - Troy
Well, I think, like we said before, in cases where things are well defined and an example, I hate to keep going back to the same example, but if it's something more regulatory, yeah, waterfall is appropriate. But I think either way, even in that case, you can develop in agile fashion and I really love Agile because you can get that feedback or you can break work into sizable chunks and sometimes that helps the team so they're not overwhelmed. And then also they can see results versus waiting towards the very end of a project to get that feedback. But I tend to either way, from an engineering standpoint, lean towards an agile way of working.
[00:13:46.460] - Chris
Got it. And I guess part of the goal of that agile development methodology is that you will have a useful functionality, basically, right. Something is going to work within that short period of time that you're going to develop. You'll be delivering value to the user, right. That's kind of the goal of that whole piece, right?
[00:14:07.500] - Troy
Absolutely. And then just getting that feedback and know what you're doing. Because sometimes for us as engineers, we think we understand the business operations and what it's really going to be used for until they actually get the product that we developed based on what we thought they wanted. So it's good to get that feedback pretty quickly.
[00:14:32.120] - Chris
It kind of reminds me, I don't know if you've seen I know you've seen it. That cartoon of that tire swing. It starts out with like what the customer wanted, what the analysts recorded, what the project manager thought it was, and then what was actually delivered and it's like entirely and totally different. Right.
[00:14:50.400] - Troy
And that's exactly what can happen with Waterfall. Right. Yes. Once you go down that path, you can be so far removed from the original requirements, whereas with Agile you're staying close and again closing that loop between the feedback from the user or operations and engineering.
[00:15:12.710] - Chris
Yeah, it makes perfect sense because even if you think about if you're off course, like some flight may be off course, like one degree or something like that, if you're just off course a short period of time, you can come back and you can get back on track quickly. Right. But if you're just keeping down that.
[00:15:30.970] - Chris
Path hours and hours and hours later.
[00:15:33.820] - Chris
Or weeks and weeks later when it comes to development or months, for heaven's.
[00:15:38.020] - Chris
Sake, you could be way off course.
[00:15:40.510] - Chris
Right. And that just could end up to be exactly what is not needed at that point in time there.
[00:15:46.620] - Troy
Yeah. When we talk about money and PMO helping, that is wasteful. Right. And a lot of times organizations do because they're going down that long path and they get to the end and it's not what the user wants and what was delivered. You have to go back in some aspects, start over and the further you're.
[00:16:14.970] - Chris
Down that path, the more expensive it is. Right?
[00:16:18.010] - Troy
Absolutely.
[00:16:19.030] - Chris
Yeah. So you had mentioned something earlier about Safe. What is safe. What does it stand for? How does it tie into Agile? What is that all about?
[00:16:31.470] - Troy
Scale agile framework.
[00:16:34.390] - Chris
Okay.
[00:16:38.830] - Troy
I've seen it in action a few times and I really like it. And it's really for if you think about scale, it's really an entire organization being Agile and some of the key ceremonies part of that is like Pi planning. And Pi planning at an uber global organization level is where it really is beneficial because every say if you have multiple pillars in the organization and those pillars are dependent on each other, you can really understand timing and dependencies and so you can align and deliver more efficiently and effective. Which is kind of one of the principles of scale. Agile framework.
[00:17:33.290] - Chris
Now you're saying Pi planning. What does that mean? What does that stand for? What does that look like?
[00:17:39.330] - Troy
Program increments. In examples that I've seen or that I've used, that is where we get all of our product people together across as in our example of pillars, we get all our product people together along with engineering and some of the key leaders and layout. Here is what we're doing as an organization from a roadmap perspective and then just getting alignment. In some cases you would spend a couple of days doing this to understand, again, all those dependencies, all the timing. So for Pi planning, it's a good way to get a good vision and actually develop your roadmap as an organization. So they're huge upside to Pi planning as part of Safe.
[00:18:37.130] - Chris
So it's basically, hey, as an organization, where are we going? And then how are we going to get there? Right? There's the roadmap that everybody is putting together and all the reliances and dependencies that have to go on there and getting that all done at one time.
[00:18:53.310] - Troy
Yeah. And another thing I love about Safe too, you really kind of define roles and responsibilities as well. I think people use product owners and product managers interchangeably. In those cases, they are different and they serve a different purpose. For example, product owners really work closely with the engineering team, right, to deliver, make sure the team understands scope as well as what are we delivering. And then the product manager essentially is looking more broader, working with typically operations in the business to understand their needs and then cascading that down to the team. Also say the product manager is also the protector of the team as well. Right. Because usually the business may ask for something that may not be feasible or may want to change requirements in scope. And so that person, I think, is critical, especially when it comes to engineering.
[00:20:06.130] - Chris
That's got to be a big job then, right? As far as being the protector of the team?
[00:20:11.040] - Troy
Absolutely. But the thing about Safe though, is all about getting things done faster with efficiency and with some level of engineering excellence.
[00:20:26.090] - Chris
Nice.
[00:20:28.230] - Chris
So Troy, let me ask you this then.
[00:20:30.120] - Chris
We're going to kind of shift gears a little bit. We talked about what waterfall is, what agile is, how Safe incorporates into that equation right there. I want to talk about how these methodologies would interact with a PMO. What would be some things that a PMO does that could hurt or help, like, let's say a waterfall team?
[00:20:56.470] - Troy
Well, I think a waterfall team, I think they're very helpful in the sense of laying out the scope at a broader level because they may have a larger vision of how our piece of work impacts something larger. And then, as I mentioned, in a waterfall, right, keeping track of financials and making sure we're hitting our targets. And I think the other thing too, is a lot of these projects have statuses. So we usually say that's the responsibility of the PMO either to provide a project manager as part of the team and then roll it up to the PMO and communicate that to the organization. So it takes a little work, will burden off the core engineering team.
[00:22:00.470] - Chris
So if I'm reading between the lines, like if they basically are there, being able to help out with the status, providing updates, kind of taking that administrative piece off of the engineering team let those guys focus, like you said, clearing that they can clear the path. They can help clear the path is what a PMO can do.
[00:22:18.170] - Chris
I assume that part of the herding.
[00:22:20.020] - Chris
Part could be putting a lot more administrative on the team, right?
[00:22:25.180] - Troy
Oh, absolutely. And I've seen that where we were spending more time providing updates than actually getting work done and that can be very distracting to the team. And then I would say sometimes the challenges can be when you look at the PMO, sometimes that technical acumen is not there trying to get them up to speed or them. Understanding your challenges can be sometimes a problem, and sometimes you're spending more time explaining it to them and then explaining it to someone else so that they can get past either a hurdle or roadblock.
[00:23:12.710] - Chris
That's a good point. They should take some of that responsibility on themselves to kind of understand even the technical side of things. Right? That would be helpful.
[00:23:21.740] - Troy
That's always the best. I say project managers or PMO organization are the ones that really understand the technology that we're dealing with, the business problem we're trying to solve. I think once you're too far removed from that and just reporting status and looking at finance, it can hurt the team overall.
[00:23:51.450] - Chris
What about agile as far as what would there be anything different that they could do to help or that they would be hurting agile teams?
[00:24:01.630] - Troy
Yeah, I think the biggest difference, I think a lot of the things are the same. I think the biggest difference is understanding the methodology and the iterations and knowing that the timelines may shift in agile, and I say timelines as well as the priorities may shift based on either findings or the business or operations can prioritize work over other. I know sometimes the PMO wants to see very defined time slices which in agile is not always the case.
[00:24:54.670] - Chris
So it sounds like the project managers need to be a little agile then, right? When it's all said and done.
[00:25:00.530] - Troy
I would say so, sir.
[00:25:04.370] - Chris
And you are right because that kind of goes against the grain. Right. Of most project managers, everything is in.
[00:25:11.190] - Chris
A bucket, everything's black and white, everything's planned out.
[00:25:14.080] - Chris
What we got to change this is a different part. We just started this, we got to move this around. That has a tendency to drive project managers crazy.
[00:25:22.710] - Chris
But that's the environment, right?
[00:25:26.170] - Troy
Yeah, that is the environment. But I think as project managers or PMO organization have to learn how to navigate in those situations. And again, I think it's understanding what's being delivered as well as understanding that they need to be a little agile as well because that's how work gets done. That's how you get efficiencies is being able to pivot based on business needs.
[00:26:03.660] - Chris
Yeah, for sure. So Troy, regardless of the methodology that's used, what is it that really counts? What helps get the work done?
[00:26:13.830] - Troy
Basically no for me, I think you take pieces of a lot of the methodologies and what works best for your team. And I think I mentioned before, right, a lot of teams use Scrum as one of their Agile methodology, but they also use Kanban, the Kanban Board, and they operate, they take bits and pieces. And the other piece of that is, in my career, it's been about building relationships. And once you build that relationship, especially as part of Agile, right, you're doing retrospectives and you're understanding the team and you're building those relationships within the team. And when you have those relationships, you're actually more efficient and because you can help uplift those that may not be up to the level you want them, and then you also can see where your gaps are and you can help elevate the team from there. But I think the biggest thing is how do we get work done and how do we deliver for the business? And I've seen once the business and operations understand Agile, they appreciate it as well, because they get to see something and they're engaged along the way.
[00:27:47.260] - Chris
Perfect. So, Troy, is there anything else you'd like to add about selecting or using these different methodologies that we haven't covered?
[00:27:55.280] - Troy
Yeah, I hate to start it off my statement by how we started out the conversation, right. It really depends, and I think you really have to understand what works for you. A lot of times it's really a combination of multiple methodologies. I say with an Agile, right. There are couple Kanban and Sprum, but you may mix the two. I think most teams use the Kanban Board in their Sprom methodology. And you know what? It actually doesn't hurt to use it in waterfall either, right, because you can actually see the work getting done and moving along. So in this world of being Agile, delivering quickly, we should try to find the right medium right, to get work done. But always remember, though, it's also about the relationships and how you get work done as well, because sometimes those relationships will also remove hurdles and blockers quickly.
[00:29:06.030] - Chris
So what I'm hearing you say is basically make it work for you. Right. You can customize whatever the methodology is, right? So you could start with the framework, but you can bring in a little bit here or a little bit there, or do it a little bit differently here, whatever's custom for you that, you know, works, getting stuff done and just get along with people in those relationships, right?
[00:29:29.560] - Troy
Yeah. Just like us.
[00:29:30.970] - Chris
Yeah, exactly. All right, man. Well, thanks for joining us today. This was very insightful and I know that our listeners will definitely benefit from this. If anybody wanted to get in touch with you, wanted to discuss any of these ideas further, what's a good way to reach it, Troy?
[00:29:48.270] - Troy
Obviously you can always find me on LinkedIn. I try to post more these days, but Troy B as in Boy Robinson on LinkedIn. You can also reach me at [email protected].
[00:30:04.100] - Chris
Excellent.
[00:30:04.680] - Troy
I would love to have conversations with anyone or give you any additional insights.
[00:30:10.540] - Chris
All right, man. Well, thanks for coming on today, Troy. It was a great conversation and we look forward to talking to you soon.
[00:30:16.630] - Troy
Hey, Chris, thanks for having me.
[00:30:22.790] - Chris
Well, that was another great episode of Great Practices, and we certainly do appreciate Troy Robinson being on today and sharing his decades of experience in engineering and development and sharing that with us today. So what did we learn? What were some of these great practices that came out of it? Well, he talked about the difference between waterfall and agile. Waterfall methodology being that step by step, linear progression of events, right. You start with an idea, you start with requirements, user stories, then you do development, then you do testing, then you deploy. And it's all very linear and step by step approach, this seems to work well for a very defined end result. He was talking about pharmaceutical companies and drugs and government type projects where you know exactly what the end result needs to be and that lends itself more toward that waterfall methodology. By contrast, there's agile methodology. That's the methodology that many companies use nowadays, a lot more flexible. Not everything is clearly defined before you start developing. There's more frequent, smaller releases which allows you to get feedback quicker, make adjustments and figure out what you want along the way. So that's really popular with many teams nowadays.
[00:31:49.560] - Chris
And it helps the teams not get overwhelmed and helps the customers, of course, correct as they begin to see this value being delivered. In addition to that, he talked about Safe. Now this is really taking agile and moving it to the organizational level. That Safe scaled agile framework, which is really the entire organization becoming agile. That's where he talked about the Pi planning, the program, increment planning, where everybody comes together in the company and the organization, all the different departments. Talks about what's coming up, what's on the roadmap, what dependencies are there going to be upon each other? What can you help each other out with? What's going to be in the way in getting all the engineering leaders and key leaders together to discuss that in order to come up with a road map that can be sustained in the coming months. I thought this was very interesting when it came to how to interact with the PMO or how the PMO can interact and help or hurt these different types of methodologies. When it came to waterfall, he said, lay out the scope from a broader level. The PMO would have maybe a bigger picture of where this particular project would fit into everything else.
[00:33:12.480] - Chris
So help the teams understand what the bigger picture is, keep track of financials, keep track of the targets that are ahead, work on the statuses, right? That's the responsibility of the PMO. You can take that burden off of the core engineering team by doing a lot of that work that could be considered administrative and being able to allow them to focus on more the engineering tasks. What about those things that could hurt a development or an engineering team when it comes to interacting with your PMO? Keep the Administravia away from the team. Sometimes we couldn't lend itself toward putting a lot of updates and status and timesheets and all of these types of things where people are finding that they're doing more work on updates than they're actually getting work done. So we always need to be mindful of that and not overwhelm our engineering teams. Then he talked about what can help from an Agile perspective. So if our PMO is developing or working with teams that are developing with an Agile methodology, basically said, hey, understand the methodology, understand the iterations, understand that timelines may shift, priorities may shift. And that's the nature of Agile.
[00:34:39.050] - Chris
We as PMO leaders many times want those very defined time slices and we want those very defined deliverables that's going to be occurring and we want to stick to a plan. But that's not always what happens when it comes to Agile. So learn to navigate in these situations. And also, I thought this was interesting as well, obviously, is get to know some of the technology behind what you're managing. It's always good to have that technical side in order to understand and help the teams out. Finally, what helps get the work done regardless of the methodology? Basically, I like the fact that Troy said, hey, just do what works for you. If you need to combine this piece of this methodology, this piece of this methodology, this tool, whatever it is you could actually do, waterfall and agile combined and pulling in the different ceremonies into these methodologies, do what works for you and ultimately build relationships with your team and with others in your organization in order to get the work done. That's ultimately what it comes down at the end of the day. Make it work for you, build those relationships and you'll get the work done.
[00:35:59.090] - Chris
So again, we'd like to thank Troy Robinson for being on today and taking time out of his schedule to come on Great Practices. You have a great practice you'd like to share. Go to the PMO leader, click on Explore Great Practices podcast and fill out the form at the bottom of the screen. Someone will get in touch with you shortly. Also, be sure not to miss a single episode by subscribing to Great Practices on your favorite podcast platform. And if you like what you hear, be sure to share this with your manager, your colleagues, and anybody else that you think would benefit. So thanks again for listening to today's episode and keep putting Great Practices in the practice.
