06.03.2020   /   duration: 30 min
The Experience Lab
Agile, Waterfall, and Design

Agile, Waterfall, and Design

Rob and Jay are back in the [socially-distant] studio to talk about the big names in product management methodologies and how we apply their principles to our practice of product design.

Hosted By

Jay Cosgrove, Senior Product Manager at Digital Scientists
Jay Cosgrove
senior product manager

Episode Transcript

Rob Hall: Hey, Jay.


Jay Cosgrove: Whuddup? 


Rob Hall: I think we need to talk about something. 


Jay Cosgrove: All right. 


Rob Hall: I think we need to talk about… waterfall and agile.


Jay Cosgrove: Hasn’t the world talked about this enough? 


Rob Hall: And Scrum.


Jay Cosgrove: Scrum. 


Rob Hall: And that other thing? 


Jay Cosgrove: What? 


Rob Hall: Lean.


Jay Cosgrove : Lean?


Rob Hall: Do we know what lean is? 


Jay Cosgrove: Not really.


Rob Hall: Let’s do this. This is the experience lab, the official podcast of digital scientists from Atlanta, Georgia. We’re an experienced lab explores and builds digital products. My name is Rob Hall, and I’m the Senior Director of Product at DS. Thanks for listening.


Today, we’re gonna do a quick tear down of your favorite PM framework, and talk about the pros and cons of each, as well as how we’ve managed to apply these principles in our work at Digital Scientists.


Jay Cosgrove: This is a great conversation. If you’re first setting off, especially if you’re an agency, this is really challenging. I don’t want to say this conversation is going to exclude by any manner, people that have like internal teams. But what I really want to showcase is figuring out how to do agile well, which is what we’re striving towards, in an agency model. 


Rob Hall: Why is that hard? Why has it been hard?


Jay Cosgrove: Because of the contract types.


Rob Hall: So we talked about that last time, understanding the differences between time and material and fixed fee, retainers and all that kind of stuff. What is how I bill the client have to do with how I structure the work internally?


Jay Cosgrove: Well, it dictates how your team can function on the project, which kind of in turn dictates how you can run the project. So for example, if you have a T&M team, then you’re designating hours which means you’re designating the amount of time your team can be on that specific project or that specific thing. Which goes into how you can structure that week or that that period of time that you’re analyzing.


Rob Hall: So by virtue, I’m designating a constraint, 


Jay Cosgrove: A constraint. Exactly. putting in place one constraint – 


Rob Hall: Yep. 


Jay Cosgrove: To many constraints that could be in your project process.


Rob Hall: Yes. Yep. So applying that to waterfall, waterfall is old. And there’s been a huge shift away from it over the last 10 years or so I’d say. 


Jay Cosgrove: Yeah.


Rob Hall: We’ve come from a waterfall esque background, right? Where we try to gather as many requirements upfront, understand what the intended outcome of the project is going to be try to put forward some sort of estimate about how long it’s going to take to create the set of defined requirements. Hope that nothing changes. I hope that we also get it all right the first time. 


Jay Cosgrove: Impossible.


Rob Hall: And hope that what comes out the other side is what we predicted would at the very beginning. And so like in waterfall, you’ve got these literal cascading phases of effort. Requirement, gathering phase and then design phase or you’ve got to BA involved in these different roles. And you’re generating a lot of paperwork. The idea being that if I can generate enough clarity of definition, then once it makes its way to the developers, they have a very clear roadmap to follow. 


Jay Cosgrove: Exactly.


Rob Hall: That minimizes error. 


Jay Cosgrove: Yep. 


Rob Hall: Doesn’t work, though?


Jay Cosgrove: Well, you know, I actually over the years, like, I’ve come to think more highly of waterfall. So it tends to be the excuse me, yeah, I know, it tends to be the thing that everyone beats on, right? And rightfully so. It causes a lot of things to just fail miserably. I think one of the biggest examples of that someone gave was that, if everyone remembers when Obamacare came out, the website like crashed and it was horrible for a couple months or whatever. And it was like a big example of like, they used waterfall, and it failed.


