Erez Morabia - Roadmapping

Speaker A: Welcome back to another episode of Agile Way podcast where we explore challenges organizations face on their Agile journey. How to become great SCRUM Master, how to change your leadership style, or how to embrace agility at the organizational level. I'm Suzie Shikova, Agile Coach, certified Scrum Trainer and author of the Great SCRUM Master book and Agile Leader Book and I am your host for this podcast. I'm passionate about business agility, organizational culture and agile leadership.

Speaker B: And that was the reason why I

Speaker A: decided to start this podcast to share with you my experiences and stories from my Agile journey.

Speaker B: Hello everyone. Let me welcome Erez here today. He is one of the Speakers of AgilePRA conference that is happening on um, 9-15-16 this year. And Erez, what are you currently passionate about in Agile space?

Speaker C: Hi Suzy, thank you for having me. Um, I think in these days and actually in the last two, three years, I'm really passionate about how roadmaps are being handled in the Agile domain. I mean we all know how to get a good grip of sprints, but when it comes to zoom out roadmaps, it's a mess.

Speaker B: So tell us more about the roadmaps.

Speaker C: Okay, so when I come to organizations and M, my main role is vpr, indeed, Papaya Global. Uh, so I'm really about getting things done and delivery. But some portion of my time I'm also an agile coach to organizations, mainly in Israel. And what I learned a long time is that in the last, I don't know, five years, when I'm moving between organization, I see most of them, they know how to handle sprints, okay, they use small stories, small deliverables, uh, they use story points, whether it's the uh, real, uh, story points or it's the day count. But eventually they know how to deliver within the sprint boundaries. Now when they go to the roadmap management it seems like they forget about Agile and they go back to like traditional project management and GANs. Because what they know mainly is Scrum. And when I talk about Agile they really talk about Scrum. And most of them I think, well, maybe all of them, they never heard about the big, um, scale up Agile frameworks. I mean save the Nexus, Scrum at scale, and so on and so forth. So some of them know PI planning, okay, everyone knows this buzzword, PI planning, but they don't really know the details on how to manage projects and roadmaps in the Agile domain. And I feel that organization that delivers, um, must have a good grip of the roadmap management because you can be perfect on the Sprint level, um, and still miss the roadmap. Well, you deliver a lot but you don't deliver what is needed. You don't know if you're on track or off track. The simplest question I ask them, can you tell me on your current roadmap whether you're on track or off track? They can't answer that. They start saying well we ask those 10 product managers, they say some subjective answers. Then we go to the team leaders and they give their technical perspective. And then you use intuition and then you say I, uh, probably on track but I'm not sure. And um, it's like the waterfall devs. We are on track. On track, on track, on track, it lasts. Sprint, everybody knows that we are off track and, and, and, and we have tools to handle that and we are not using them. And I'm really trying to be very practical in my approach because most organizations use Jira, okay. It dominates the market. I don't know, uh, 60, 70% of the market using Jira. So I'm really trying to get them to use the tool. In a way it will provide them an answer whether they're on track or off track in order to handle their day to day roadmaps. So it's like no, they've big, too big. Uh, actually they have two big problems. One is planning. They don't know how to plan based on velocity. In sprints they know what velocity is, they know how to plan. When they come to roadmaps they don't know how to plan. And then suppose their plan is solid, they know they don't know how to track it, they don't know how to summarize everything that happens in the sprint. In their older teams, accumulate that into a single dashboard or a single indication whether they're on track or off track.

Speaker B: Okay, but that's, you know, it's a bit trickier, right, because we use agile and complex problems which are unpredictable, fast pace of change, etc. So the traditional techniques of road mapping, we're uh, standing on the general uh, acknowledgement that we know what needs to be done. But that's not true anymore. We don't know what needs to be done. We know what we want to achieve. We can set a, uh, clear business oriented metrics, achieve this, this and that, but you can measure them even if we decide so. But uh, we don't know what needs to be done. So creating all that stuff in our so called backlog as a to do list is like outdated. So how would you recommend people to do planning in an agile world.

