Stay agile out there

Good time of the day, everyone, wherever you join us from. Today Angelica and myself are going to be talking about a topic that is very close to Angelica’s heart, and I am very excited to finally learn and kind of clarify everything that has to do with Agile. We are being joined by Inbal Cohen, who is also based in Berlin, just like myself. Hi, Inbal.

Hello.

How are you doing?

Very well. Thank you very much for having me today. I’m excited.

It’s our pleasure. We’re excited to have you. Inbal, could you tell us a little bit about yourself?

So hello, I’m Inbal. I’ve been working in the field of product management for the past about ten years. I’ve had all sorts of different types of positions, mostly in startup companies in mobility, and fintech, and gaming. I’ve been CPO, CTO, director of product, and at the moment, I work at a company called Amazon, which you might have heard of, as a Technical Senior Product Manager. Maybe important to mention - everything that I talk about in this show are my personal opinions, and they don’t represent the company. What else…? I’ve been living in Berlin for nearly six years, and really loving it here.

That’s great. Thank you for a very thorough intro. It’s cool to see how many parts of the industry you have touched, both different industries, but also different roles. Definitely cool. And let’s start with a point. What is agile?

What is agile?

What is the agile methodology?

And is it a methodology?

What is the methodology?

And is it a methodology? [laughter] Maybe just to start - it’s not a cult, it’s not a religion, and although it seems that anyone that is working in Agile, or has anything to do with it would be talking about it as they’ve discovered the truth of the world - which, honestly, I do the same thing; I swear, it’s totally legit. That’s a fantastic question… And maybe a little bit more to the point - when we talk about the different types of ways that people think about agile, most of the times they’re very stuck on the thought of story points, or it has to be like lots of meetings, absolute chaos. Or I’ve heard things like you don’t have any certainty about things. And I think that maybe the best thing to do when we’re starting to talk about agile is actually strip everything down and go way back to the basics. And when I talk about the basics, that means going through the very basic principles of the manifesto. And when you read through those, you realize that Agile is actually a methodology. There are people that say that it’s not a methodology; it might be just a way of thinking, in order to create progress in an iterative and incremental way. Just progress. Is it for a team of software developers? Is it for a team of people that are working on HR? Is it for the team that’s working on marketing? That doesn’t really matter at this point.

Okay, so agile methodology is a list of steps to make incremental progress.

[05:40] It’s more like a mindset that helps you understand what are the steps that you will need to take in order to get your job done well. So here’s an example… One of the things that came a bit before agile was the whole concept of lean. So there’s this company - you’ve probably already heard this story 10,000 times, so shorten it down; there’s a company you might have heard of, Toyota… They were looking at the manufacturing lines that they had, and they decided to cut the waste, cutting down all the different types of wasteful processes that were happening, that were wasting a lot of time and energy and money for the company, and they decided to call it that methodology lean. It’s a way of thinking. How do I strip down everything that isn’t creating value for me at this moment? One step forward would be agile. So we’re taking into consideration everything that lean has taught us on reducing waste, and now we’re saying, “Okay, we don’t have waste, but what do I do with the people that I do have? There’s a goal in mind, there is something that I want to achieve. How do I get there?” It’s a very big and large project.

Let’s say it’s a project I have a very large project to accomplish; there is a piece of software that I want to develop. What do I need to do? I have 14 people. How do I arrange these people in a kind of way that they would make the most out of their time and their efforts?

And another thing to take into consideration - agile isn’t just about what to do. It’s also how to nurture the people that are part of that team; how to create motivation, how to make sure that people are working in their highest capacity, and also working together in a very, very close way. That’s one of the things that we also learned about agile; it’s all about the people.

And then how does agile relate to the practice of like Scrum, and the kind of day-to-day practices that I’m sure many of us are familiar with - retro, standup, sprint planning, grooming, etc. How do those two play together?

I love that. So Scrum - and you’ve probably also heard about Kanban; there’s Scrumban, there’s Safe, there is Less, there’s all sorts of different types of frameworks that we could take to our advantage. And I think that frameworks are absolutely cool. They’re awesome. There is a person that sat down and said, “Okay, I understood the principles of agile, but there are people that are coming and asking me, “What should I actually get done?” And there were people that sat down and said, “You know what - this is a way to get it done.” For example with Scrum, they’re saying, “You need to have a defined group of people. You need to have a list of tasks. You need to prioritize that list of tasks. You need to go through different types of ceremonies in order to arrive to a point where you’re creating increments of valuable software. How do we get that done with ceremonies that repeat on regular intervals?”

There’s all sorts of things that happen in Scrum that you would also see in other frameworks, like Kanban, for example. Still, we’re breaking down larger tasks into smaller tasks; we’re organizing, we’re prioritizing them. We’re taking them through swim lanes of development. But each and every methodology, or each and every framework, sorry, would fit differently, depending on the team that you’re working with. And what I’ve found interesting is the better you know the different types of frameworks that you have available, the smarter you are to be able to pick and choose which pieces of those frameworks are actually suitable for your team. Don’t follow frameworks blindly, because that’s not what they’re there for. They’re there to encourage you to be curious about the different types of ways that you can implement agile in your work.

