“The real shift is in the mindset, and the real shift is in the trust that you entrust the people of building the software for you. So you need to really look deeply into when you're doing your change management and avoid falling into the trap of, like, just doing Agile by naming conventions and ceremonies. These are important, but they're not the end-all be-all. The mindset is the key.”

Intro:
Welcome to the Agile Digital Transformation podcast, where we explore different aspects of digital transformation and digital experience with your host, Tim Butara, content and community manager at Agiledrop. 

Tim Butara: Hello, everyone. Thanks for tuning in. I'm joined today by Elad Simon, a former Google executive and the CEO of Craft.io, a product management platform that's tailored specifically to product managers and product development teams. Our topic for today falls within this same context. We'll be talking about product management as key to agile digital transformation, and we'll take a look at the key differences between agile and waterfall first before going more practical with Elad sharing his own first hand experiences and tips. So welcome, Elad. It's really great having you here today. And let me start off with the most basic question. Why is product management so important to digital transformation? 

Elad Simon: All right. First of all, hi, Tim, and thanks for having me on your show today. I appreciate the time and I appreciate you. And so let me just kind of dive in directly into product management and digital transformation. Digital transformation is a very big thing, right? It's almost like an abused topic in a way, in a lot of large companies. And it encompasses everything from changing, moving from servers in your server room into the cloud and from moving into agile into– like, it’s a huge topic. 

However, at its essence, that's kind of how I think product management kind of links into it, in my mind, it's about shifting the mindset of the enterprise or the company that is going through digital transformation to a more digital mindset. And that concept connects extremely well with the notions of agile and with the notions of product management. And I think we'll deep dive into those two topics later. But the reality is that in my mind, product management is at the essence of this transition into agile, and it's the essence of the transition into how, like, modern companies like Google and Netflix and Microsoft and the likes are building software for a living right now. 

And that shift is connected, how do you say, in the hip between the concepts of agile and the concept of product management. Because the concepts of agile, in essence, are– we'll talk about more later. But in its essence, the concept of agile is really about transforming the way you think about building software, slicing it into smaller pieces, understanding the customer needs, and reiterating and rethinking through your solution all over and over again, which is hand in hand combined with product management. 

And the interesting thing we're seeing right now, by the way, is that companies that are going through this digital transformation, they put product management at the heart of this transformation when it comes to how they build software. So we see more and more companies shifting into this world of product management and understanding that it's a core capability that they're missing in the organization in order to become digitally transformed. So to kind of sum it up to your question, digital transformation and product management are really deeply intertwined when it comes to how you build software, because how you build software in the modern way is agile and with the product manager leading that software building. 

Tim Butara: Yeah. Because software is basically your product is the software if you're a software company. So in this sense, if you take an agile approach to software development, it's inevitable that you'll have to incorporate product management in some way. And it's a great starting point because my first experience with agile was actually when I was working in product development and then as a product manager. So, yeah, I can totally agree with that. I'm totally on the same page. 

Elad Simon: Just to your point, by the way, you mentioned– for software companies, I think this is like stating the obvious. The interesting part is that when you look at digital transformation, in many cases this is associated with non-software companies. Right. So you think like the large FTSE 100, large enterprises. But the reality is, and this is how we see the world at Craft, and I think that's how a lot of people see the world nowadays. The word software is basically everywhere. There is no enterprise that is going to escape the need for building software. It doesn't exist anymore. 

It might not be a consumer facing software, but it might be software for their logistics, supply chain, sales, marketing activities. It doesn't matter. Enterprises need to know how to build software well these days, even if they're not software companies. We have a lot of customers in Craft that are non-software companies, but they're also building software and they're going through digital transformation. So this concept is not limited just to the people who are building software for a living. 

Tim Butara: Yeah. Especially now we're seeing more and more of that as digitalization, as innovation progresses. But yeah, we'll talk more about your experiences, more about your first-hand experiences with previous clients in a little bit. Let's first take a step back and let me ask you, what are the differences between waterfall and agile, mostly in software development? 

Elad Simon: Yeah, I guess if you kind of break it down, waterfall and agile are kind of like, they’re always perceived to be the opposites of how you build software. And in reality, they kind of are. Eventually, and by the way, these are very interlinked with the concept of project management and product management in general. I think that differentiation is very similar in concept. 

