It’s not a meeting II

We’re going to talk about a few more techniques to create better sessions, I’ll avoid the term meeting, with your collaborators as you scale up your existing product. One of the really tough areas is estimation and planning. And a lot of the time, the real problem here is the product manager, or the product owner, is trying to cram too much stuff into a cycle. And, I mean, that’s really rude, of a lot of push and pull, and this and that. And so, your main job as the product manager, is to help your team build less software better, with better focus. But to the extent that you need estimates to make decisions and prioritize things, I’ll give you a few ideas.

[COUGH] If you use some kind of story point system to look at your stories and say, how big are these? Probably so you can prioritize them, hopefully. Because precise planning is difficult and can be very wasteful. My main advice is, don’t get too specific. Use either, hey this story is going to take either minutes or hours or days or months. T-shirt sizes, S, M, L, etc, is another popular system. Some people use the Fibonacci scale, and some people pair that with this activity of planning poker. Where you talk about a story, all the developers put out a card where they say how big they think it is. And if they’re pretty much similar, then you move on.

If they’re not, then what you’re looking to discuss there is, is there a variance and everyone’s understanding, or is there a difference in how they think they would approach this feature? And that’s a good thing to talk about. Well the main thing here is we’re all optimists at heart. But you don’t want to just push people to create estimates that are beyond their envelope of visibility. You want to be able to think about, what am the product manager really trying to get out of this? Am I trying to just roughly prioritize things and make sure that I don’t think this little thing that I thought I wanted to do now.

Because I thought it was small is actually big, and I find that out. And I change my priorities, that’s a relatively good reason to want to do these. But they’re also a lot of really wasteful reasons, which is like having a super precise schedule. Which you’re just not going to necessarily probably know. And so the best way to do that is to keep things general. Stay focused on relative priorities and use tools like Planning Poker to add a little levity to the whole thing and keep it from getting too specific or too serious. Another question is, do you use the burn down chart? This is something where you add up the size of those stories.

And then over the period of your iteration from start to finish. You track on day x, day y, day z, how you’re burning down these stories. This is a relatively linear one. Oftentimes, they don’t look like that. Some teams find this helpful, others don’t. Many focus instead on what’s actually happening. And they look kind of after the fact at what is our velocity? How many stories do we usually finish in a week or a cycle? And that is a little bit, that certainly introduces less overhead into trying to create a prediction about what’s going to happen over an upcoming cycle.

So this is a real job, I mean, you need to know what’s going to be in a release or how soon something is going to come. But there are certain ways to do that that are more productive than others. Let’s talk about another job, Introducing Personas. It is really, really important to acquaint your development team with who the user is and what kind of makes them tick. It’s a big part of that desirability dimension and creating an intersection with that, and feasibility in your engineering activity. One fun way to do that, is you’ve gone out, done this research with these users, and you brought back a bunch of photos and you can play this game Day in the Life.

And the way the game works, is you show a series of photos from the research you’ve done on personas. And then at the end you ask the team a bunch of questions about the persona. And there is no right answer to the questions but the right process is to infer your answer based on what you saw. These are examples of the kind of photos you might have from your work on researching the personas. These are examples of some questions you might ask. These are all kind of fun questions, but you can also interweave some more substantial questions that have to do with the way your customer might use the product.

And the purpose of this really again, is just to get them interested in that user and get them a little bit familiar with who this persona is. And maybe if you’re lucky, persuade them to go sit down and read about the personas as they’re thinking through their user stories. The demo is something where I know in my experience, I was a sales engineer for many years. We always just tried to cram as much functionality into the demo as we could. It was usually stuff that wasn’t quite ready and it was kind of breaky. And we would always push it right to the edge. A lot of the time, we did break stuff.

And at the end, we’re always like, it was so dumb because the audience really just wanted to know why did we build this and what are we hoping is going to happen? All the little details of the software that we thought were so important to invest all this time in preparing that really didn’t matter, and we stressed ourself out. We broke stuff and I don’t know why we did that. Some kind of weird, negative target fixation. But I think it’s relatively common to just, you’re focused on the software. And you’re focused on implicitly all of the things that you wish were different about it. Instead, start with the audience.

Focus on what outcome you want with them from this meeting and then design the agenda that way. And you’ll probably find it has a lot more to do with explaining what you’ve learned. That the validated learning that led you to build what you built. And what outcome you’re looking for and some kind of conclusion output to the meeting.

The retrospective is one of the most important parts of a strong, high functioning, interdisciplinary team and the practice of agile. These are examples of the kind of questions you would ask. And what you’re really driving to is this question of, how do we want to to work together differently? This is not a meeting about, whose doing the most work or blaming people. You may want to accept those things or change them, but that’s a different issue. This is about the process that you use with your interdisciplinary team to work together and how to change that so that it becomes better. Another popular technique, as you’re going through the answers to these questions, is the 5 why’s.

So let’s say we’re asking, well, why did this bug make it out to production?

And the answer is, well, we didn’t run such and such a test on it. And then we ask, well why didn’t we run that test? And the idea is not to be, because Bill forgot or Jane forgot, but to ask do we need to fundamentally change the way we’re thinking about our testing infrastructure or our integration process? Because those are better answers, they’re more actionable answers. Because again, you’re not trying to fix or blame one little thing that happened. You’re trying to think about your overall process and how over the longer view of you working together with this team, how you make it better.

Finally, I would always take the time to create an agenda if you’re going to call a meeting. We started, in the last video, with this idea of how much a meeting actually costs, a lot. And I guarantee it’s worth 5, 10, 15, even 20 minutes for you to put together the set of questions you’re trying to answer. Probably even timeboxed them to keep the meeting on track. Specify the output you want from this meeting, and really think about who needs to be there and why? And so perhaps even pose the question of if they need to come or not. I think these are a few ideas that’ll make you a stronger interdisciplinary collaborator. Try them out, see how they go.

Some will probably work better for you than others. But those are a few focal points to think about.