Rob Hall: And I just want to say real quick, I could have built a better website for $200 million.


Jay Cosgrove: Exactly. Put yourself through school and build it yourself. Yeah. Yeah. So but here’s the thing. Waterfall, it works kind of well for really short term projects. And so like Rob has mentioned, it’s got a cascading effect, where you’re going to go from requirement gathering to design if there’s kind of a design phase, and then to development and testing, and then some sort of release, generally.


Rob Hall: So you have these individual swells of effort that then pour over into the next phase. 


Jay Cosgrove: That’s right


Rob Hall: And the next phase doesn’t begin until the prior phase has been completed.


Jay Cosgrove: Yep. Yeah, that makes a lot of sense to people. It’s, like easier to sell or we’re going to do this then that then that. But I think with shorter run projects, it actually does, okay. And sometimes you have restraints with resourcing, where you have to structure it that way. Where you’re going to get a design resource for two months, and that’s all you’re going to get them for, right? So you have to do as much research up front as possible to fuel the next six months of your dev team, or whatever that might look like. But I think, but I think ideally, you would run a little more agile. And we can define that later. And just kind of have sporadic use as necessary of the different kind of factions that you need. So from the designer research, it would kind of come in context, because as we know, the consumer and the product shifts over time. So if you did something six months ago, there’s a really good chance that it might be different now. 


Rob Hall: I don’t think I define our teams as factions.


Jay Cosgrove: Yeah, factions is probably the wrong word there. Though, I’ve seen many organizations where they are faction.


Rob Hall: They’re very factionalized. Yeah, we’d like to get along here at DS or die trying. Anyway, there’s aspects to our process, we talked a lot about our process here, there’s aspects to it that are still very waterfall. Research, for example. We can structure it, I think in an agile manner, in terms of just planning the work. But in terms of the outcome of research being able to inform design and development, that’s pretty much a waterfall in nature. And I don’t think there’s a way to necessarily avoid that. 


Jay Cosgrove: Yeah. 


Rob Hall: Likewise with product design. And this is a whole separate topic that we can get into. But there’s a cascade, if you will, where design has to get out in front of development. They can’t run truly, and perfectly in parallel. Yeah, I think if we structure their work in sprints, they can be, you know, a sprint or two ahead.


Jay Cosgrove: Exactly. You’re still technically waterfalling design in. 


Rob Hall: That’s right. 


Jay Cosgrove: Yeah, yeah. So you’re using the flashy agile terminology. 


Rob Hall: And you’re faking it. 


Jay Cosgrove: You’re faking it. Yeah, exactly. And that’s okay. Really, because that’s what the world comes down to. I remember when I was a young PM, a few years back, and I stumbled on this term agile. And I was just naturally using more of a waterfall thing, though, I didn’t even know what that meant at the time. And I searched the internet so hard to figure out how design works in agile. And at the time, there was like nothing that returned at least any of the queries that I put in.


Rob Hall: There’s still not there. Yeah, there’s some but there’s not a lot.


Jay Cosgrove: So I want to take this time really, you know, instead of beating the dead horse of what is agile versus waterfall to describe how you can kind of work some of these things in parallel. And I’m gonna dispel the myth right away. I have not seen design work super well in true agile forms.


Rob Hall: Let’s take a step back. 


Jay Cosgrove: Yep. 


Rob Hall: And define a few terms. 


Jay Cosgrove: Yes. 


Rob Hall: Design sprint, I think would be wise to treat as a completely separate entity apart from agile sprints. 


Jay Cosgrove: Very distinct. 


