Dave: Hey everyone, Dave here with another episode of the Philly Tech Entrepreneurs podcast. Today I am speaking with Mr. Gary Cohen. Gary has 30 years of experience in the software development industry as a developer, manager, and executive across various vertical markets. He has successfully introduced and cultivated agile thinking and cultural values at a number of different software and services companies. He works as a coaching consultant at executive management and team levels. He’s a certified scrum master, agile professional, and we’re going to be talking about all things scrum, agile, product development dos and don’ts, a lot of good stuff. So thank you, Gary, for chatting with me today. How are you doing?
Gary: Good, Dave. How you doing today?
Dave: I am doing well. Happy to kind of get into this conversation because these are terms that I have heard like a million times and still really fail to grasp and speak about educatedly. So I’m happy to talk with someone such as yourself who is an expert on the topic of things like scrum and agile. Thought it would probably be good to just start by defining kind of what they are. When someone says scrum or agile, you know, what do they mean? How are they different?
Gary: Agile is the general collection of different frameworks and practices that help us pivot and change direction and adapt and adjust in our software development efforts. So it’s like the broad umbrella. Scrum is one of the more popular ways of implementing agile. It’s maybe I’m not supposed to call it a framework, but it’s a set of practices that work together, things like a daily scrum and a retrospective, and the way that you plan out in two-week or three-week or four-week increments. So it’s a specific way of working that allows you to get some of the benefits of an agile development framework.
Dave: Awesome. Okay, that does put things in the context a bit about where they kind of sit on top of each other. So with product development, you know, we were talking before this and you had mentioned that there’s a lot of focus on optimizing delivery and not enough time of getting skilled at continuous product discovery. Elaborate, tell us a little bit more about, you know, where people are maybe prioritizing maybe a little incorrectly, right?
Gary: So if you think about most of the meetings that we have and most of the things that we get asked about, it’s about the delivery of a roadmap, right? And so when is this going to be done? And how do we improve our productivity and things like that, which is all good reasonable stuff, right? So here’s the problem though, is that if we get really efficient at delivery but we’re delivering the wrong stuff, then what have we done? We’re just doing the wrong stuff faster, right? So we should be spending at least as much time thinking about, you know, what’s the problem we’re trying to solve? What’s the market opportunity? What are the customer outcomes we want to get? And then how do we efficiently find the right fit and the right set of features that are going to make our customers happy and going to make our businesses money, right?
Dave: Yeah, it’s a great point. And I feel like there’s probably like decades of history here, but in your opinion, you know, why are we focusing on delivery so much? What’s of all the things we could be prioritizing, you know, why that?
Gary: I think number one, it’s more measurable, right? You see the output coming out, and we like to measure things, right? And also, it’s the end product, right? So it’s, you know, and people feel good. We have a plan, right? And we’re going to have these 10 features, and we’re going to deliver these features at this point in time, and we can measure whether it’s late or not. And we focus in on the end product. But the other thing to understand is that we’re very bad at figuring out what customers want or actually use and pay for. You know, something like 80% of the features that we create are rarely or never used by customers. So, like, we need to bring some of that experimentation that we already have on the delivery side over to the discovery side and kind of have a healthy recognition of how much we don’t know when we start out saying we want to solve this problem for our customers, right? We think there’s a good market opportunity there. We think it’s a real pain for the customers. But, you know, how do we actually, what’s the optimal solution for getting there, and how can we learn? How can we do small things on the discovery side, get some feedback, and figure out, okay, this is worth investing in to build a bit of the product and push it out to the customer? You know, but it’s an iterative thing on both ends, both on the discovery and the delivery side. And I think it’s just, it’s a little bit, we don’t like to admit that we don’t know things, and we don’t like uncertainty. So I think that’s probably the biggest reason why it’s taking longer to focus on both together.
Dave: I definitely sympathize with the problem. I’ve done software before as a business, and I know that we built a bunch of stuff at the time that really wasn’t necessary. And it’s bad enough to kind of invest upfront resources to build features that nobody really wanted to begin with, but then to then have to deal with maybe the bugs and the technical debt that kind of come up with them, and so and to then prevent you from being able to invest time in the things that people do want, right? But at the same time, if I understand you correctly, it’s obviously not that delivery should be completely overlooked. It’s more that discovery and delivery are this co-evolving process. So how do you kind of see the two working together?
Gary: So at first, discovery helps guide our initial delivery development efforts, right? We want to start off, we think this is the most valuable thing that we could deliver, or this is the area where we have the most uncertainty or the riskiest assumption. So let’s work on that first, right? And then once we deliver, we’re also getting feedback. Are customers actually using this or not? And that feeds back into the discovery process because the discovery process should not be a once-and-done thing upfront. It should be continuous, working in small batches. And so, you know, you get feedback on both sides. Let’s talk practical. You know, obviously, these concepts are great and important, but teams have to actually implement this. They have to execute it. They need to make changes in their SOPs. Leadership needs to be on board. I mean, what are the things that you advise people on as a coaching consultant? How do you kind of go in there and determine, you know, maybe some gaps in their process and eventually steer them on the right path?
Dave: Usually, we do some sort of assessment or observation upfront to understand the current practices. And there’s also the, what are we trying to, like, what’s the problem we’re trying to solve here in this particular company? Is it that we want to get more efficient at this discovery process, or is it something on the delivery side or both? But generally, you know, we want to work with leadership to kind of express to people why there’s a need for change, right? That if we keep doing what we’re doing, we’re not going to be successful. And on top of that, I can help leadership craft the vision of what the new world will look like, how things will operate, and how it will be obviously better, right? So that gives people the mindset of being open to change. And then it’s a question of, I have some principles that I can share of things that are good, like working in small batches, right? And experimenting and working cross-functional and things like that. But I like to work with the teams and the organization itself to figure out what are the actual practices that are going to work best for them given their unique context because it’s not like a come in and implement this framework, you know, and just follow the manual or whatever. It’s not like that. It’s understanding how to get things flowing better, how to get the feedback right. We really want the fast feedback loops. So we work smaller, and we’re putting in the hooks to get the feedback, bringing customers into the room both on the discovery and the delivery side. Then you get that critical mass that kind of helps you really figure out what’s exactly best for your organization.
Dave: And about how long can that take? I mean, like on the low end or the high end, you know, kind of, I’m leadership, I’m on board with with the change and the culture change and the way we approach product development. What are the expectations in terms of, you know, making these types of changes you’re talking about?
Gary: Well, obviously, it depends on the size of the organization. So if we’re working with startups, it probably doesn’t take very long at all. I’ve worked with big companies too, like Google and other companies, and changing the culture is a lot harder, a lot longer. I think the best answer to say is that we don’t look at it as a beginning point and an endpoint, you know? It’s continuous improvement and continuous adjustment and adapting to what’s going on because things are changing all the time, right? So what works for you in the first year might not work for you in the second year. But having said that, the idea is to start to see changes in the first couple of months, right? The first couple of cycles of doing discovery and delivery, and then to start to develop internal champions who really live the values of continuous improvement and fast feedback and working in small chunks, cross-functional teams. And then you start to build momentum from that because it becomes less about me as an external coach doing stuff and more about the internal folks on the team creating the ways that work for them.
Dave: Awesome. I love it. I feel like it’s, I don’t know, maybe I’m biased, but it seems hard to argue with this not being the way to go. I mean, it’s really just like a customer-centric approach to product development. So, Gary, for those who want to learn more, get in touch with you directly, how can they do so?
Gary: There’s a couple of ways. So, number one, I am on the Philly Tech Entrepreneurs Slack route, so that’s always easy. You can email me at gary@practicalagility.com. And we also have a website, so you can go to the website, and there’s ways to send messages there, schedule time to talk. And then finally, I’m pretty active on LinkedIn and always happy to connect and chat there as well.
Dave: Awesome. Thanks, Gary, for coming on, sharing your decades of experience in the agile world. I hope this was useful for people running product teams and others. Again, I appreciate your time.
Gary: Yeah, thanks, Dave. Really appreciate you having me.