Okay. And then, I think - well, this is a personal preference… I feel like you can’t talk about agile without talking about waterfall. I feel like whenever I’m talking about process, or whenever I’m talking to my team about agile practices, it’s always like, “Oh, but this is waterfall. What is the difference?” Like, there’s a lot of talk about companies who do agile, but actually do waterfall. So it’d be great if you could give a little like TL;DR, like what is waterfall, and what is the difference between waterfall and agile?

[10:03] I love that. And I think that waterfall is extremely important for understanding agile. One of the examples that I like giving about waterfall is - so I worked in automotive; I learned about it a little bit, and that’s why my example comes from automotive. So let’s think about a factory that’s, say, producing cars. If someone would come into a factory and say, “Hey, let’s produce a really cool new car”, and someone would say, “Okay, let me think. Let me first give you” - and if you know agile, you know that the perfect example, if someone asks you for a car, give them like a skateboard. And if you don’t know this example, you’ll have to read up on it, or we’ll talk about it later. But in a car factory, that doesn’t actually work that way.

When we’re trying to produce a car, what we have to go through is a process of maybe two or three years of planning, trying out all sorts of different options. And then you take about two or three years sourcing all the materials that you need in order to produce - the steel, and the rubber, and the tires, and whatever it is. And then it takes you a few years to produce a few different types of prototypes, what you would choose one from, and only then you would get to the point, maybe ten years later, where you can start mass-producing this vehicle that you chose to produce. That’s waterfall. Waterfall says, “Plan everything, work on everything, test everything, and then ship everything.” It’s a big bang. It’s all or nothing. Okay?

So it’s a waterfall because it’s like stage by stage…

Exactly. It’s step by step. Every time you finish a step, you’re done. The process isn’t planned to go back to the drawing board. You’re already ahead. The train has already moved out of the station. And in agile, we’re saying it’s not step by step. It’s like a type of loop-de-loop. And why is it always drawn as a loop-de-loop is because we’re saying, “If I as a software company will try to produce the most perfect software”, and you as a product team come up to your CEO and you say, “We have it. This is it. We know what we’re building. 10 years, and you have the most amazing software”, your CEOs will say like, “Dude, I don’t have the resources for 10 years from now. And the software that you’re going to produce is not going to be relevant in 10 years.” Right? Like, what piece of software do we even know that is still relevant… This was part of our pre-conversation. But there are very few things that last so long, right? And in the industry that we have going on right now, especially if we’re looking at apps, if we’re looking at web services, you’re expecting to get updates on a regular basis. We need to be able to iterate very, very quickly, with small increments, and produce, produce, produce, produce, and not just wait until the end.

So agile is this feedback loop. Waterfall, we say that’s step by step, not going back. How about Scrum?

So that’s agile.

So Scrum is part of agile.

Scrum is a framework of agile. And you can have different ones. You have Scrum, you have Kanban, you have Scrumban… You have all sorts of different frameworks that are doing those at scale. There’s Nexus, there’s all sorts of different types of frameworks to do iterative work. And it really depends on the type of things that you’re getting done. So just imagine, there are companies that are doing solely backend products; there’s nothing to see. Even if there is a UI, that’s not the part that we’re focusing on. You wouldn’t expect their development cycles to match an app gaming company. You’re not going to expect the same level of interest, let’s say, coming up from the different updates, and you would also not expect them to be so regular.

[14:08] The amount of complexity might be different, the different types of languages that are being used are different, there might be the differences of the sizes of the teams… So according to all of these different parameters, a person that is in product, probably leadership in product, would need to decide on the right framework or the combination of frameworks that might be working for that team, and then on a deeper level, the product manager themselves of that team need to be able to have the feedback loops with their team, “Does this fit us? Does it not?”

So is it like pick your own adventure? I feel going in you have all these frameworks, all these many different ways of doing things, and it really is kind of pick and choose as and when relevant. It may well be the same team has one project they do very strict agile, but then the next is waterfall… It really is kind of as and when applicable, whatever is the best way to get your end result in the most efficient, effective manner. Am I right? You don’t really have to choose, it’s kind of the benefit here is there’s all these wonderful frameworks, learn about all of them, and then see which one fits your team and your needs best.

Absolutely. And doing it differently – in my personal opinion, doing it differently would actually be missing out. If you’re just trying to copy whatever a guidebook is giving you… You know, you just bought a book, or you went through one training, and you’re like, “This is it. This is the only way of doing things”, you’re really limiting yourself, because agile is a way of thinking, and it’s not so limited.