Speaker C: So that's a great point because you know, sometimes I see organization, they are failing in the roadmaps. And then um, the conclusion is let's plan harder, let's plan longer. And this is exactly what happened in the waterfall days. When organizations were failing projects, they invested more in planning which resulted more failures because they wasted time. Extensive planning doesn't help you to reveal unknown unknowns, only iterations help you that. So what I tell them, you know, you need to do a good enough planning. Um, you know, if you planning the big rocks, if I'm talking about Jira epics, you know, try and measure them. And again when you try to measure them, don't run away from your traditional measurement metrics. I mean if you in sprint you're using story points, people know how to measure in story points. Don't ask him for when they measure an epic. Don't all of a sudden ask them measure in weeks measuring weeks of a person, measuring weeks of a team. They don't know how to measure that because their day to day is measuring in story points. So tell them measure your epics in story points because at the end of the day it's mathematics. You need to take the entire planning, compare that to the velocity. That's it. It's simple. Because when organization are starting to measure in uh, men weeks, they fall back to not using velocity. They are starting using this capacity planning. I have 10 people for uh four months. They multiply. That takes 80% buffer. Why? Because it's Pareto. We're probably right. If it's not enough, I'll take another sprint for a buffer. Then again this magic formula that doesn't work instead of just looking at the velocity and saying well this is what I can do. So if you want to use your sprint based velocity, you must measure in the way you measure things in the sprint. So the first pitfall I see that they are not measuring epics in story points or days. Whatever they do in the sprint, they move m to a completely different measuring system and then they lose the ability to use their velocity. This is one thing, um, the other thing that they're not really using their history. If you're tackling an EPIC and you need to give rough estimation, do some relative sizing. Look on epics that are similar in the past, learn from what you've done in the past in order to measure what we have now. It's very quick and easy to do that. Um, then you need to track it because as you said it's, it changes all the time. And I always tell them, you know, the fact that you estimated an EPIC in I don't know, 50 story points and you got to a point where it's 70 story points, it's not a bad thing. It depends. Maybe, maybe it's a bad because you added stuff that are not your mvp, but maybe you learned about the EPIC and you found very important stuff that you need to do. And it's good that you found them and put them into the epic. But you need to be aware that you are over budget from the EPIC and it comes on expense of something else. And the sooner you will know that you're over budgeting your big rocks, the better maneuvering you have in your roadmap management. You don't know that at the end. You can know that in the second sprint in the roadmap whether you are on track or off track. And you need to manage that on a sprint to sprint level. And I think the fact that the planning is not using the same measurements and then you don't really track whether your big rocks are on track or off track and accumulate that it's disabled you from really doing proper project management here. And everything is subjective instead of being objective. Now when I say objective is like it's the mathematics. You have your velocity, you have your content. Just compare them all the time. Now I don't say, don't ask people whether you think we are on track or off track. Do that. But first be objective, use the numbers and then add on top of that the subjective, you know, thoughts of the people, not the other way around.

Speaker B: Okay, so relative sizing makes sense, right? Time to time it will give you the sense. But the more unpredictable it is, the less likely you're going to use any estimate at all in agile space, right? We start shifting from estimates like 10 years ago now. But uh, still I would like to have a bigger picture. Roadmaping. So you said people are not doing it. So uh, how you want to do it in this highly unpracticed, unpredictable market when you don't know what needs to be done, you know that. I give you example. You want to improve people finance decisions. You can measure it by savings, uh, investments, executions, debts. Right, things like that. But imagine we have a nonprofit organization which want to help people to make better finance decisions. You have smart people there, they brainstorm millions of ideas. So how would you roadmap such an unpredictable environment? Any tips for us?

Speaker C: Well, that's a good question. I mean, you know, most of the organization I work with them are profit ones. I guess this is the majority. And still I think you know when, when you handle your big epics in the roadmap and suppose you're doing it pretty well, when you ship it out, you just move on. You don't take the moment to reflect and see whether you the assumption that the EPIC will do on the market or on the people or whatever you expect it to really happened. And suppose you take the moment to reflect on that. When you do that at ah, the end of the roadmap it's too late because sometimes we are talking about technology organizations and if the product manager will come to me as a VP of R& D and at the end of the roadmap will say we like this EPIC on this financial market that I want you to tell me if it succeeded or not. And at that point I would tell him I can't do that now. I don't have the right analytics, I don't know what you want to measure. I need to put those infrastructure as part of the EPIC development. It's starting with the end in mind. Those epics that you want to understand whether they are success or not, there is engineering work to be done underneath to make it happen. In most cases they just move on. In other cases they ask you at the end and it's too late. So I think you know, um, once the organization get a grip of really releasing the big rocks to the market, they need to think about it at the planning. You know, it's, it's not about what I do, but how I make sure that what I did really make a difference. Because I think you know, we're trying to be better and better in delivery but, but that's not the game. I mean, you know, you can work harder, be more efficient but if, no, but if that was the only metric for success, many organizations would be successful. The thing is that you know, people work hard, work efficient, but they are not hitting the target. You know that that's the problem. It's not about you know, delivering more and faster. It's good but you know, you need to be in the right direction. And I think most of us, we were missing that part. And I think you know, objectively sometimes it's difficult, you know, if I tell organization I'm trying to do that, you know, put um, so when suppose I'm talking about a profit organization put dollars amount on the epic that just went out, it's really difficult to do that. It's really objectively, it's really difficult to do that. And I think, you know, I think this is the big challenge. But, but, but again it's not like uh, one or zero. We can do our best. We can get some indications. So maybe you can put like it provided me, I don't know, $1,000 this quarter, but maybe I can know. It gave me like 10% more clicks on whatever. So we need to do whatever we can instead of just giving up from the start.