Basically, when you think about waterfall software development, it is a very much of a predefined scope, predefined project notion and a predefined timeline notion. Everything is kind of predefined. And let's say the variable, the thing you play with, is the budget. How much money do you want to spend? But eventually you have to predefine everything. 

And then waterfall is like, once you predefined everything and you sit down with all the stakeholders and agree on everything in advance and write all the specification, then it just becomes this very massive execution project of a predefined plan. I'm obviously ridiculously oversimplifying the concept of a waterfall, but as a basic concept, that's how it looks like, right? 

So basically, you and I, you're my customer or you're my business counterpart in a big company, you will sit down and say, hey, I need this platform to do this. I'm in a bank and I need a brokerage platform to do this for me. And I will sit down and say, okay, I'm going to write all the things you need in this platform and then you're going to give me money and I'll give you a time estimate based on that amount of money and then I will deliver to you. And then at the end of the day I'll say, okay, congratulations, Tim. Here's your software and good luck with it and see you later. The team dissolves and we move on to the next thing. That's how a classic waterfall project looks like. 

And again, there's a lot more to it. But an agile project– product basically looks very different in concept. Basically what you define, the only thing that is permanent, is the team. You say, like I have here a team of X people, X could be ten, it could be 50, it could be 1000. And I trust them with building the right solutions for my customers. I don't know what they're going to build and this is a very scary thing for enterprise. This is one of the reasons why enterprise are really afraid of the shift from waterfall to agile. 

Eventually, people always like certainty and scope is great in terms of certainty. It just ends up with bad software. That's the only problem with it, right? But with agile, you don't know what the scope is going to be. You just say, hey, I'm going to invest ten people here, product manager, a UX designer, and then a couple of developers and QA people, and they'll build whatever is right. And they'll iterate very quickly on what's right. 

And they'll have sprints and they may have releases and they may have quarters and they'll do planning and they'll check and recheck and continuously check whether what they're building is right or not right for their end users. And then iterate and shift along the way and you really don't know what you're going to get because it's going to change. And you also really don't know when you're going to get it. Actually, there is no concept of, when am I going to get it because there is never I'm going to get it. The concept of waterfall is like, I give you an end deliverable and that's it. Now you have it. I gave you an end product. 

But if you ask Eric Yuan, which is the CEO of Zoom, which is a platform that we're using right now to talk to each other, it's not like they've finished building Zoom, right? They're continuously building Zoom. It's never ending. It's just that they keep adding stuff and shifting things and moving things around. And that's the main shift in waterfall to agile. There's no end deliverable. It's a live product in essence, and then continuously iterates. 

And of course, sometimes products mature and sometimes products even die right. From time to time, people kill products, and that's okay as well. But in essence, when you start a new product in agile, it doesn't have an end date and it doesn't have a delivery date to it. You might have a delivery date for an MVP. You might say, hey, I'm going to give you something by roughly this. If you're like a strict agile practitioner, you may never commit to any dates. You have these, like very, how do you say, zealous– kanban, I never commit kind of people in agile, but usually you kind of have a ballpark, okay, by this time, I'm going to give you something. 

So that's kind of like the difference between waterfall and agile. And by the way, I'm not proposing that this is horrible and this is good or anything along those lines. Right. So, I mean, you have cases where waterfall makes perfect sense. They are diminishing in the world. But you still have cases where you have very complex software, combination of software and hardware. You have strict dates, strict timelines. Immediately think of, like, software that you have in a cockpit of a Boeing airplane. Right. 

So that's not a very agile software. Almost by its definition. The life cycle developing a new plane could be 20 years, and then the training of the pilots could take another 15. It's not like you're going to switch, the pilots don't wake up in the morning and say, okay, now, software updates. And then they start looking at the manual and reading through how they fly the plane now. So you have industries that are more prone to be much more waterfall oriented than others, and you have projects that are much more waterfall than others. 

Tim Butara: Well, I mean, just this example, right. In one case, the worst case scenario is, a user can't access a website. In the other, the worst case scenario is, the plane falls down, right? 