So being able to open yourself up and know more about all the different frameworks, and being able to do that, as you’re saying, go on your own adventure - that’s part of the fun, isn’t it? Like, getting to know your team, getting to know what works for you, trying different things out… Super-important.

Okay, so as a developer, I’ll ask you, what tips do you have for me to make the most of agile?

That’s fantastic. First of all, I would say educate yourself. One of the things that a lot of times we do is that we depend on other people within our team to be the experts in whatever their subject matter expertise is… Which is fantastic. That’s their job; they should be the expert. But having some type of basic knowledge about the things that you should expect different people of different professions is extremely important. The more educated you are on the types of expectations that you can have from your product manager, from your product owner, from your Scrum master, whatever type of a title that you have going on in your team - that’s the first, most important step.

The second thing is to really have in mind, agile isn’t about output. It’s not only about what you’re delivering. It’s about the process that happens in between. It’s about creating high-performance teams. And let’s say the aim, the goal of the person that is managing the team in an agile way - which is most probably, again, a product leader - should be to have a high-performance team. And they need to be able - and you could help them that way, to tell them and to express how to make you more effective at your job. Are you feeling comfortable? Do you feel that you’re stressed? Do you feel that the work environment that you have - does it suit you or not? Do you understand the purpose of what you’re doing? Understanding purpose is a major role in agile. You have to have a team that knows “Why are we doing what we’re doing?”

[17:56] And I’m going to quote someone that, again, I hope I’m not too much of a cliché, but Martin Kagan wrote a book, it’s called Inspired; it’s pretty much – can I say that it’s the Bible of PMs? Like, not to have any religious affinities, but it’s a book that PMs very much look to, to get obviously inspired. And one of the things that he says there is that if you’re using your developers only to develop code, you’re only using half of their skills. And that’s something that’s really important for you as a developer to know. If you’re sitting in a team and all you’re doing is coding, they’re not getting the most out of you. You should be a person that needs to be advised. You need to know the big picture; you should know the vision of the company, the vision of the product that you’re working on, and you should be able to pitch in and also give advice on new features or new things that are coming up, to be able to say what are the trade-offs, what can be done differently; is there one thing that should happen before the other? You should also be able to say, “I think that’s a bad idea.” So these might be good initial steps.

So as a developer, you say if I only kind of execute, what some people might refer to as a code monkey, you’re only basically using half of the resources of this team of developers. And then you should be able to chime in and provide the feedback. And what stage would that make sense? So it can be very early on, when you’ve just planned the features, and prioritized and so on, but then, on the one hand, you lose the speed, let’s say, if you’re going to be asking all your developers. But if it actually comes down to “Here’s the stage where I am as a product manager giving this to the developers”, and then we might have to shelf back some ideas that were already panned out, and so on. So… When?

Well, it really depends on your style. As a product, I think it also really depends on the level of confidence the product manager or owner has in themselves and in the team. I would strongly recommend, just put aside ego, put aside any mistrust, anything that happened in the past, in your career, or with the team, come clean to the table, and understand, for any profession within development - and probably this also applies for other professions in general - if you’re able to come and have an open and honest conversation with the professionals around you, and each and every person around the table sits there and says, “I’m just going to have an open, honest conversation about what’s going on right now”, the effectiveness rate of that team would increase at least twice as much. And it’s hard for me to give numbers on it. It’s just – it creates a special type of magic.

And then specifically for your question, take these opportunities to understand that it’s not just chiming in. You are part of the thought process. I would expect, as a product manager – for myself, I have a rule. I mention anything that I want to have developed four times before it gets developed. One time - and now we’re talking a little bit about the different ceremonies, but these are ceremonies that I like having anyway; so one time, I’ll just mention it in a stand up. “Hey, I had a meeting with someone about this thing. It might be interesting.” Once, right? A second time might be bringing it up for like a grooming, or at the retrospective, or somewhere in one of the different ceremonies that I have with the team. “Hey, remember that thing I talked about? It’s actually proven to have really good numbers.” Or “This is proving to have a really strong business case. I’m going to move ahead and start writing a story about it, or a ticket about it”, whatever kind of method you have. Is there anyone around the table that would be interested in working on this with me?

[21:58] And then a third time would probably already be in a grooming or a refining session. I already have my ticket; this is me sitting down with the team, already opening it up, breaking it down into smaller pieces… And then maybe a fourth time, if we have an extra estimation meeting, if we have an extra meeting for putting things into our product backlog.

So by the time you as a developer, when you saw that ticket, you’re like, “I already know what this is about. I know who to approach. I know who was interested in it. I know which people were involved in the conversations. I know how important this is. I know that my PM did her homework. I’m in, I’m involved.” So right at the beginning, I guess.

