Here, we are excited to welcome the “Pragmatic Manager,” Johanna Rothman, who helps organisational leaders see problems and risks in their product development. A very special thank-you to Johanna, being kind enough to share her experiences, insights on the pragmatic approach to manage remote teams and workshops. You can read more of her writing and learn about her books. Rothman has an MS in Systems Engineering.
Johanna, you have a long track record in helping product and project managers become better at developing software. Tell us a bit about yourself and the specific things you do to help those managers?
Sometimes, I coach project and product managers (and program managers and regular managers). I offer workshops. Sometimes, I go visit a company and consult or do an assessment. It depends on what people want and what they need.
What do you see most software product managers struggle with?
I see several problems:
- The Product Owner is different from the Product Manager. The Product Manager is too vague and the PO has to guess what the Product Manager wants. That’s never a good thing, the guessing.
- Too few organizations realize that the roadmap is a wishlist. They often think they can get anything they want because it’s in the roadmap. Nope, the ranked backlog is more specific than the roadmap, and even then you can’t always get everything you want.
- I see so many product managers struggle with how to rank the backlog. Some people want to use some sort of financial benefit as a way to analyze the items. You might be able to use money in some sense, and I like to consider waste as one of those ways. Not everyone uses waste.
Read more : The Secret Formula For Distributed Teams
So there are two very interesting points you make here. First, the overlap between the product owner and the product manager. In what setting would you say it’s good to have both those roles versus just having the product owner role (who then talks to the users or business owners instead of the product manager)? Second, using waste to decide on the importance of a user story. How does this work?
It’s ideal if the product manager and the product owner is the same person. I see that as an “overloaded operator,” to use a technical term. The Product Owner role is huge. The larger the project (or program), the more difficult the role is.
For programs (collections of projects with one deliverable, where that deliverable provides more business value than any of the projects), I almost never see a Program Product Owner (the product manager) who can spend enough time inside the program. The Product Owners for each feature set/project need to work together and talk to the Product Manager/Program Product Owner to understand how to deliver value continuously.
As for using waste, when POs don’t consider waste, they get feature-itis. I wrote about how to use waste to evaluate projects in “Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects”. It’s the same idea for features. You ask, “Who cannot do what based on the absence of this feature/work?”
This is how you rank technical debt and defects in the backlog along with features. If you have technical debt, say you don’t have enough test automation, you can add a story/feature/something that says, “Pay off technical debt, 10 tests per iteration in this area, because not having it prevents us from doing continuous delivery.” (or whatever it prevents you from doing.) After a few iterations, you have covered that part of the debt.
There are many methodologies out there to help build better software like lean startup, agile, scrum. From your experience, what are the methods that truly help managers?
I lean towards lean and agile approaches. I don’t care about what you call your approach. I’m no ideologue. I care about people being able to release valuable product. If they find a way to do that, I’m all for it.
I love structure and methods, so what I often observe is that product companies work in a very unstructured way. Even if they say they use some method, it looks more like chaos to me. How do you help people find a balance between chaos and structure in order to release valuable products? (you can maybe put some excerpts from your workshops here?)
I see that, too. When I teach my agile and lean workshop, I model agile and lean. I use a kanban board to address people’s concerns. We don’t measure the WIP in that board, but we update it frequently.
Based on what the workshop people need, I change where we are in the workbook. That’s the agile part.
We release often in the workshop. We do a project in timeboxes. We look at the results of each timebox. We look at how we build trust as the people in the workshop, and what would have to happen to have that trust at work. Because we release and we look at our work in progress on a regular basis, people find a rhythm that works for them.
I came across an old post of yours about geographically distributed agile teams. One of the things that surprised me was that most managers say ‘we thought scrum would help’. Can you elaborate a bit on that?
Sure. Scrum is terrific for geographically collocated teams. It relies on real-time, face-to-face rituals that work quite well for collocated teams. These rituals do not work well for geographically distributed teams.
Let’s start with iteration planning. If you have people all over the world, how do you bring them together for the planning? Someone has to work late or work early. Neither is conducive to people working at their maximum capacity.
Now, add in stand-ups, the demo, and the retrospective, and you have a recipe for disaster. I often find that people skew their workday so they can be in touch with the people across the organization. If you have just a couple of hours skew, that might not be bad. But, I’ve seen testers work through their nights—they actually become second or third shifters—so they can work when their developers work.
This is not healthy.
Another interesting point you raised is to not hire testers 12 hours away just to save costs. It’s common to offshore testing. What’s the reason behind your finding?
I like developers to pair with testers. I find that the thinking they have when they work together is quite superior to handing off a “development-done” story to testers. In my experience, the testers don’t have the same knowledge as the developers. Too many people think the developers are second class citizens.
That’s no way to run any team, especially not an agile team.
When you have testers more than about 3 hours time zone away from developers, they depend on handoffs, not on collaboration. That makes any software product development quite difficult.
It seems to me that you speak with many companies that work with big time differences and several locations. In Europe, many companies work with Eastern Europe (1 hour difference) and India (max. 4,5 hours difference). If you have a complete team (including testers) in 1 office maximum 4,5 hours away from you, I have found that Distributed Scrum works very well (at least its better than most alternatives). (maybe you have some reply to this as we’d have if we had a real talk?
It seems to me that your European clients have a reasonable approach. Yes, I agree with you, once you have feature teams as you said, you can use a form of Scrum.
That’s not what I see here in the US. I see teams who are totally dispersed (one person in any given time zone), with time zones more than 12 hours apart for the entire team. I don’t see how to use an approach for real-time collaboration that way. I recommend handoffs, not realtime conversation in that case.
It’s more important, to me at least, to find a way to work where we can change what we need to do on a regular basis, rather than sticking to a specific way of working. A life cycle or project management framework is a model of what you can do. If you deliver value every day or every other day, and manage your WIP, you’re doing agile, most likely in a successful manner. That’s what I care about.
You have developed a special workshop for agile distributed teams. Can you tell us a bit more about the contents of that workshop?
Sure, it’s a blast. We simulate your projects and then discover ways you can improve your projects. The description of the workshop is here.
I teach it with and without Shane.
If you have three tips for a software product manager, new to working with a remote team, what would they be?
- Separate the roadmap from the backlog. You have to iterate on both, and you almost always iterate on the backlog more often.
- Make your stories small in the backlog. The smaller the story, the faster you get feedback from the team on your story and the faster you can see the product take shape.
- Know what your release criteria are for your entire project. If you don’t know what done means for the project, neither will the project team.
Read Next >> Lean Startup With A Distributed Team – Smart Solutions You Can’t Afford To Overlook