Elad Simon: Yeah, exactly. So you don't want to be in the wrong camp in the wrong sense. And by the way, funnily enough, there's also the “wagile” camp, which is– I don't know if you ever heard about this. I've had a few friends from large consultancies, which I'm not going to name, but basically said, which is like the combination of waterfall and agile. You do basically waterfall, and you pretend to be agile. 

So basically what you do is you take a waterfall project and you slice it into sprints. So people feel like you're doing agile, but it's not really agile because you're not actually shifting direction. You're just slicing it into sprints. That doesn't really make it– I mean, the concept of slicing things into sprints and having a scrum master doesn't make you agile. These are good ceremonies for agile, but that's not what makes you agile. But what makes you agile is the concept of I don't know where I'm going. I'm going to have initial thought. I'm going to check it with users. I'm going to then build something, give it to users, get some feedback. Iterate on it, and iterate, and iterate, and iterate, and that motion, that cycle, that never ending cycle is what makes agile agile, not the scrum ceremonies or if you're using sprints or conduct, that doesn't make companies agile. In effect.

Tim Butara: Yeah. It's possible to introduce agile practices into waterfall project management. But what you described is just like kind of an unnatural attempt of joining both. 

Elad Simon: Yeah. In practice, you end up with the same thing, and you can just say that you're agile if that's important. Like, you don't end up with a better software. I mean, the magic of being agile and of being product led is that you end up having: one, faster delivery timeline, and you end up with something that is better for the users, that is more relevant for your end users, whoever they may be. This could be an internal user in an enterprise, or it could be a consumer using your app. It doesn't matter. You end up with something that is actually better for the users. 

And that's for me, in many cases, I guess you probably know that, in many cases, agile ends up being more like a cult concept of like, you have all these ceremonies around it, and they're important. We do that. We have a daily stand up and we have Scrum, and we have retros, and it's all good. That's not what makes the company agile actually. What makes the company agile is a change in the mindset of saying, hey, we are going to not expect in advance what's going to happen. We are going to actually listen to our users on an ongoing basis. And based on that, we're going to build software. 

Tim Butara: And I think that this is precisely the reason why agile is gaining ground recently. Because you mentioned before that agile is so efficient because it allows you to incorporate uncertainty into your planning. Right.  And in a world with so much disruption, in a world with so much uncertainty, you can't even expect to have sustainable success if you don't move into a methodology that's kind of best suited for this new way of the world. 

Elad Simon: Absolutely. And software, it's interesting how you look at the word. The way I think about it, eventually software building, like software development is becoming– the actual coding, let's say, is becoming like, slowly but surely commoditized apart from areas that are very complex, like cyber and AI, like, you have areas in software development that are, still require quite a lot of technical, let's say, expertise. 

But if you want to build now, like an app, like a web app, you can go to like a Bubble kind of thing and just build it like a low code / no code platform, and just build it yourself without any coding knowledge. But still, what is interesting is this iteration of like, okay, I build something, I give it to the users, I collect their feedback, I change it accordingly. Right. So the magic, and this connects to the first question you asked me. 

The magic is at the product level. The magic eventually, in my mind, of course, he can say it because I'm a CEO of a company that works as product manager. So I have my own biases for sure. But in my mind, eventually, when you're building software, in many cases, the magic is, like, how you think about the product and how you shift it over time. For me, that's like one of the core things in agile. 

Tim Butara: Okay. Can we now go more practical? Can you share some insights, some first-hand insights from your experiences? I know that you work with companies such as Kimberly Clark, SAP, Cisco, as they adopted or moved into product management. Can you talk a little bit about those? 

Elad Simon: Yeah. For me, I look at these big beasts in a lot of fascination and honestly, with a lot of awe and appreciation. So they're trying to make a transition in a world that has really shifted very radically and very quickly, and they now have to adopt concepts like digital transformation and product management very, very quickly in a very short period of time. Now, the reason people have been talking about digital transformation, about this concept of product-led and the concept of product management for quite some time. 

But Covid and I think people talk about it more and more, but the reality is that the Covid pandemic made a huge, like it pressed the “Accelerate” button so aggressively because now everything is clear now that a lot of the consumption experience and a lot of the work around logistics and marketing and sales is now software-related. So if you're Kimberly Clark and you want to be selling now FMCG products, toilet papers, diapers, et cetera, et cetera, you now need to have APIs from your catalog, your digital catalog, into Walmart and Target and all these guys. 

