Greg Cohen in Getting Started with Agile

I’m here with Greg Cohen, 20-year product management veteran and author of Agile Excellence for Product Managers. Thanks for joining us, Greg. » Thanks for having me, Alex. » Greg, there are lots of statistics about this, like only 20% of features are used, and so forth. It’s generally accepted that we build a lot of software that nobody uses or nobody particularly likes. Why do you think that happens? Yeah I think there’s many reasons but I think fundamentally that comes down to a product management issue where we haven’t well understood the user needs, and a lot of companies and groups take this solution first approach.

And you only have to go back and understand what is the Problem that the user is trying to solve and from there design the solution. » Got it. And for the team that is getting started with Android which we probably accept this as a good vehicle at least to try and do that. What do you think is the hardest part of it getting started? And, what do you think are some of the earliest visible rewards for the team? » Right yeah, excellent question. So, for Agile the framework is really easy to understand, to get your hands around.

But if you’re working with a group of experienced software developers, QA people, product managers, they’ve already developed years of expertise in how to behave, right? And how to work and what those processes are and you have to relearn an entirely new way of doing that work. And human change is difficult. And, more than that, even if you agree with the framework and the actual principles, change takes time. And mastery takes time. And I think a lot of groups don’t really afford themselves that time to learn or have a fair expectation of how long that’s It’s going to take.

But when a team really get going, for me the rewards are a lot higher autonomy, and ownership of the work, a lot more creativity. And for management you get a lot more flexibility in your planning, a lot more predictability, and higher quality of code in product. » Let’s talk about all a bit to different audiences for that. How do you think that applies specifically to the manager versus the engineer? What’s specifically hard for the one versus the other? And conversely what are some of the earliest rewards they’re going to possibly see by doing Agile.

Right, yeah, so for the manager I think that the toughest behavior is to trust the team, and to maybe get of the mode of telling the team exactly what to do. And the developers what to do and giving them the problem and giving them the product team, the space to creatively solve that problem. » Mm-hm. » So that’s one of the real big challenges, changes of behavior both for the team and for the manager. And where this is hardest is if you’re in a company where deadlines have been missed And that’s used to doing that. Missing deadlines, lame assignment, you get a lot of CYA behaviors. The Module says we’re going to shift that now.

Right, that we are going to take joint ownership and joint responsiblity of the solution and that’s a really big change. And to get people comfortable with that. But when you get there, as I sort of mentioned earlier, I think that the biggest thing is that it’s a much more rewarding environment to work in. And from that you’ll get better product and from better product you’ll get better financial results. And that’s a positive feedback. » And what’s rewarding about it? What is the ideal environment like for these different audiences that makes it more rewarding?

So I think knowledge workers, I believe at the end of the day want to always be learning » Pushing themselves and creating things that are useful. They’re there for reasons other than just collecting a paycheck. Right, they are motivated by wanting to change the world and solve a real problem for users, especially engineers. That’s what they studied, problem solving. How do we solve these problems in a creative way? And apply our analytics to it. So when you get into that mode where you’re having influence in the product. You’re having ownership of it and you see how you’re impacting the user in a positive way and impacting financial results.

Your company in a positive way, that creates jobs satisfaction and gratification. » And how do you think this stuff differs between we’re making a product for an external customer, verses one IT project internally, and we’re putting the other system for people we work with? » Yeah, so I think some of the fundamental, » Differences they are my view the I.T. problem is a little easier, usually you have a no end set of users, they’re finite. They’re probably 1000 maybe a real large company, a thousand, a couple of thousand, and then you have a company that can maintain consistent process of those users.

So it’s easier to find your customers, it’s easier to go talk to them and pull them in and work with them. When you’re dealing with a commercial product, you might be in thousands, tens of thousands, millions of users and you’re looking for commonality. » Across all those different users, and often fundamentally very different market segments with different needs that you’re trying to at various points in the release cycle optimize for. So it’s just a more challenging product to do it on a commercial scale.

And in that case too, it’s often a little harder to get good customer feedback built into the process because now your PO is often very much really acting as a pure proxy for all these different segments. And in an IT project, you can go out and much more easily pocket through your users. » That’s great. That’s a great practical advice on kind of the what and the how of. Thanks, Greg.