Rob Hall: It’s easy to confuse the two because they both share the word sprint. But a design sprint, referring to the Google Ventures design sprint methodology, is very much its own thing. But when we refer to a sprint in the agile way, we’re talking about a defined block of time. And for some people that might be a week that might be two weeks might be three weeks. For us, it’s typically two weeks of just a block of time where the team has structured work. And we have these things called ceremonies.


Jay Cosgrove: Yeah. Okay, so I’m gonna take one, I’m gonna up you one. Oh raise you one here. 


Rob Hall: Uh Oh. Here we go. 


Jay Cosgrove: We’re let’s go back a little bit further even further. So we have waterfall, which is cascading effects. And I think the most defining point that Rob made is that requirements are gathered up front.


Rob Hall: Yes, all of them. 


Jay Cosgrove: All of them.


Rob Hall: Or so you think. 


Jay Cosgrove: If you change them, it becomes very destructive to your contract, to your process, to your timeline. And most of the time, it’s going to change. That’s why I emphasized earlier that shorter projects are better. If you can do a month long project, it’s less likely that you’re gonna have changing requirements. 


Rob Hall: Yep. 


Jay Cosgrove: On the other hand, you have this, this ideology of agile, which is working in iterative releases of your software. And that allows for change because we know change happens. And that kind of embraces change because after an iteration, you can re examine what worked well, what didn’t work well. And you can pivot if necessary, or add something else into your plan. And by nature, it’s supposed to be iterative, meaning that it can change. So within agile you have a couple of flavors. So you have Scrum, which is the one that we keep referring to with Sprint’s, which is probably the most structured form of agile. 


Rob Hall: Sure. 


Jay Cosgrove: Would you agree?


Rob Hall: Yeah I would.


Jay Cosgrove: Okay. And then you have Kanban, which is a bit looser, and 


Rob Hall: Different. 


Jay Cosgrove: Different. Yeah.


Rob Hall: Different.


Jay Cosgrove: Yeah, it’s different. I view it looser because it has less of the kind of structured ceremonies and requirements of Scrum.


Rob Hall: True. 


Jay Cosgrove: So that’s the main two I’ve used. Scrum, as a quick definition is, again, flavor of agile, that requires a certain structure that includes defined roles on the team. So you’re gonna have a Product Owner, Scrum Master to kind of keep things humming along. And then you’re gonna have the scrum team, and stakeholders kind of sit outside of all of that. And then you’re going to have ceremonies. And these ceremonies are really kind of regular meetings. And so that’s stand ups and your sprint retrospectives and demos. And then with Kanban on the other side, it’s much more loose. So you the idea with Scrum is that you release at the end of your sprint, which is a specific period of time. It can range from a week to a month.


Rob Hall: What do you mean by release at the end of your sprint?


Jay Cosgrove: Not every team releases. But the idea with Scrum is that you would to complete a story or a task that’s on your board that you’ve planned for that sprint, that to be done. And you really have to define with your team what done means is that it’s released. It’s out the door. So you would pick up a ticket or story specifically that you could take all the way through all phases within one sprint, one period of time, and it ends and is done with you releasing it or going live. So it’s not always that way. It really isn’t. But that’s I think the true when people think of Scrum, that’s what they think of. 


Rob Hall: Gotcha. 


Jay Cosgrove: Yeah. Okay, so Kanban on the other side, it’s a flavor of Agile again, kind of iterative, but it does not plan things in periods of time. It more looks at things based on when you’re ready to release. And so really, you have this board, this Kanban board, which kind of Scrum steals from it. And Kaban steals certain things from Scrum to over the years. But you had this board of a to do column and everything is prioritized in the to do column. 


Rob Hall: Yeah, I was gonna say, I feel like a lot of people misuse the Kanban board. So they don’t really know the process itself. So they utilize it as if it’s for Scrum, right, or whatever. And you can 


Jay Cosgrove: Yeah.


Rob Hall: There’s not a law that’s you’re not allowed to misappropriate the tool for your own, however you want whatever works and best for you.