And if you don't have it or if it's crap or if it's not well built, or if it doesn't give the right data to the online reader or to the retailers themselves, but even for their stores, you will be behind, which is the interesting part. What happens in the world is that now in the non-digital space, like you're selling non-digital products, you still have to compete in your capabilities of building software.

Because if Kimberly Clark doesn't do it, somebody else will. A competitor, Kimberly Clark, will do it. And if they do it better, they'll get more shelf space in Walmart. They'll be an easier partner to work with. Their salespeople will not be optimized in who they address first, because they don't know from a supply chain perspective, they don't know where the gaps are in the market. 

All this stuff is happening in the real world, not the world of software. So that change. We work with these companies through that change. And as they understand that if they take project managers and just tell them, hey, you go build software, like in the old way of building software, waterfall, by the time they finish building the software, it's obsolete because the API on Walmart’s side changed. Software is moving very fast. By definition, it's moving very fast. And if you don't have because you're interconnected to everything, it's just not going to happen.

And even if you're building a completely internal system, let's say you're building a marketing attribution system for the marketing teams in Kimberly Clark. Right. And you just want to help them understand which channels are working better, marketing, mixed modeling, whatever it is. If you're going to build it in a year and a half and by specs that you wrote, the whole market would have changed, the dynamics of the digital landscape moved. Everything could have moved. Like cookie tracking change, browser behaviors change. If you can't cope with that, you're going to have crap software. 

So they understand that. And that's where we come in and we help them with the transformation into this. And the way I think of change management in general, it always has three legs. You have people, you have processes, and you have tools, right. So that's like general change management. And we work with them practically on all levels because of our software. Our software allows us to help both with making product managers better at what they do. We have this thing called Guru in craft.io, which is kind of like a layer in the product that allows you to bring best practices or product management into the tool. 

And of course, we help solidify and clarify the processes into the tools so that people follow, let's say good practice product management process so that they don't skip, for example, steps like validating your process with customers. This is very easy to skip. I mean, a lot of people in the product management industry, like Melissa Perri and Teresa Torres, they speak a lot about this concept of the build trap or people very, very– like, a lot of product managers and agile teams really focus on building stuff on like, you know, let's build a feature. Let's keep the engineers busy. That's a real strong driver. 

However, if you end up building stuff that nobody needs or you haven't validated with your consumers or your users, you're just building feature bloat. It's like really bad use of time and you're making your software worse, which is really horrible. So the role of the product managers and the role of crafting that context is really to make sure that that process is being followed in a way that doesn't skip the steps that are so critical to the success of a product. Like discovery, understanding the problem better. All these things are so critical to the success of a good product. 

Tim Butara: Yes, some very, very good points here. I actually have a personal anecdote here from when I was working in product development and we were developing this app. We were constantly talking about features, iterating on everything, tweaking, we were doing it in the proper agile way. But we fell right into this pitfall that you highlighted just now. You know what we forgot to do? 

We forgot to add a search feature to the app because we were so focused on everything else. And then we rolled out the MVP and we had our coworkers tested. And the number one piece of feedback that came back was where the hell is the search function? And we were like, yeah. 

Elad Simon: But the nice thing about your anecdote is that you've done an MVP and you rolled it out and you ask people what they think. That's the magic. Because if you instead of that two years long of building the software and big rollout and then discover that you're missing the search functionality, then you're really in a tight spot. So you'd rather make a small mistake fast and iterate. 

Honestly, that's a perfect example of an awesome product, of awesome product and awesome agile delivery. Because as long as teams don't skip the step, even if it's like after they originally launched something, an MVP, it's fine. You'll have a small user base and you'll have time to iterate. But to your point, and that's the interesting thing, what you see in the big companies like Kimberly Clark or Fannie Mae, companies I’ve worked with, you see the big change in the thing is the mindset of the end users and the users of whatever is your building. In many cases, these are internal users. 

