Nathan Gilmore:     Welcome to another episode of Time Limit, the podcast where we talk about how to make the most of our limited time in business. We're gearing this specifically towards people who are leading projects and want to figure out how to be most efficient with your limited time.
                   So, today we have three of us here. It's myself, I'm Nathan Gilmore, one of the co-founders of TeamGantt. Also with us is John, who is another co-founder here.

John Correlli:      Howdy.

Nathan Gilmore:     And we have Brett, a very good friend of ours here with us today.

Brett Harned:       Hello.

Nathan Gilmore:     So, I'll ... I'm going to give a little intro to Brett, because we're really thankful to have him here with us today, and we're really thankful to have been working with him for the last ... it seems like it's been about, I think, about five years now, according to what we were talking about earlier, so-

John Correlli:      Wow.

Nathan Gilmore:     ... five years, it's crazy. But Brett is a good, a good friend of us here at TeamGantt. He's not too far away. We're in Maryland, and he is ... You're in Jersey now, right?

Brett Harned:       Yeah, now in Jersey, yep.

Nathan Gilmore:     So, we first started working together years ago when Brett authored The Guide to Project Management, which is on our website, and it's, what, eight? Nine chapters, I believe, full of really good information. It's been read by over 700,000 people now.

Brett Harned:       Wow, I didn't know that.

Nathan Gilmore:     Yeah, isn't that crazy?

Brett Harned:       That's amazing.

John Correlli:      Wow.

Nathan Gilmore:     And previously in his career he was VP of project management at a popular agency called Happy Cog in Philadelphia. That's where we first met him, and he's project managed high profile projects for companies like Zappos and MTV while he was there.
                   He also founded the Digital PM Summit, which is a conference that happens once a year, and a bunch of project managers get together. He has built an entire community around this conference, around this group of people, and he has been in the middle of his.
                   Brett, when did you first start that conference?

Brett Harned:       I think the idea came up in around 2012, the first event happened in October of 2013. So, I'm now currently planning our sixth Digital PM Summit.

Nathan Gilmore:     Wow.

Brett Harned:       Yeah.

Nathan Gilmore:     That's awesome. I think that's how we first got connected, too, was through that-

Brett Harned:       Yeah.

Nathan Gilmore:     ... and meeting you through that. So, that's something we've sponsored a few times, that we've attended, and it is a great conference, if you're looking to go this year. It's definitely a great place to go and connect, and meet with other project managers, people leading digital projects. They always have a lot of great speakers, and a lot of great conversation there.
                   Brett is also currently running his own consulting agency, where he helps teams from large and small companies optimize their process, and project management structures. And if all that isn't enough, he just released his first book, which was published by Rosenfeld Media, called Project Management for Humans.
                   Brett, welcome, thanks a lot for being here, man, we really do appreciate it.

Brett Harned:       Thank you, and thanks for that great introduction, I really appreciate it.

Nathan Gilmore:     Yeah. Yeah, absolutely.
                   So, today we are talking about agile, waterfall, hybrid, and we just want to talk about, try and get a sense of what most people are doing. Brett, we thought you'd be perfect since you are in the community, so deeply entrenched, we thought it would be good to ask you a little bit about this.
                   And one of the first questions is, I think most people probably know what agile is, but if you've got a little 20-second intro of just what, if you could summarize that?

Brett Harned:       Sure. So, agile is, it's pretty much a time boxed iterative approach to delivery. So, basically building something incrementally rather than delivering it all at once. It works by breaking projects down into bits of user functionality, or features, and user stories, prioritizing them, and then just continuously delivering in short, two-week sprint cycles.

Nathan Gilmore:     Now, how many people do you think, how many teams do you think, are doing pure, 100% agile?

Brett Harned:       That's a tough one, because a lot of companies will say that they are agile, but then if you kind of scratch the surface, you find out that they're kind of hacking it to make their own way of sort of creating an agile process.
                   So, I think the companies who are definitely doing strict 100% agile are those that are product companies like yourselves, like companies who don't have boards of stakeholders to deal with, clients to work with. It doesn't mean that they're not using some form of agile in those other companies, but it's just not that very strict, by the book process.