Jay Cosgrove: And all the project management tools have kind of merged these things anyways. 


Rob Hall: Yeah, yeah, for sure. 


Jay Cosgrove: So you would have this to do column of prioritized tasks and the team pick up off the top of the column. These tasks or stories, they work on them, and they move them to done when they’re done. And then at some time they would decide, “Alright, we’ve got enough in the done column, let’s release.” And that’s really up to the team and the set of features and all that kind of stuff. It’s  much more loose in the sense that you’re not going to have a ton of structure around meetings or roles. It’s more about just getting work done. 


Rob Hall: Sure. 


Jay Cosgrove: And then the one that no one really likes to talk about is Lean. You want to take a spin at Lean, Rob? 


Rob Hall: Ooh, so lean. I’m not gonna get all the way into the weeds on lean. Lean has its roots more in the automotive manufacturing industry. I want to say it actually came out of Toyota 


Jay Cosgrove: Yeah, I’m pretty sure 


Rob Hall: back in the 60s or 70s 


Jay Cosgrove: Most good processes to have. 


Rob Hall: Yeah, for sure. But the idea of lean is a very rigid interpretation of agile methodology. It’s not exactly I don’t know it, just it has a very tightly prescribed method. And it has a number of benefits that its proponents will swear by. But it’s not a methodology that I would suggest is easily adaptable to the needs of an organization. It’s something that you have to make a commitment to. 


Jay Cosgrove: Right. 


Rob Hall: If you’re going to follow it, you’re going to follow it to the tee. Honestly, similarly to form a waterfall methodology. 


Jay Cosgrove: Yeah. 


Rob Hall: And I think that’s why waterfall has been such a pain for so many people, even for those who do utilize it to the letter. 


Jay Cosgrove: Right. 


Rob Hall: It is a method that is intended to be followed as prescribed, without variation or deviation, and in lean is very much that way. 


Jay Cosgrove: And the thing that it’s holding to if I’m not mistaken, though I haven’t used it is the removal of waste.


Rob Hall: That’s right. 


Jay Cosgrove: That’s the whole focus of being lean.


Rob Hall: Yeah, exactly. Literally, it is intended to remove action that is extraneous, remove meetings that are extraneous, and minimize level of effort to maximize efficiency. 


Jay Cosgrove: So you would probably see, would this work well for kind of like MVP land, where you’re only working on the thing that you absolutely need to get out the door? Is that what we’re talking about? Or is it different from that? 


Rob Hall: You know, that’s a good question. Lean really, I think tends to work well, when you need a complex process to orchestrate many different people across a multitude of roles when you’re dealing with complex systems. 


Jay Cosgrove: So making a large team more efficient? 


Rob Hall: Potentially, yes. So I mean, it will take the automotive industry, right, like where it came from. You’re trying to build a car? 


Jay Cosgrove: Yeah, thousands of parts.


Rob Hall: Lots of parts, lots of different people, a complicated factory that’s building those parts on the fly, mind you, 


Jay Cosgrove: Right.


Rob Hall: And trying to maintain a high degree of quality because lives are at risk. Sure, that rigidity to process is an absolute necessity, because deviation from process means failure, right? And so the whole point of lean is to minimize that failure. But what that has the effect of doing I think you could argue is minimizing personal input. 


Jay Cosgrove: Yep. 


Rob Hall: I’m supposed to follow the book, right? Follow the guide, follow the process and not think for myself because if I think for myself, someone’s gonna die. 


Jay Cosgrove: Yep. 


Rob Hall: That’s not the case when we’re building software. 


Jay Cosgrove: Yes. 


Rob Hall: Right. Maybe in some enterprise world, that’s the thing. I personally don’t know any software companies that have successfully implemented Lean. 


Jay Cosgrove: Yeah.


Rob Hall: I don’t know any. I’ve asked people that I know and they’re like, uh, only folks I know, that operate leaner manufacturing firms.