Explaining to a business counterpart in a big enterprise to say, like, listen, I'm going to give you something. It's probably going to be a bit shady. It's not going to be great, but I'm going to iterate very fast on it. This is not how people are accustomed to work with. They want to say, I want exactly this, green button, blue that, five things on the menu, whatever. And that's it. And that's what I want. And you build me exactly that. And then you said, no, listen, if I build you that, you're going to get like, you're not going to be happy with it. Let me build something very nimble, very quickly. I give that to you. You tell me your feedback and then we'll iterate. 

This is a mind shift at the side of the users as it is. And the funny thing is, as consumers, we're all accustomed to this. We get like software update– if you get a new version of Android on your phone, you're waiting for the bugs to come up. You just know your phone is going to be a little bit crappy now for a little bit, and then afterwards it's going to be better. And it's like how we're used to now consuming software. 

But in large enterprises, that mindset still hasn't shifted because they're so used to these big waterfall kind of project thingies. So that's like the mindset shift you need to do beyond just the product manager themselves. You need to shift the minds of the end users, which is kind of interesting. 

Tim Butara: Yeah. That's basically the people part of the digital transformation. And yeah, we already started talking about the MVP or the minimum viable product. I know that this is key both for product development as well as for Agile, because it's based on taking this iterative approach as we just talked about. Can we talk a little bit more about this, about the minimum viable product?

Elad Simon: Yes, absolutely. I mean, we're in a podcast. I'm not going to show anything, but there's a very famous cartoon, kind of diagram of showing a skateboard and then a bicycle, and then you notice and then a motorcycle, and then a car, versus like a car with just the wheels. The concept of MVP is very elusive and it's very confusing to people. And I also think, by the way, different companies in different stages of maturity will have different concepts around MVP. 

It's okay. It's like a moving, it's not like a one size fits all concept, because an MVP for Google today is not the same as an MVP for Craft today, because we're a young startup and we're growing and we're happy and everything is fine. But we're still like below 100 people and we're rapidly growing and we want to iterate fast. And that's okay. If you are 200,000 people Google, people have expectations. 

The first thing I would say about MVP is the concept is different between different stages of maturity of the company and in some cases of the product. So you can have an MVP feature. But in a product that is so mature that you're going to need to do some more like the minimum thing and it needs to be checked. The other thing is, the concept of the MVP is very simple. It basically says get something out the door that delivers some value. 

And that's one of the things that people really missed out on. I speak to a lot of product managers, really. That's part of my day to day work, and I love it. But in many cases, people forget about the fact, you can't release an MVP if it doesn't add value to do users. It's not useful. MVP has to deliver value. It doesn't have to be all the value. It doesn't have to be amazing. It has to deliver value. 

And so when you say minimum viable product, I think that's what the viable kind of stands for eventually. The viability comes from the notion that it actually gives some value to the user. 

Tim Butara: So it could also be minimum valuable product. 

Elad Simon: Exactly. I mean, it's still MVP kind of thing. For me, that's like one of the things that, one of the big mistakes in MVP is, you ship things out and they just don't have or in some cases, by the way, in work, I've seen people ship an MVP, which detracts value, like you have like an MVP version that actually reduces, I've seen that happen. In reality, that happens not because of bad intentions by anybody or whatnot. It's just because you want to ship fast. 

And MVP, of course, one of the concepts of MVP is to say, bring something to the market, get feedback, and iterate on it. That's logic, and that's fine. But it's a really fine balance, in my mind, because sometimes you can bring something to the market that is so unready, uncooked, you know what I mean? That you can end up so disappointing your customers, so disappointing your customers that they might run away from your product. And then you might get the wrong impression about a feature. So there's like, it's really a delicate balance. And I think eventually good product practitioners know where to strike that balance. 

And I'm very fortunate to work with Roni who’s our chief product officer, who is so clear about where that line cut. But I don't think there's an obvious recipe to say, like, hey, where do you cut the line? Where is this is now minimum viable kind of thing. But the only thing you need to make sure is one thing is that you actually deliver a minimum value to the user, and, no less important, that you iterate on it very fast. 

