Today I’m joined by Johanna Rothman. Johanna is the author of seven books. You can learn more about Johanna and the Rothman Consulting Group here.
Johanna, thank you for joining me today. You’re very actively engaged in the product development community particularly at the intersection of Agile and project management. From your vantage, are there many organizations that have successfully adopted Agile? Are there common characteristics for those that succeeded?
Greg, thanks for having me. All kinds of organizations have adopted Agile, from the perspective of the kinds of products they create or the systems they create. What they have in common is their culture. They’re willing to be or become more transparent and to be open to learning. When I say transparent, I mean transparent in many more areas than we normally consider transparency: the entire budgeting process for projects, programs, and the project portfolio, and compensation for people and teams. When you really transition to Agile, it makes no sense to do yearly budgeting. It makes much less sense to do a yearly individual performance review. And, many of our Finance and HR folks have no idea how to transition to Agile. Well, too few of our technology managers do, so let’s not pick on Finance and HR!
Why do you think executives struggle in scaling Agile across their organizations? Do you think there is a natural upper limit where organizations should reconsider implementing Agile?
No. There are natural breaking points. I’m working on a blog post now that will be in my program management book.
For program teams, there are small programs of 1-3 teams, where you just need a few more people to get the work done. The next breaking point is 4-9 teams. That’s where many teams try to do Scrum-of-Scrums. And, S-o-S works if you have everyone collocated and you have no hardware. I have no clients like that. None. Other people do. That’s what I call medium-size program teams. When I call that medium-size program teams, people sometimes get nervous. “That’s not large?” they ask me. Nope. Not large at all.
A large program starts at 10 teams and goes up. That’s 10 technical teams. That’s because now you need networks of teams. A hierarchy will not work. Scrum-of-Scrums works in a hierarchy and does not scale. However, a network will scale. That’s one of the reasons people think there’s an upper limit.
Now, at some point, you wonder how can an architecture “just evolve.” Well, you still have to shepherd an architecture. It doesn’t just evolve. So you need communities of practice around architecture and testing. You need people responsible for the business value of the roadmap, the backlog, and the architecture. And, if you want to know that you have a product that works, you need continuous integration as often as you can make it happen.
For me, the larger the program, the more you need continuous integration. On the largest programs, I like either Kanban, where people integrate their features every day, or iterations no longer than two weeks. Otherwise, you’re, as we say in the industry, hosed.
With so many challenges facing businesses today, how important is the product owner role?
The larger the program, the more critical the product owner role. In fact, for programs, I see a need for a program product owner role, where that person shepherds the business value of the roadmap and program backlog. It’s really a problem, because the projects have all the value in their backlogs. How do you know when to end the program? When there is no more value in the roadmap. It’s a critical role.
Do you think The Guide to the Product Management and Marketing Body of Knowledge will help organizations recognize the importance of the product owner role and overcome some of the challenges we have discussed?
I think so. As long as ProdBOK helps people to think, that’s what’s really important. I’m big on helping people to think critically. If they do that, I’m happy.
Why did you choose to participate in the ProdBOK project?
You asked. And, aside from that, product management and product marketing are critically important functional partners to project management, which is one of my areas of expertise. I wanted to make sure you had access to my experience and help in whatever way I could – I was happy to help.
Greg Geracie is a recognized thought leader in the field of product management and the President of Actuation Consulting, a global provider of product management consulting, training, and advisory services to some of the world’s most well-known organizations. Greg is also the author of the global best seller Take Charge Product Management. He is also an adjunct professor at DePaul University’s College of Computing and Digital Media where he teaches graduate and undergraduate courses on high-tech and digital product management.
ProdBOK is a registered trademark of AIPMM.