Nathan Gilmore:     Yeah. And why do you think it is that people have trouble following 100% pure agile? What are some of the reasons for that?

Brett Harned:       So, for agencies, a big problem is with agile you need a dedicated team. So, you need one team working on one project at all of their time, and it's really hard, in an agency setting, to split that time, because you end up having a lot of projects and priorities, and probably not enough staff to cover them all.
                   I think clients or stakeholders is another one. So, I'm working with an internal team in an organization now, and they are just so wrought with politics that it's really difficult to make a decision. As much as they're trying to make an agile process work, every time a decision has to be made, or even that they feel like a decision has to be made, things fall apart, and it totally breaks the agile process. Which is fine, you know, you find ways kind of around it.
                   A lot of times also, you know, people want to work in an agile process, then they realize there's a lot of onboarding and research that they need to do before they jump in. Then there are decisions to be made in terms of, like, if you're designing a product, you know, when you start to talk about look and feel, if there already isn't some kind of brand presence, there's a lot of kind of roundabout conversations in making the decision, or landing on a final decision, that I think sometimes just doesn't work as well in an agile environment.

Nathan Gilmore:     Yeah, I think that's a really, you made a couple good points there, and one about how agile really requires a dedicated team, and how often that's not the reality. Often you're sharing some kind of resources, you're sharing people. Or maybe there's outside people involved, outside stakeholders or something, that you're relying on something from them. And at that point it gets tough to do a pure agile flow, when you have dependencies between things, or different people involved.

Brett Harned:       Absolutely, yeah. I mean, I've even been on projects that are running a more, kind of, I wouldn't say totally strict agile, but a more agile process that, you know, another third party gets involved, that complicates things, there are dependencies on other projects and tasks, and that just starts to break things down too. So, anything that's going to stop you from just planning, building, demoing, and moving forward, is basically going to be an impediment.

Nathan Gilmore:     Yep. I think another thing, too, is you might not have the right client, or the right boss. So, maybe people want to see a timeline or something. How often do you see that? Where people are saying, you know, we need a timeline, we need this, but yet you're trying to be agile, and there's this conflict there.

Brett Harned:       Always, yeah. I think, you know, the thing about projects in any organization, whether you're a consulting agency or an internal team building a product, somebody higher up wants to know that the project, or product, is essentially worth the time and effort that a team is going to put into it.
                   So, when they hear, well, we're just going to build it iteratively, and we're going to start launching an MVP on this date, they think, well, why can't I just get the full thing on that date? And what does it mean if you're only launching part of the thing on a first date? Like, when am I going to get the rest of the stuff, and how long is it going to take you? And I think that becomes difficult.
                   So, I think the thing about agile is people have to be bought into the process from the top down, and it truly is the type of thing where everyone's got to be on board with the way that you're working, and comfortable, and sort of trusting one another in that process as well.
                   Whereas, you know, working any other way you can scope things out, you can provide timelines, you can provide things that are always an estimate of time and funding, or money, and there's a little bit of comfort in that. Even if things do go off the rails, you know, people can still provide an estimate for how much it's going to take to finish it.
                   But with agile you don't necessarily sit there and define the number of sprints that you're going to do, and say it's going to be done on this date, and with this certain amount of money. I think that's tough to grasp.

Nathan Gilmore:     Yeah, and I think sometimes there's a tendency to try and push agile into situations where it's not the right thing. Like, there are times where agile is good, right? Where you have a totally unknown solution, and you're like, I just have ... we don't know how to get there, we need to do a bunch of iterations, and it can be a good thing. And there's no dependencies on other teams, or anything like that.
                   But then there's other times where you may have ... maybe you have a known solution, so you kind of know more. There might be some question marks in there, but you have a better idea of how you want to plan it out.
                   So, maybe if you're doing a certain marketing project, probably a lot of agency work, or different things, where it's like, you kind of know there are certain things that have to happen, and then maybe a hybrid or waterfall solution can be good.

Brett Harned:       Yeah, definitely. And I think, you know, out of everything I've said, I don't want anyone to think that I have a problem with agile. I think it definitely works in the right scenarios, and it actually is a really fun way of working, too. I mean, it's super collaborative in that, you know, a full team works together to make decisions and set priorities.
                   And, you know, if you're in the agile process, and you're doing testing, and you're iterating based on kind of what the findings are, that's really cool. You're able to build something quickly, and iteratively, with the feedback that you need.