The other thing I've seen some people do is you launch an MVP and then it just stays there. That's the end kind of thing. And if you actually don't intend to have a phase one and a phase two and a phase three, you need to think about the concept of MVP for yourself. The whole purpose, the whole model behind MVP is that you iterate on it. If you're saying, hey, actually, afterwards, I won't be able to touch it ever, which might happen, then you might want to bring something a little bit more mature into the market. 

Tim Butara: Yeah. I think the main purpose, in my own view, the main purpose of the MVP should be to enable you really thorough and really concrete user feedback right. Because you can do user research preemptively for a product that you're intending to build and you don't really know how it will play out when it's actually built, when they're actually using it. With an MVP, you get that other, the practical side of the practical side of the product. 

Elad Simon: Yeah, of course. User research in that sense, it's obviously very valuable, but it has a lot of limitations in that sense. Right. Users, until they actually put their hands on a piece of software, they have no clue. And by the way, interestingly enough, in software that doesn't solve obvious problems, users can be completely agnostic until they actually feel the MVP. Like, if you think of a company like Airbnb, they've invented a new category in a way. And if you just do user research on it, people say, what, I want to live in somebody else's flat, you know what I mean? 

Until they actually have an experience that they can actually feel they're not going to give, the feedback is going to be very conceptual and could be very wrong in a way. Right. So to your point, shipping something out is important. And by the way, again, to emphasize the original point I started with, it really depends where you are in your life stage as a company. 

If you're in early stage startup, you don't have a product yet, you're just validating the market. You get an MVP out there. It could be like completely like smoke and mirrors. Right. So just like a website with a button that clicks on it, that's it. Nothing happens after. And that's okay for an MVP. It really depends on how fast you need to validate and how big of the validation is unique. As you mature in your product lifecycle, the MVP concepts change quite dramatically. 

Tim Butara: Yeah. At first, I mean, for a really small company, even just a clickable wireframe can do the job. 

Elad Simon: Exactly, like an InVision with some– yeah, absolutely. That gives people a really good sense. Right. And that's fantastic for an MVP. I mean, probably you might want to code a little bit, but this concept, because it's such a broad concept and it's used in so many spaces in product management, in agile development, it really depends. 

Tim Butara: Yeah. I think some great points here as well, and I'm really loving this conversation and I think that we've covered a lot of stuff. But one important thing that I want to ask you is what would be your tips for the companies that are starting to move to a product management approach or facing challenges, are having trouble implementing it. What would you advise to these kind of companies and these kind of company owners? 

Elad Simon: Yeah, I would say probably three things that come to my mind as the three things to think about. One, you cannot fudge the mindset shift. It's very easy to fudge it. Very easy to fudge, but you cannot fudge it. And I think a lot of companies get that really wrong. Like, I see that a lot, especially in enterprise land. I see that happen quite often where people are like, yeah, and then they put posters and now there are no offices anymore. Conceptually, they would have put a poster, and now it’s virtual posters. 

But you talk about Agile and you expand the notion that the mindset shift really has to come from the leadership and trickle down of accepting this notion of like, yes, we're going to iterate and it's not going to be perfect at the beginning and you're going to get a better version later. And and and. And this commitment, this mindset is basically this commitment to say, like, hey, I trust the people in the squads or in my scrum teams to overtime come up with the best thing for us. 

That mindset shift. I always see it underestimated, like, always. And then people really fall very easily into their old habits of like, okay, but I want to know, what am I getting for this money, right? I'm giving you now $10 million budget. What features are you building for me? And if you are as a leader asking that question, you are breaking down the whole concept of agile product management, product mindset. It breaks it, because then people immediately shift their minds into, I need to commit to features, first of all, right? And then that immediately is like, you just moved from agile land to waterfall land. It's just how it is. 

So that's first one. So the first one is, don't underestimate the cultural shift that needs to happen in the organization. And as a leader, you need to lead that concept. If you're sitting in an annual planning and you're asking, giving a list of features for the next 24 months, you broke it, it's going to die. You're not going to succeed in change management. So that's one. 

The second thing I would say is that invest in the people, processes and tools. Right? So, I mean, we see a lot of companies. It's a really big differentiation, to be honest, that companies that invest in building in centers of excellence and transformation teams are better at this. And the reason why they're better at this shift to product management. And the reason is because they have people whose job is to say, okay, we are going to help the organization transform. We're going to help the organization change and shift and become better at this. 