So would it be a fair assumption to say that one of the tangential benefits of working in agile style as opposed to others, like waterfall, is that there is more space for input? And as you say, we keep on saying “Iterative approach. Iteration.” Is kind of a side note benefit that developers have more of an opportunity, because we’re working on this, whether it’s a two-week sprint or whatever cadence cycle, where you’re regularly being asked, “Are we working on the right thing? Do you understand?” Is there input? Is there more important, is there tech debt that we need to address? Is it a right assumption to say agile is also great because there is more developer input, as opposed to, “Hey, Product Manager coming in, we’re gonna work on this thing for six months. Go do the work.”

Absolutely. And it’s not just the developer, it’s the entire team. Because just imagine - in waterfall, we have people that are sitting in these very, very tight compartments, that have to do with the steps of development that they’re in. So there is a planner, he’s sitting alone in a room with a group of planners, and the developers are sitting in a group of developers, and the testers are sitting with a group of testers… And there’s very minimal friction, because there’s only handovers.

And then agile, by doing things in an iterative way - that’s one thing - and two, by taking advantage of cross-platform teams, having everybody sit together through, which again, I think is an extremely important point… The table is flat when we’re looking at a team; the table is flat. No one has the higher chair. Developers are sitting the same with the project manager, with the product manager, with the designer, with the tester, with the backend, the frontend… Everybody. Everybody’s sitting together around the same table. It’s absolutely flat. Everybody gets to chime in. And not only do they get to chime in, they get to chime in every week, or two weeks, or three weeks, or worst case, once a month, which is pretty much the slowest cycle, right? Slowest sprint that I’ve heard of… But at least once a month. And it’s not like you disappear in the background. As a product manager, I would expect you to be present, and I would expect you to pitch in and give your opinion. So absolutely yes.

When we’re thinking about like the day-to-day practices of agile, working in a team, pushing projects forward, I’d love to hear a little bit of how you’ve seen the culture change as we’ve become a more remote-first industry. How has remote working, especially during COVID, and now with kind of – I think people going into the office every day is going to be very much the exception, and remote is going to be the rule… How does that impact agile practices, and what have you seen in terms of how it’s changed agile culture?

It changed a lot. It shook me, absolutely… Because one of the things that I really insisted on is seeing people face to face. Even when I had remote teams in different countries. So one, I always had an office for my remote team. They would sit together in the same room. And the second thing was, I would visit them on regular intervals.

I think the teams that I visited the least was four times a year; once in a quarter, I would go and sit in those offices for a week or two weeks together with the team.

For my teams that are local, next to me, for example in Berlin, we would sit in one room, and I would be the person with the smallest room for my team, because I wanted everybody to sit close together as well, and not just in a big, open space. Because there’s a very special moment, especially as a product person - you’re sitting down, you’re typing something, you have a thought, you just lift your head and you can say, “Hey, what do you think about this?” And you get that instant reaction. You get an instant reply. That’s priceless.

And now, when remote, all of that is as if gone. I’ve tried to weirdest things. I can talk about it now… I had sessions, I had days with my teams, camera open, everybody’s just sitting at home - and this is way before we had like a proper setup; this is like super-uncomfortable… Just to try to create this type of environment.

So what I would say, biggest change - people that are in charge of the agile within the team, whoever they are, really have to step up their game with everything that has to do with social interactions between the different team members. You have to be present, you need to find a way to actively communicate with everybody, on a daily basis. And a teeny tiny advice that I can give - if you’re doing agile, any type, if you’re having stand ups, and even if you’re not doing agile, make sure that everybody turns on their camera for stand up. Have that 10-15 minutes in a day where you know for sure that everybody saw everybody else’s faces. It kind of connects you for a moment.

And then a second thing that I would give a piece of advice would be have an extra meeting that doesn’t have to be part of your agile framework, whatever it is that you’re doing. Maybe it’s a coffee hour, maybe it’s an afternoon drinks. Something. Give your team the opportunity to show up as they would want to, without having to be there. So it’s not a mandatory time. It’s not part of official work. It’s just something that we can do just to have a chat, and gossip. Everybody likes to gossip. [laughter]

[30:17] And then what would be your advice for reaching high-performance from the office? Not remotes. Or advices.

I was so tempted to say, “Have plenty of coffee breaks”, but that’s not very inspirational…

It will make you code faster.

For sure. And that is the most important thing about developers, as you know - how fast do you code.

You convert the coffee into tests.

[laughs] Exactly. I think in the workspace – there’s a whole thing, you can read about it. There’s even a book, The Five Dysfunctions of a Team. One of the most common things that I see in teams - and that’s the one thing that breaks teams, and that’s the one thing to work on first… If there’s one thing, if you join a team and there’s one thing that you would be able to get done, is check the pulse on trust. And being able to nurture and create trust between human beings is a lot easier in-person.