Speaker B: All right, now if you look back into your journey. So what was your biggest aha moment on your Agile journey?

Speaker C: Wow. Um, I think I started my journey, no, 10 years ago, maybe more, where I suddenly know about Scrum. Somebody told me about that and it was like in traditional project management. And I told him, yeah, yeah, I get it. I read this Scrum guide. I know it, I know it, leave me alone, I'll do that. And I think I did every single pitfall I could do. And then I started to really read it and reread it and re understand it by, by experimenting. And I think in the big aha moment was that I was, I had a case where I tried to build a project. You know, I'd like, I don't know, uh, 25 people doing some long term project. We worked for six months, we just go the infrastructure build and then they start a project. Now three years later they requested us to do similar project and add different people, different skill set. And this time I did it the agile way because I knew how to work in Scrum and so on and so forth. And after six months I had a working product in my hands and it amazed me. You know, like three years ago I had like, after six months I had like nothing, just infrastructure. And I, my prediction was like one half year, um, for development. And when I did it on the Agile way, it took me six months to get a working product. Now when I looked back and I said, well it's, it's not smarter people, they didn't work harder. I even have less people. And I think the magic was, is maximizing the work not being done because we learned on the way what we don't need to do and we focused on what else we should do. And I think this is the magic. When people ask me, you know, how agile really make it happen, um, in the same time I think it's about, you know, the focus, you understand what you're not being done. And this was my big aha moment when I sold out on a scale of like, you know, after six months I have working product instead of like a plan of Two years with nothing in my hands.

Speaker B: Wow. Good stories. Good stories. So, uh, that leads me to our last question. So, uh, in September 1516 in Prague, there is this wonderful Agile Prague conference where you're going to be speaking. Can you tell us like one or two reasons why people should attend your talk?

Speaker C: Yeah, first of all, I'm very excited about this conference. I'm going to be there with the great Danko. Um, I think what I will talk about, I think um, I find many people interested in is that um, we know how to measure in sprints and we know how to work with velocity, but sometimes it's not about uh, how we measure, it's about what we measure. Because if I measure, you know, when I go to my product and I say this is my velocity, you know, I need to understand that it's purely delivery to product. If I counter like bugs and technical debt and whatever, it's not, you know, I'm, I'm. It's a pitfall. Like it's not the real number I give. I need to really know what I measure. I don't need to measure anything. I don't measure coffee breaks. Right, that's the obvious. But do I measure designs meeting, you know, then I do I measure like you know, regular delivery work of, I don't know, regression testing, does it matter? So I'm really trying to focus organizations and know besides of how to measure whether it's days or story points for me it's less important. Look on what you measure. When you tell product, this is my velocity, it should be the real velocity for product. When you plan your tech debt, know what your velocity for tech depth and this helps you really set the right expectation in the organization both on the sprint level and of course it's accumulated to the roadmap level.

Speaker B: Well, thank you very much for a conversation and looking forward to see you in September.

Speaker C: Looking forward. Thank you Susie.

Speaker A: Thanks for listening to this episode of the Agile Way podcast hosted by Suzy Shopana, author of the Great Scrum Master Book and Agile Leader Book. If you love listening to this podcast, please leave us a review. If there is any topic you are particularly interested in and would like to hear another episode on it, let me know. For more information about me and my agile classes, Visit our website Sohova.com S O uh C H-O V A.com thank you for listening.