Jay Cosgrove: Yeah. So I think it’s been a hard crossover, though, I’m sure you would find certain values from from Lean being used in large organizations to try to clean up the garbage that’s going on. But I think most of the time you are going to straddle some sort of combination of waterfall and agile, which is where we land so 


Rob Hall: Yes.


Jay Cosgrove: back full, full circle here.


Rob Hall : Even though we have become more formally agile, like our product team is mostly Scrum certified, our process is very much a hybrid process. A lot of that depends on just what the engagement is that we’re performing. So for example, if we’re running a workshop for a client, that’s not agile, it’s a one day workshop. If we are performing a formal design sprint, that’s a two week block of time the design sprint itself is only five days but we add an additional amount of time for prep, early research, things like that. The activities in a design sprint are not variable. They are what they are. Yesterday is tightly planned, and it is always the same. There’s a little room for variation depending on the needs of the client, but for the most part, there’s very little deviation from one design sprint to the next.


Jay Cosgrove: Obviously they’re not going to be used in your typical product development. Like actually developing out the full product.


Rob Hall: Depends on the problem you’re trying to solve.


Jay Cosgrove: Yeah.


Rob Hall: Honestly, I don’t know. That seems to be always the answer to every question is, “Well, what depends.”


Jay Cosgrove: What kind of contract should you go with? 


Rob Hall: It depends. So, but, yeah, to answer your question, Jay, we very much have a hybrid process. And so like I was mentioning earlier, research is still waterfall esque. Right? 


Jay Cosgrove: Right. 


Rob Hall: Product Design is still waterfall esque. We have a project going on right now where we do have research, design and development running in parallel being structured by sprint. But as you pointed out earlier, there’s still an aspect of a cascading waterfall going on. 


Jay Cosgrove: Yeah.


Rob Hall: Right? I don’t know that that you can really call it true agile, aside from just the reality that the efforts are being planned in an agile manner


Jay Cosgrove: Right. 


Rob Hall: And are running concurrently. It’s not like development is sitting there waiting on product design to complete their work.


Jay Cosgrove: Yeah, and if you think about that true definition, again, of kind of think specifically Scrum, where you would see a ticket move all the way across the board going through all the cycles that need so from a value statement, right, a user story up to being live within two weeks. Very rarely have I seen that done. I have seen it done. I mean, like we’ve, the one example I can think of is I had a project that had a three week sprint cycle. It was technically a four week sprint cycle, because it was a really large client and the actual contract dictated that. So the story would start and in the first week design would crush that piece of it. It was already a designed product, though. And it was really adding or changing features to that. 


Rob Hall: Sure. 


Jay Cosgrove: So it wasn’t, it still wasn’t true. And when we think about it as like digital scientists, most of the work that we do here, I shouldn’t say most but a lot of the work is designing a lot more than just a small feature onto something that already exists or small widget, right? You are concepting this new thing or trying to create something new, right, which is very hard to, you know, have design and running parallel. 


Rob Hall: It is, you know, I think that that speaks to the reality that there isn’t a clearly black and white right or wrong choice. 


Jay Cosgrove: Yes. 


Rob Hall: And I would say, especially for the work we do being more R&D oriented, we have to have a bit of a hybrid approach. 


Jay Cosgrove: Yeah.


Rob Hall: I think where it has behooved us is to pull forward development and make them a greater, more intentional participant in the design process. Instead of having this big tumbling waterfall of a handoff between design and development. Having them be an integral part of the design process, I think has made their efforts more efficient. Nevermind it’s caught a lot of things faster


Jay Cosgrove: Scope creep, okay. 


Rob Hall: Absolutely. Yes. Or just things that might not be feasible foundationally. 


Jay Cosgrove: Yeah.


Rob Hall: A designer propose some great piece of functionality, and the developer might have to throw a red flag and say, “Hey, hold on.”