So I’d say even if you’re working in a remote or a hybrid setting, when you come to the office, don’t come to the office when no one’s there. Especially if you’re making a special effort. Maybe if it’s only once a month or once a week, try to make sure that there are other people there, one. Two, don’t set up any meetings; have it as a day that you’re trying to connect with people around you, trying to get to know them better, try to make them get to know you better… Because what happens is that one of the things that a lot of times in development - efficiency, being effective, and everything that has to do with that… People, again, forget we are human beings. And at the end of the day, when you have a person that you’ve managed to connect on on a personal level - it doesn’t have to be too deep, right? We can just have a coffee together, and talk about where you came from, or what’s your favorite food. But having that very basic human connection would increase the chances of you being able to trust that person in the workplace, and then be able to have fun. Ah, did I say fun? But yes, you would be able to have fun together, working, and be able to trust them. And high-performance teams have fun. They’re not just like work-work-work…

Yeah, it’s true, it is a harder thing to do these days, in this post-pandemic setup that many companies are, indeed, like you say, hybrid. And there’s an office, you can show up, you can not show up, or maybe some companies have some days in the week where you can come, or maybe it’s just like a hot chair, and you can come whenever it’s available. So you say coordinating with your teammates would be a good thing to do. I guess it’s especially nice if you’re new in the team, or if your team kind of got a refreshment over the last few years, to get to know each other again.

And so would you recommend kind of getting to know and making friends mostly with your teammates, or just with random people you meet in the office and you’re not sure who they are or what they do? How to go about that, other than making everybody put their picture on Slack and saying “I’m gonna find you”?

Well, I can tell you that it’s a very difficult question for me to answer. And the reason is that I’m thinking about the people that are listening to this podcast, right? I am pretty high in any test that I took on the scale of being an extrovert. My friends have this joke that I can’t even go to the supermarket without finding a new friend. So if you asked me, honestly, for me, I make friends with everybody. I have a coffee – I would go to other floors. I just joined recently the job that I have right now. I go on other floors to make coffee, just to kind of see who’s there and like spark some type of conversation to see who I can talk with.

[34:13] That is interesting. Visiting at their coffee machines. That is a strategy.

You know that you find out that not all floors were made the same…?

[laughs] So do the coffee machines get better as you go higher up?

That’s a tricky question. I actually found that the one that is on the ground floor is the fanciest one. But more of the point is - with your team, super-important. Go together on lunch; have a lunch date. That’s something that’s relatively easy for you to organize. But then meeting people from other teams also gives you a bit of a refresher, because you might be meeting people that are, first of all, obviously on a different team, so they don’t know what you’re working on exactly, and it doesn’t really matter… And then just imagine you might meet someone that has a completely different profession than you; they don’t even know what you do. They don’t know what Go is, and it doesn’t matter. You can connect with another person on a personal level. And just imagine that you would be able to go on breaks, at work, not talking about work, the entire break. And that’s very refreshing. I think that it’s a fun feeling, just being able to have something that is completely out of it to be able to really disconnect.

Mm-hm. I guess that’s why some people at work join interest groups. Like, we are people who like Asian food on Tuesdays, or sports clubs, or whatnot. Yeah, that makes sense.

So I’m gonna jump in and ask a question that’s been on my mind, that has not to do with this, it has to do with agile again. But I think we’ve talked a lot about like the benefits of agile, but I’d love to hear a little bit about the cons. Like, why is agile not always the best choice? When is agile not right? What are the pain points around the fact that agile - and this is a bit of a leading question, giving away my opinion… Agile sometimes as a product manager, when there’s like – you have loose deadlines, things change on like a sprint-to-sprint basis; if you have tight deadlines, it can be a bit more difficult to stick to them, and therefore sometimes - putting my hand up - you kind of fall into waterfall to meet the deadline. So I’d love to hear a little bit about where agile kind of might be difficult, may introduce cons, may not be the right fit, may need to be adjusted to not be strict agile practice.

I love that. And I love also the way that you lead into that question, because it points back full-circle to the beginning of our conversation… And the reason being is, if you strip all the frameworks away, strip it all off, go back to your principles, go back to the values, then you will see that if you try to stand just by the – we are working together as a team. Are we doing that? Yes. Does everybody understand what we’re doing? Yes. Does everybody understand the importance of it? Yes. Are we boxing a period of time which we can try, to the best of our availability, to provide an increment of value at the end? Not just doing something for doing it. Are we trying to achieve an increment of value within a time box? Yes.

So you’re doing agile, right? You’re doing the very basics of it. You might not be following your framework perfectly. Okay, you broke your sprints, you did whatever; you did a little bit of waterfall in the middle; you’re actually a Scrum person and you did a bit of Kanban - okay, but there is no agile police. It’s not about making anyone happy except yourself with your team.

[37:59] So I think that the biggest disadvantages of agile is pretty – and this is too, again, culty, but it’s more about the misrepresentation of agile; it’s more about the things that we put on top of an agile thinking. Just have an agile thinking. If you start from that and you’re doing that, you’re already good. And being flexible. We’re thinking about these iterations, we’re thinking about the frameworks, but agility - it’s being flexible, it’s moving, it’s being able to change according to the things that are happening around me. And this if that’s something that you feel a need to do, I would trust you as a professional saying “This is this is it. This is the pivot that we need.”