Nathan Gilmore:     So, there seems to be not a whole lot of people doing 100% pure agile, not a whole lot going pure waterfall, especially in software development and agency world. What do you think the ... How many people are doing some type of hybrid solution?

Brett Harned:       I would say most people are probably doing a hybrid solution, and when I say that, I think there's no one specific way of saying what your hybrid solution is. But I think, for my definition, it's like, the minute that you stray from that strict agile practice, you know, what any kind of agile coach would teach you, is the minute that you're creating your own hybrid process.
                   So, whether you're changing the ceremonies that you're doing, or you're changing the way that your team is operating sprints, or taking on multiple projects at the same time, you're just kind of straying away from that kind of by the book approach.
                   And I think there's a lot of ways that you could classify that hybrid system. The way that I typically look at it is through the lens of design, and working with stakeholders who need some level of approval or input in that design.
                   And I think you can do that within a more kind of agile workflow, absolutely. But I think when you start to involve more people it drags out the process, and it gets really tricky to figure out when to roll feedback into a process, and how to gain approvals.
                   I also think, you know, there's obviously the whole research aspect of it that can't necessarily be done in an agile process. Like, you can say we're going to do a sprint that is, like, stakeholder interviews, or user research, but kind of really doesn't make sense either, right?
                   So yeah, I think there's a lot of different ways of doing it. A lot of people are just trying to learn everything they can about a process, and then they just adapt it to what's going to work for them, and their clients, and their projects.

Nathan Gilmore:     Yeah, absolutely. One thing we wanted to do is talk a little bit with John about how we're running development projects here at TeamGantt, because we've kind of fallen into a little bit of a hybrid solution. So, John, do you want to explain that a little bit?

John Correlli:      Yeah. I think, for us, we've got a mix between waterfall and agile. We're using waterfall as more of the big picture, you know, where we want to be on a month by month, quarter by quarter basis. You know, we've got rough ideas of how long things are going to take the dev process to be, so we know how far, you know, research and design needs to be ahead of us on the dev side.
                   And then it just gives us our goals and our targets to shoot for. Then, you know, we're keeping track of our baselines, so we can see sort of how our original estimates are comparing to what we're actually outputting.
                   And then sort of taking that process, you know, with just strictly the dev team, we're using a pretty agile process with, we've got a backlog that we're managing, that we fill from the Gantt view, from the waterfall vision of the company. Then, you know, when we go into sprint planning we basically pull out of there into the sprint. Sort of the normal process there.
                   But what's helping us is that we're using the waterfall to steer the direction of sort of what we're working on, and then once we get that we're taking advantage of the benefits of agile to accomplish it.

Nathan Gilmore:     Yeah, and it really helps us coordinate, like John said, the design helps us think, like, what do we need to do in advance for design, especially for the bigger projects. We have some bigger projects going on right now, where they do span a good bit of time, and we want to kind of set ... in a way we're setting budgets too.
                   So, we might say, for this quarter, like, we never really plan out more than a quarter in advance, especially for what we do, it's just, it would be too far in advance, and we do want to stay nimble. But so, we'll plan out a quarter, and we're kind of setting budgets.
                   Like, we know we've got about eight weeks to try and get this done. So that helps us when we decide, you know, that might ... eight weeks could be four sprints, and we're saying we want to try and get it done within then. So, from a design perspective, we're not trying to throw in tons of new features, because we know, from a business point of view, we want to try and get this done, because we've got other things we need to get done too.
                   So that helps us from a business and strategy point of view to do that, and for John and I to be on the same page, and kind of know what we're trying to accomplish. And then they do break it out into more of an agile flow.
                   So, I think that's been helpful for us. And it's also not like it's all set in stone. We don't set this quarterly plan and say this is absolutely what we're doing, and we're not going to ever change it, you know? As we learn, if we learn new information a month in, or two months in, we're fine with looking at our plan and saying hey, maybe we can take this out and put something else in. But at least now we have a plan, so we know what trade offs we're making.