Jay Cosgrove: Yeah.


Rob Hall: We can’t do that until we do this. Think about it the other way around.


Jay Cosgrove: Yeah. For anyone listening, do that. I don’t care what process you’re using. Have development involved in design


Rob Hall: Yeah, they have to be.


Jay Cosgrove: and try to pick someone on the dev team that can be a bit of a visionary. You don’t want them being the naysayer, that’s always crushing everyone’s hopes and dreams. 


Rob Hall: If they have people skills, that’d be great. 


Jay Cosgrove: Yeah, that would be great. 


Rob Hall: I don’t mean to be facetious.


Jay Cosgrove: But it’s so critical. And mature designers are going to love this, because they don’t want to design something that can’t be built, or to really be kind of deconstructed and look like a Frankenstein when it comes out the other end.


Rob Hall: That’s it is, the more it can be a collaborative process the entire team wins. It’s so demoralizing for a product designer to work really hard on something over a long period of time, hand it off to development and have just a bunch of red lines slashed through it. 


Jay Cosgrove: Yeah. 


Rob Hall: Without any ability for them to respond or work through it and iterate. 


Jay Cosgrove: Yeah. 


Rob Hall: The more collaboration that can be encouraged, the better.


Jay Cosgrove: Yeah, I agree. And for those that have not listened to our podcasts on contract types, we hit that point pretty hard is your contract will a lot of times dictate how much collaboration you can allow. And we’ve just found the most success in the most collaboration between design and development and product, just all being able to work together. And it does come down to a cultural barrier too, depending on how your org is set up. But as the PM, if you’re a PM listening to this, that’s your job. You know, you got to pull them together and figure out how everyone can communicate for the good of the user. 


Rob Hall: That’s right. Come back, though, to this agile versus waterfall tension. We’ve realized that a pure waterfall approach doesn’t work. 


Jay Cosgrove: Yep. 


Rob Hall: But at the same time, a pure agile approach doesn’t necessarily work either. But we’re trying to answer the question, how do you apply design to agile.


Jay Cosgrove: I think what have landed on that works fairly well for us is waterfalling design into development and development is working more in an agile manner. So what do they call that like Scrum-fall? So I don’t know, there’s lots of clever words for it


Rob Hall: I think you’re making up stuff.


Jay Cosgrove: But that seems to work well, if you have tight collaboration with development during this time. And that means during your dev sprints, if they’re running in parallel, that you have to account for time, in maybe even a story on the board for the developer to be working with the designer on this. And this gets into the dicey area to have, you know, how do you task out your design team? Well, they even look at the ticket you task out and spend all your time on. That’s obviously an internal battle, that you’re gonna have to figure out for yourself. But the collaboration has to be there. That’s the point. 


Rob Hall: Yep. 


Jay Cosgrove: And we’ve encouraged on every level, to not be so dedicated to one type of project process but to be more agnostic and see what fits best for what project. So to me, that’s one of the marks of a more senior PM, if I’m interviewing them is, have you gotten to the point in your career where you realize it’s not just one flavor of Agile or waterfall or whatever that is successful.


Rob Hall: Because you can, you can be so rigid with agile that you take the Agile out of it. And I’ve seen that before. You have to have some level of discernment.


Jay Cosgrove: Yeah. Well, I mean, people will literally, I think Scrum is the big one everyone knows. 




They’ll hate it. I mean, they hate their life in Scrum. 


Rob Hall: That’s right.


Jay Cosgrove: Yeah. 


Rob Hall: But you’ve got a slightly overzealous Scrum Master is beating everybody upside the head with every last little ceremony and even there, you have to use discernment. Do I need to have a demo? Is it appropriate to have a demo? Are we going to ever release the sprint? How long should the Sprint Retrospective run? Yeah, those types of things where the good product manager has to exercise some critical thinking to understand how much of the process needs to be adhered to at a given time.


Jay Cosgrove: Yep. 