And because you need to change people, processes and tools, that's a lot of change management on your hands, right? So you need to train people. You need to agree together with the teams on processes, and you need to embed tools so that they solidify the people and the processes into something that is scalable. All this stuff really has to really– needs an owner. 

When I talk to CIOs of big companies, I would say, hey, if you want to make a really big shift in your company, build a transformation team or a center of excellence or something that says, hey, I decided as a CIO decided to invest resources and efforts in making that transformation successful. Sometimes these things become like they could be sourced to cynicism. But I'm a really big believer in them because I think without them, people just would organically revert to their old habits because that's how– you need to change agents in the company. So that would be my second thing.

And then my third thing. Don't fall into the trap of agile cultness. I don't know exactly how to say that. There's a lot of this. I've seen that a lot of companies where you say, okay, I decided to become an agile company. So we're going to implement SAFe as an enterprise now. I don't have anything against SAFe. SAFe is a fantastic framework for scaled agile and large enterprise, and that's great. And value streams and whatnot, you have a lot of beautiful frameworks within the world of agile, for smaller companies, for bigger companies, it's all good. 

Ceremonies and frameworks don't make the change. Don't confuse that with that. They are enablers of change. They are supporters of change. But the fact that you've changed everybody's acronyms and you confused this organization doesn't make you an agile company. All it does makes you maybe an agile sounding company or a product sounding company, but it doesn't make you product mindset. 

The real shift is in the mindset, and the real shift is in the trust that you entrust the people of building the software for you. So you need to really look deeply into when you're doing your change management and avoid falling into the trap of, like, just doing Agile by naming conventions and ceremonies. These are important, but they're not the end-all be-all. The mindset is the key.

Tim Butara: I think on a recent episode, our guest used the perfect word that I think that you're looking for right now. He called this agile theater. 

Elad Simon: Yes, that's perfect. I will steal it for my own benefit from now on. But it's perfect. Yes, it's exactly that, by the way, it creates, as a side note, I would say in many cases it creates a huge amount of confusion, because you change everybody's terms, like people, they don't know what they're talking anymore, like people talking ARTs and value streams and they don't know what they read.

And again, I'm not saying I am– Craft as a concept believes that you can build, you bring your own methodology, and we will embed it in the tool in a way that is good for you. We're methodology agnostic in the sense that we believe that all methodologies are good because eventually they're all built under similar principles of saying, look at the– focus on the customer, iterate fast. They're good practices of agile. That's how they're built and bring value. And even the concept of value streams, again, it's like an abstraction level of that concept as well. 

Being in this theater, as you call it, eventually creates a really big gap between the realities of the organization and how everybody behaves in the ceremonies. And for us that's more dangerous than not doing change in a way because then you're claiming to do it like you think– and then people start being cynical about it. People start being cynical about the notions of agile and about the notion of this mindset shift. 

Tim Butara: Well, yeah, I agree and I think that was actually a perfect note to finish on. I think that, as I said, we covered a lot of really interesting areas. I think we highlighted a lot of interesting, unique insights. I really enjoyed our conversation today, Elad. Just before we wrap up the call, if our listeners wanted to reach out or learn more about you or learn more about Craft, where can they reach you? 

Elad Simon: First of all, super enjoyed our conversation as well. It's fantastic chatting about it. As you can see, I'm very passionate about this topic. Always happy to talk about this. Feel free to reach out personally to me. I'm elad@craft.io, the same as you spell the word craft and the website is craft.io as well. So feel free to find us either there or ping me a note directly and happy to connect with agile practitioners, product enthusiasts and the rest. 

Tim Butara: Awesome. I'll make sure to include all the relevant info in the show notes. Thanks again. 

Elad Simon: I appreciate it. Thanks a lot, Tim. 

Tim Butara: Well, to our listeners, that's all for this episode. Have a great day, everyone and stay safe.

Outro: 
Thanks for tuning in. If you'd like to check out our other episodes, you can find all of them at agildrop.com/podcast as well as on all the most popular podcasting platforms. Make sure to subscribe so you don't miss any new episodes and don't forget to share the podcast with your friends and colleagues.