And who in your opinion is the driver of the methodologies, the frameworks that a team should use? This is just my personal question and something I’ve been kind of thinking through… Like, a lot of teams have project managers, product managers, engineering managers… Who is the driver of the practices? Is it truly collaborative as always it should be, or is it that like it is really part of the project discipline to establish what is the right framework? I’m just interested in your personal view; there’s no right answer, I’m sure, but it’s something I’ve kind of been thinking through. Like, can an engineer be like, “Hey, Angelica, this agile thing is just not working. We need to try this other thing”?

Absolutely. And one of the things that we have – we can call people that way; I have been called that way for a while… It’s called an agile evangelist. Going back to like, religious, “This is not a cult.” What is it being an agile evangelist, and why do I think that each and every person that is working with agile should be an evangelist? I think that one of the principles or the things that guide me when I mention this is I am here to provide you, as a team or as a company, with information on how we can get things done in an effective way, where everybody’s super-happy. Okay? This is what I do. That’s my profession. I’m going to tell you the different types of things that you can get done. You can choose if you want to drink the Kool Aid, if you want to participate or not.

As a team, as each and every developer sitting in that team, you need to be able to say “I accept this, I understand it. And actually, this is helping my work. And I’m going to stick to it. I want to make sure that everybody sticks to it.” And I think it’s a lot like – if you’ve ever been in a good meeting, with really active participants, you would notice that there is a person that’s leading the conversation, but you would always have the additional people in the conversation being able to say, “Oh, sorry, off-topic…” Or, “Hm, let’s take it offline.” Not only the moderator would be the one driving the conversation; all the people around the table would be actively participating. Because they’re a part of it; they get the point. They want to arrive to a conclusion in this meeting. And working with agile is exactly the same.

So you as the product leader can provide the information to the audience, to the team, to the company, but it’s each and every person’s role to be a small evangelist of themselves. Each and every person within that team needs to be able to say “That sounds waterfallish.” Or “What about the deadline?” “I don’t understand that increment of value.” Or “Hey, what happened to our retrospective? I really need to pour my heart out.”

Each and every person within the team should be accountable, where we have a shared responsibility and accountability, and an individual one. And in that shared one, we’re all maintaining that agile atmosphere thinking, because it benefits us, and we want to.

[42:03] So is there a world in which we would maybe have almost like a agile interview stage? Like, it feels to me, as we talk more, that everyone on the team, regardless of discipline, engineer, designer, product, project, should know - not in great detail; they don’t have to read every single documentation or every book, but the basics of what agile is, what waterfall is etc. Is there a world in which perhaps it would bode well to have like almost like a project methodology interview stage, where people just talk through the kind of working styles… Have you done waterfall before? Have you done agile? Both to make sure that everyone has that information, i.e. like if you were going into an interview and you saw you had an interview about agile, you’d probably do a quick YouTube video on it. But also if there is an overarching, like certain companies tend to err on the waterfall, versus the agile; it almost feels like it could be like a culture fit. Just spitballing here… What are your thoughts?

Yes. And I actually do that.

Oh, awesome. Tell us more.

I love it that you’re mentioning that. There was one piece of an interview - and this is me giving away a bit of my secrets, but there’s one piece of an interview that I do for any person that I interview, for any job. It doesn’t even matter. It could be sales, it could be any job. And there’s one thing that I do, and I don’t give them prior preparation, like “Hm, we’re going to test you on agile now”, because I don’t want people to prepare in advance. I want to see your mindset. I want to get an understanding, is this something that you could put in your mind? And what I do is I have the websites - there’s a website for the principles - and I just put on the principles on the screen, and I asked them to look through them and tell me, if you had to choose one… And I give them time to read them through. If you had to choose one, the most important one, which one would you choose? And why? And then we have a conversation about it.

And it’s super-insightful. Super-insightful to see what do you choose, why did you choose that one? Where are you coming from? What’s the job, what’s the role that you’re aiming for? And then involving that into an entire conversation about how much prior knowledge they had.

That is a really interesting way of going about that. I do see in a lot of job descriptions for developers that in addition to mentioning the technology, they also mention the methodology that you’re using. So yeah, it makes sense. But I can’t say I was ever asked about that. But I guess if I don’t have to know them in advance, it will be interesting for me to kind of read through and see which one resonates with me. So I like this. If you would ask me to read them in advance and have that prepared, it probably would be a different thing… So I’m glad to hear that this is not that.

Last question for today would be, as a Go developer that is working as part of a cross-platform team, what advice, or what exactly would I be doing?