Rob Hall: And when to pull back. Likewise, just when you’re structuring an engagement, what aspects of waterfall might make sense depending on what you’re doing and what the strengths of your team are?


Jay Cosgrove: Yep. I think the big note here is backup far enough when you’re rolling into a new project, to think about the team you’re being staffed with, the project that’s in front of you, the contract type, the stakeholders, and to give yourself the freedom to consider something that isn’t what you’ve always done, because that might not be the right answer. And for for us, for example, I’ve been very grateful to have Rob as my boss that allows that flexibility 


Rob Hall: That’s right. 


Jay Cosgrove: Yes. Where I’ve got one project running konban and it’s much more loose and we release when we need to and part of that is because I can rely on their word and their say so a little bit differently than I can on some of my other projects. It’s also smaller. And then I have another project that is Scrum. And I’m using all the ceremonies, though I’m still flexible in it. So I think you have to remain flexible to what the team needs. And it’s funny because like, if you’re a scrum master or a product owner, or wearing both hats like we do here, then a lot of times you’re going to see if you’re implementing Scrum, you’re going to get to a retro and some of the things that people throw up in the “I don’t like from this sprint board” is going to be parts of the ceremonies 


Rob Hall: Sure.


Jay Cosgrove: Or part of the structure that is there. And at some point, when you’re mature enough, you’re going to realize you don’t have to justify that. 


Rob Hall: Right. But see, that also speaks to the intended outcome. Like for example, you mentioned two different projects. One of them you’re following more of a Kanban approach. The other is pretty much pure Scrum. Well, the Kanban approach is an R&D project that we don’t really know what the outcome is intended to be. It’s coalescing over time. 


Jay Cosgrove: I mean, two days out, I don’t know what it’s gonna be.


Rob Hall: Exactly. We’re not sure what kind of feedback we might get from the client. It’s very much an exercise where we’re wandering in the wilderness just to see what’s possible playing with new technology. And so we don’t need that rigidity of process. Whereas the other one, like tactical delivery is important. You’re operating on a series of services that are in production that have live customers and real users. And the team’s got to be on point.


Jay Cosgrove: Yep. And it comes down to like I mentioned, it comes down to the team too. So it’s on the scrum team, I’ve got multiple developers working on it at varying grades of skills, and they need that structure to know what to expect from day to day.


Rob Hall: Right. 


Jay Cosgrove: And so I know that I need that there. However, if it got to the point where staffing changed, I may consider going to more of a Kanban model range that’s really gonna adjust based on the team. But I think it’s important that you’re able to pick what works best and then learn when to pivot when necessary. 


Rob Hall: Yeah.


Jay Cosgrove: And just be okay with it. But through all of that flexibility, that loosey goosey-ness that I’m describing here. You need to communicate to your team what the process is


Rob Hall: Yes.


Jay Cosgrove  

There’s real expectations for it.


Rob Hall: Absolutely. And you do need to exercise a great degree of consistency. Once you’ve committed to a process, stick with it. And don’t pivot away from that process unless there’s a real need and there’s consensus with the team that, “yeah, we can make that change. We need to make that change and here’s why.” 


Jay Cosgrove: Yeah.


Rob Hall: Otherwise you just create chaos and you risk not delivering. 


Jay Cosgrove: Yep, that’s right.


If you are in a project type where you need to maybe forecast a little bit better, and you have a little bit more of a product roadmap, dare I say.


Rob Hall: What? 


Jay Cosgrove  

What is that? Then I think Scrum is probably a little better fit for that. I’ve had a lot more struggle, doing long term large projects with Kanban and having expectations kind of met from a declared product roadmap. 

Well, I don’t know if I have much more on this topic, Rob.


Rob Hall: Aw, man. Good discussion. 


Jay Cosgrove: That was great.


Rob Hall: Thank you, sir


Jay Cosgrove: Catch y’all next time!