Brett Harned:       That makes sense to me. I'm interested to know, like, so do you have a roadmap view of everything by quarter, is that how you operate? Or is that what you're saying is kind of in the Gantt chart?

John Correlli:      Yeah, yeah, pretty much. We're using the Gantt chart as the roadmap of, you know, we've got pretty much the current quarter, and a little bit into the next quarter fleshed out, sort of what our main goals are, then beyond that it's kind of rough ideas, and we're always sort of shaping and refining that as we go along. We're using that to steer our sprints.

Brett Harned:       Yeah, that makes sense. I think you just have to be flexible either way, right? To just be able to get work done in a way that's going to work for everybody on the team. Has your process shifted since you started working together?

John Correlli:      Dramatically, yeah. I mean, if you look back, I guess it was two years ago, two and a half, I was the only dev here, so we were, you know, at that point we were just strictly waterfall, because I could only kind of do one thing at a time anyways. And as we grew we sort of, we learned that we had to manage the dev lifecycle a little bit differently. You know, there's more to manage, there's more things to do, and we've implemented retros, you know, we've got the biweekly sprints now.
                   And just even within that, our process is always shifting and morphing to be better. We're stripping out what's not working. We're strengthening out what's working well. Then, you know, we're always introducing new ideas to see what could make it better, give it a shot, and if it doesn't, we get rid of it.

Brett Harned:       To me, that's the best way of working. It's like, you know, anyone who's sitting down and saying we've got to take a class and follow this book is just doing it wrong. I like the idea of knowing, like, taking the class and reading the book, but knowing that you can alter it in a way that's going to work best for you, and just kind of being agile about your own process, right? Like, sitting down to talk about what's working, what's not working, and then just getting better as days, weeks, months, years move on. Things are going to change, they have to.

John Correlli:      Yeah, and that's what it's all about. It's finding the process that works great for you. And what we had worked great in the beginning, but as the dev team grew we had to change things up, and as it grew even more we had to change things up again.
                   You can't really be married to one way or the other. You need to find what's going to work best for you. And even the devs, you need to do what you can do to make them as successful as they can be. It's sort of a, you know, we're all in it together type of thing, so let's come out with a process that helps everybody win.

Brett Harned:       Absolutely.

Nathan Gilmore:     And it's interesting, too, I think it also depends on the type of projects we're running here internally. So, that's how we've been doing our dev projects, but, like, recently we had a marketing project. So, we're starting a new webinar series, and we had some pretty tight deadlines we set for ourselves. We set some pretty good time limits to try and set some aggressive goals and get things done quickly.
                   And we knew exactly what we needed to do. We had to make some email changes. We had to find some new webinar software to use. We had to get Brett signed up to do it, so he actually led the webinar. And we had to figure out a bunch of different things, a few technical changes, and some marketing involved, and everything in it.
                   And to do all those things there was a certain order, there was a certain series of steps that needed to be done. So, naturally, we just went straight up waterfall, with a straight up Gantt chart, and just said here's where we are today, here's where we need to be done, here's all the pieces. We checked with everybody on their availability to see if they had the time and the bandwidth to do it, and everybody had their individual deadlines for each task.
                   And by doing that we were able to hit a very tight timeline and get it done. So that was a different thing, where it's like, not like some of our software development, where we're really iterating, we're not sure which way we're going to do, and we're changing things. This was more like a we know what we need to do, let's just do it through our waterfall.
                   So, Brett, what have you seen in terms of hybrid? Do you have any examples, or anything you want to share, that you've seen as kind of an interesting way people are doing a hybrid solution?