I think that that’s great. It’s a great summary. I would say, take this entire conversation, and if I had to crunch it up into a few sentences, right? So one, get to know your team. Who’s on your team? What did they do? Why are they doing that? Why do they think that it’s cool? What’s their favorite food? Right? And then a second thing is, who is the product leader on your team? What can you learn from them? A product leader on your team should be a source of information, the same like anyone else. The same like you would go in and get advice from your backend developer, from your frontend developer, from your designer, from whoever about this next thing that you might be doing - go and get advice from your product leader. Like, what are you doing? What does that actually mean? Right?

Then another thing would be think, try to have a thought with yourself, “What motivates me? What do I don’t like so much about my job right now, and what do I really enjoy?” And then try to initiate a conversation at the end of whatever cycle that you have - if it’s a sprint, if it’s a week, if it’s two weeks… Usually, what we have at the end of these cycles is a retrospective, which is a type of meeting where we can sit and have a conversation about the week that we had. That would be a fantastic opportunity to say, “Hey, I actually thought about it this week, and one of the things that bothered me are that we don’t meet as a team. That we never have lunch together. Is that something that we can arrange?” So being able to be open and honest.

And then the last one would be think about trust. Do you trust your teammates? Do they trust you? Is there something that you would be able to do to up-one the trust in your team?

That’s a great checklist, and definitely something to bookmark.

Yeah. And I would double-click just quickly, and have a comment, slash also request, which I’m going to regret saying, but I’m gonna say it anyway… Please, software engineers, ask your product manager what that incremental improvement you are providing is. Like, if we’re following agile, we should be providing value on a sprint-by-sprint basis. Also your product manager, “Why are we doing this work in this sprint? What are we providing? We’re agile. What value are you getting us to do? Why are we working on this feature versus this other one?” Continue to ask those questions, one, because it helps your product manager think in that agile fashion, but also it holds them accountable, and ultimately, to your last point, it builds trust, you as engineers knowing very clearly “Okay, my product manager has a very clear reason why this ticket has to be done today.” But also, we as product managers should be held accountable. We should be thinking through like, “Oh, I just personally want this tech debt done.” No. Why is this more important than this other feature?

So I think it’s about building that trust both ways, but also holding both the engineers and the product managers accountable to truly be agile. And if I’m like, “Oh, we have to work on this thing for six months”, I would like my engineers (this is the bit I’m gonna regret) to be like “Angelica, why are we working in waterfall? I thought we were an agile team.” Final point… [laughs]

Amen to that.

Definitely, yeah. Having a why is something I can absolutely stand behind. And I think everybody will agree with you, Angelica, that this is a popular opinion. But now it’s time for the unpopular opinions.

For anybody who’s not joining the live stream, Inbal was dancing to all the tunes like she’s heard them forever… So either you’ve been listening secretly to this podcast, or I can understand why you make friends in the supermarket. You’re are super-friendly.

Yay!

[laughs]

I love the tunes.

Thank you, thank you. Okay, so what is your unpopular opinion today, Inbal?

My unpopular opinion has to do with roadmaps. Roadmaps are a very, very dangerous tool, that a lot of times is used against development teams, instead of by development teams for the business.

Interesting…

And my unpopular opinion would be - and this is funny, because it’s an unpopular opinion in many companies that I’ve been in, but it’s actually how they’re supposed to be done… Which is roadmaps should be a combination of two directions meeting in the middle. From the top, we have the Why; the business telling us “These are the numbers that are going to make our company super-successful.” We have the middle part, which is the product saying What. What are we building. I understand the need, and now I’m going to think about this fantastic software that’s going to solve all our problems. And on the bottom, we have the How. These are the development teams - how is this going to get done?

And roadmaps are supposed to take those two edges of the Why and the How, and bring them in the middle, which also is the house of When. So when we’re trying to drop on development teams when things are done, we’re limiting how things are done. There’s all sorts of different types of metrics that we can look at that have to do with effort, and time, and what comes out in the end… But I can tell you that when we do roadmaps that start from the bottom, on how the different things can be done according to those business objectives, they are much more accurate. That’s one thing. And the second thing is development teams, regardless of who is representing them, are much more confident on giving red flags, or notifying whoever needs to know if there are any delays. Because they are accountable for the dates that they provided themselves, and not resentful of the dates that were brought upon them. That is my unpopular opinion.

I’m like that meme with all the numbers… I know you two understand each other, because you both are product, but I was lost in here… Can you say that in one line for me? I’m like that meme where you see all the math formulas… Like, I understand, it makes all sense… It does need to meet in the middle… But what is that unpopular part of the opinion?

[53:59] That roadmaps need to come from development up, and not from business down. So roadmaps aren’t something that you are given as a development team. It’s something that you build.

I agree with you. I think you have my voice. [laughs]

I want to be clear, is the proposition that software engineers work on the roadmap and bring it to product managers? I want to be very like logistical here. And are they then accountable for saying why they think that it’s the correct course of action? In the same way, if you do it the other way around, product is accountable for convincing that and evangelizing why that’s the correct roadmap for the engineers? Would it just be the opposite?