Brett Harned:       Sure. So, I've seen it done in a couple of ways. Currently working with a group on a project that is definitely hybrid. You know, the idea at first was, you know, let's do sprints, everything was all about sprints.
                   And then, I think, once they jumped in and realized the size of the organization, the size of the project, and the complexity of it, this is a huge institution with over 20 departments who all have a stake in a website redesign, once they realized that complexity it was like, all right, let's take a step back and figure out how we can account for involving all of these people in the process, because if we don't we're going to have major problems on our hand.
                   So, the way that that kind of broke down was rather than jumping in and, you know, working ... The advantage of this project, and the reason why they thought that an agile process would work was because they have a pretty well defined brand and design system, so design is almost secondary in the project, because the design system is really well defined.
                   But then, you know, again, talking about stakeholders, it was like, all right, well, we have to take a step back and look at the landscape, talk to a number of stakeholders, have a lot of conversations about content on a really content rich website, and then bring it back to a level where, okay, let's start to identify what our top priorities are for an MVP launch. Knowing that the organization wants something in the fall, knowing that it's winter now, like, you know, say about nine or 10 months to get a project done is not enough time to do a whole project.
                   So, we took a step back, looked at priorities, identified, I think, four or five features to build, and basically have set up a schedule where as soon as research is done we're jumping straight into sprints, where we're going to be gathering requirements, designing and building, demoing.
                   And then, when the demo comes in, that's where things get a little complicated, because it's not like you can get like eight people in a room an say hey, how does this look? It's much bigger than that. There are committees upon committees.
                   So that kind of breaks things down. It just stretches things out a little bit. But we're able to kind of hold intact the idea that we're being iterative, and building things in a way that is agile-ish. It's not totally the agile process, but I like it, because I think we're going to see a lot of progress quickly, as a team.
                   I think where things might drag out, and drag down, is with the stakeholder reviews, and the amount of feedback that's going to come in, and the wading through that feedback, and pushing for the right decisions. But I think the idea that we know we can build something fairly quickly having requirements and defined stories is pretty exciting for everyone.
                   It's just going to be a matter of getting to that finish line, training people in a content management system, which is kind of going to break out of that sprint cycle, doing a lot of content work in the background, which kind of breaks out of that sprint cycle.
                   But when you think about just delivering a specific feature separate from the content that needs to be a part of it, it's a pretty agile process. It just, we kind of have broken it down, and definitely stretched it out in other ways, because of involving people.
                   So that's one example.

Nathan Gilmore:     Yeah, that's a good example. And I think, because there are so many people involved, and there's a timeline, but yet you still want to do agile, it's just, it naturally leads to a hybrid process.

Brett Harned:       Yep. And I'll say, too, it's another project where the higher level executives want a timeline. So, we've got everything in TeamGantt, everything is laid out so that they can see what's happening and when.
                   And even kind of, like, steps within a sprint are spelled out, so the sprints, to them, look like a mini waterfall project. Which is fine, we're still going to operate the way that we want to operate, but we're just making concessions of, like, trying to explain the steps as much as possible so that we can just get them on board with the work that we're doing.
                   Because I think, you know, the other part of it is education. A lot of people in those higher up positions don't understand what it actually takes to do this work. They don't understand why they can't get a whole site in nine months.
                   So, you know, it's all of those factors that just affect the way that you've got to work, or craft a process.

Nathan Gilmore:     I think that helps when they see a timeline of a project, because you can really, that's how you communicate it out to them. If you say, we're just going to do agile for nine months and then we'll have the project, they're like, what's that mean? Like, why? There are so many question marks.
                   But when you show them that timeline, and even if you put the sprints, we see people do that all the time, they'll put sprints as tasks, or as groups in TeamGantt. And then you can just kind of clearly see, we're doing this research, we're doing sprints, we're doing demos here, we're doing this, we're getting feedback, we got a marketing push here, we're going to set up this here. And when they see the whole timeline it makes them feel a little more confident in what's going on.

Brett Harned:       Absolutely. It would make me feel more confident.

Nathan Gilmore:     Oh yeah, any time you know a plan, and you can see a plan, everybody feels better, and everyone kind of knows what's going on, and you know it's been thought through.
                   So, to summarize a little bit here, just roughly, I think there's a few buckets of when you want to use each system. And Brett, I'm going to try and summarize this. You let me know what you think about this.
                   But I think to use pure agile there's a few things, one is you've got to have a completely dedicated team. You can't be relying on outside people. It should be something where the solution isn't known. You've got to iterate a lot. And it could be something like developing a new software product, and you got a nice internal team that's just going to keep iterating, and you really don't know what you're going to be doing in a month from now, and that can be a great solution for agile.
                   Would you agree with that?