So how it would work in like in a really nice setup… Business comes in and says “We have an X amount of new clients that we have to onboard. We have a deadline. It’s a hard deadline. We have to have this by the end of 2023, or the company goes belly up.” Right? So these are the types of deadlines that we can’t argue with. And we come down to the development team; as product, we already have a What in mind, we already know what we want to build, we have an idea of what we want to get done in order to achieve that business goal… And we come to them and we say, “This is kind of what we want to build. It’s a rough idea. It’s not particular; it’s not to the tee. I have a general vague initiative that I have in mind. What of this could I get done in 12 months?” And then we would sit together and tear it apart, take down the pieces… This is quite literally the exact same thing like we’re planning a sprint; it’s exactly the same like taking a story, breaking it apart into tasks, and then putting it up and seeing what fits inside my backlog without overdoing it, or without making it too small. Exactly the same thing, just at scale, on a roadmap.

And what happens a lot of times is that companies kind of forget that it’s a sprint at scale. They forget that, and that’s one of the issues that we have a lot of times with companies that think that they’re doing agile, is that a lot of times when you have stress, any stress - it could be stress on the system, it could be stress on people, it could be a business stress… Any type of stress that comes on top of people that don’t have an agile mindset, they defer to either it’s waterfall, or micro-managing, or all sorts of different types of behaviors that are absolutely not agile, and they kind of forget that they already have a way to actually have a prediction, or have some type of understanding of what they can expect in a period of time in the future. And it doesn’t really matter if it’s two weeks or a year.

So can you even use roadmaps effectively in agile? Or is there an argument that any roadmap you create today will be different tomorrow, so what’s the point?

There is a point. And the reason that there is a point is, one, I don’t really like roadmaps; I like more the idea of goal maps. I have goals I would like to achieve. It’s not about having a specific amount of lines of code, it’s about an increment of values that I want to achieve in a certain amount of time. And there are all sorts of shortcuts that I’m willing to take along the way if things don’t work out; that’s being agile.

But on the other hand, it is very important for me to have, one, a Northern Star. Where am I aiming? What is the direction that I’m aiming my ship? And then having these milestones on the way as these buoys to make sure that I’m still on course to get to that direction that I want to arrive to. If I don’t put any of these insights, I might even not have a ship. You might find out that everybody’s in like their lifeboats, all over the place. You need to have a direction, and you need to have these milestones to guide you through. And also to be able to even say, “We didn’t hit a milestone.” That’s also okay, as long as you know where the milestone is, and where are you, you can still calculate where are you on route to give some type of prediction on what’s going to happen.

[58:16] Yeah, that makes a lot of sense. It also connects to a conversation we had a couple episodes ago about velocity. It makes a lot of sense, everything, so thank you for clarifying everything and sharing all that. I’ll use the last minute to share my unpopular opinion that I’ve been planning for the last week… It’s on the topic of food. My unpopular opinion is that you should only get nice, fresh ingredients, fancy everything, if you’re planning to be easy on the spices. It doesn’t make sense to take – I don’t want to say a nice steak, because I’m vegan, but it’s a very easy to explain example… Don’t take a piece of meat if you’re going to drench it with spices. Take tofu. It’s going to taste the same, with the same spices.

The interesting thing is that we will be asking our Twitter followers for how unpopular is this unpopular opinion, and I think, at least in the field, in this little crowd of developers, Inbal, what you say, you might end up in the wall of popular unpopular opinions, because it does make sense for developers to give that feedback. Thanks for sharing that, very much.

But the developers want to be accountable for that cognitive extra load…

This was not part of the unpopular opinion…

Do they want to? [laughs]

I can’t hear you… The connection breaks… [laughs]

Do developers want to take on that extra cognitive load? Do you want to be accountable for putting together the roadmap?

Yeah, that is a good point. I’m thinking whether this is a popular or an unpopular opinion. That’s a fair one.

I mean, it’s probably two sides of the same coin, and part of me is like, I really want to continue doing it. I really enjoy doing it. But also, another part of me is like, developers already have so much they need to do in their lives. We put so much accountability on them. I feel like this is something that almost like we as product or project can, with heavy input from them, drive the boat on.

So here’s a question for you to think about, just kind of going forward, nothing related to this specific episode… So you mentioned developers have a lot of responsibility, and a way to go about let’s say respecting this responsibility while writing code is actually writing a lot of tests to make sure the behavior is as expected. What is the test equivalent of roadmaps, sprint planning, and so on?

Oh, I love that… That was a brilliant question, that we could have a whole other episode on.

Absolutely. We will.

I should have used that as my unpopular opinion, talking about testing… [laughs]

Next time.

Well, we have many more episodes, and we hope you’ll join us again.

Thank you for having me. I had fun!

Thanks a lot for joining, and thanks everyone who listened.