Brett Harned:       Yeah, I think you kind of nailed it. It's like, you have to be open to change, whereas in waterfall you're not as open to change, because things are really strict, like, any change is a big freakout.

Nathan Gilmore:     Right, right. And waterfall might be, like, pure, pure waterfall could be, for example, like one extreme would be a construction project. You know the steps, you know, you know, have a deadline, and it's the same thing over and over [crosstalk]

Brett Harned:       There's no way around those steps, right?

Nathan Gilmore:     Yeah, exactly.

Brett Harned:       Like, you have to do it that way, because if you build things out of order in a construction project things are going to go gravely wrong.

John Correlli:      You mean you can't put the roof before the walls?

Brett Harned:       Right, exactly. There you go.

Nathan Gilmore:     You just keep iterating until you get it, you just keep iterating. Eventually, one day, there's a building.

Brett Harned:       Right.

Nathan Gilmore:     I think that's true, probably, for things too like, you know, you have a blog calendar, or like we were doing with our webinar project, it's like, we know what steps we needed to do, we just needed to lay it out and make sure we hit a certain deadline.
                   So, projects where you have a deadline and a known system is good for pure waterfall. And then hybrid is where, I think, that's where it gets a little blurry, and I think that's where you're not in either one of those buckets, where you have this ... you know, maybe you have, you want to iterate, you don't know exactly what you need to build, but you know you've got to do some iterating.
                   But maybe you have someone that wants a deadline, there's some kind of timeline, there's some kind of business decision there that you need to be able to make. Or if you need to be able to do some kind of resourcing, or dependencies, or your team isn't completely 100%. You know, one team you may be relying on other people, or other teams, or outside stakeholders. Then maybe you're doing some type of hybrid process.

Brett Harned:       Yeah, I think that's right, too. I think it's ... In the hybrid process, what I found was, like, you're trying to be a little more efficient, a little more collaborative and iterative, while also paying respect to the fact that decisions need to be made, and there's a timeline to the project, or a deadline.

Nathan Gilmore:     Right. And one thing, too, that's really interesting with hybrid, is it seems like there are not many tools designed for hybrid. Seems like there's tools designed for agile, there's tools designed for waterfall, but there's not really tools designed for a hybrid.

Brett Harned:       Yep, pretty much.

Nathan Gilmore:     Yeah.

Brett Harned:       It's a combination of types of things. You know, like for me it's a project plan combined with, like, a task list, or like a Kanban board, or something like-

Nathan Gilmore:     Right, right. We recently built an integration with Trello to help with that, and we're doing some cool things there. And we're also starting to explore some new ideas for TeamGantt of incorporating agile, and kind of coming up with a nice solution where you can have agile parts of your project, and a board view and everything, but you can still have your overall timeline view. And so, that's something that, this year, is a really exciting thing we're working on.

Brett Harned:       Awesome, that is exciting.

Nathan Gilmore:     Yeah, yeah. So, that's something too, if anybody is interested in checking that out early, or putting feedback in, because we really want this to be a community effort, and something that a lot of people can weigh in on. So, we're interested in hearing your thoughts or feedback. If you want to be included in that, feel free to drop us an email at TimeLimit@TeamGantt.com, and we'll include you in that, if you want to be.
                   Any other closing thoughts or anything from you guys? John? Brett?

Brett Harned:       I don't think so. I think if I were to summarize this in any way, I think it's just that learn what you can, know what you can and can't do, and just adapt your process to what's going to work for everybody involved.

John Correlli:      Yeah, I think I would summarize similarly. Just learn the benefits of both, and find a way to craft a process that's going to work for you and your team. What works for us might not work for you, and what works for you might not work for us. But, you know, it doesn't matter, you got to find what works best for you.

Nathan Gilmore:     Definitely. What's best for you, what's best for your team, what's best for your company.
                   Well, very good. Well, hopefully this was helpful to everyone, and we hope you liked it. If you did enjoy it, please feel free to rate us on iTunes and subscribe to the podcast. We're going to be doing more of this.
                   We thank you so much for listening. If you have any feedback, anything in particular you want us to talk about, please feel free to send that feedback over to TimeLimit@TeamGantt.com.
                   Thanks a lot, everybody. Have a great day.