NO-CODE PLAYBOOK: THE FRAMEWORK

JASON MILLER: Welcome to Creatio’s No-Code Playbook podcast, where we discuss insights, tips, success stories, and how to leverage the no-code approach to transform business and deliver applications of any complexity. I'm your host Jason Miller, Head of Pre-Sales for Creatio in the Americas. Today we're going to talk about the no-code framework and the things to think about when choosing to use no-code over at the software solutions. I'm pleased to introduce today's guest. Burley Kawasaki is the founder of Tachyon Solutions and the co-author of the No-Code Playbook. Welcome, Burley. 

BURLEY KAWASAKI: Thanks, Jason. Happy to be here. 

JASON MILLER: Burley, first of all, I want to say congratulations on the early electronic publishing and the hard copy of the book that's coming out now. I will tell you I've read it twice now. And I'm still, every time I go back through it and do new references, there are new things I pick up. So, from myself and all the no-code creators worldwide, thank you for putting together such a wonderful book and piece for us to reference.  

BURLEY KAWASAKI: Thanks, you're very welcome. It was a labor of love. I can only compare it to having children. This sort of intense process you go through. And then, when you're done, you should look back, and you have all these fuzzy fun memories. But it was a lot of work to pull it together, and I couldn't have done it without Katherine and the whole Creatio team. So, I'm incredibly proud.   

JASON MILLER: I know it took some time to put all this together. What was the inspiration, or what were some of your thoughts and reasoning behind the decision to write this No-Code Playbook? 

BURLEY KAWASAKI: Well, it came out of some discussions that I had with Katherine. We started talking about the fact that no-code is going through an evolution in many ways that parallel. If I look at the way Agile transformed, maybe traditional professional development. But in the early days, you know, started using and applying some of the Agile concepts from the Agile manifesto, it was adopted by lots of small teams, SMBs. And they adopted it because they knew it was right for them. But it took a while for the enterprise to embrace it and start adapting it to the more complex enterprise requirements. And we realized there was a need for equivalent guidance and a framework available to support no-code as it began to become more broadly deployed by enterprises. And for a range of use cases. And so, seeing this as an overall maturation process, that was why we "there's a void in the market that we can help address."  

JASON MILLER: Yeah, and often when I'm out talking with customers about that relationship to how Agile transformed application development lifecycles, I always make that parallel correlation. Because I agree with you; not only did the age of cloud computing help accelerate the need for that difference in delivery methodology from more of a Waterfall or a traditional approach to Agile. We're seeing the same thing now with a traditional shift from Agile and CloudOps or DevOps towards this approach of real-time everyday delivery. Whether it's extreme delivery or just shortening those cycle times on your sprint, we're seeing it. Because teams can move faster, they're taking on these low-hanging fruit a lot, so they can deliver quickly and show value to the business. So, I agree with you on that one. I know that as we've talked with Katherine in the past and some other folks involved with creating the book. It was not just a labor of love, and it wasn't just meant to be out there and pitch Creatio. If people haven't read it yet, one of the things that they need to understand is this book is technology-agnostic. So, why did you go with the technology-agnostic approach? 

BURLEY KAWASAKI: Well, for a couple of reasons, Jason. First of all, we want it to be taken seriously. And for it to come across and be adopted and be part of a discussion, we knew it could and should have. It couldn't be seen as purely just a marketing initiative from Сreatio. It had something more ambitious; it had to have a broader reach. So Katherine and I both agreed on that very early. It needed to be bigger and more ambitious. I would say this one or two; we knew the intended audience for the Playbook. This isn't intended for developers; it's not intended for IT. It's meant for the business and either mix of stakeholders and senior leaders, but also practitioners. You know, the more you get into the business, in some ways, the less relevant you know the technology. I mean that only in the sense that you know you have to first connect with something that matters to them in sort of their business challenges, then technology can help them solve that. But if you rely too much on technology and, especially, if you lead already with a particular vendor or set of vendors, I think you risk alienating the business, and we want to be very much approachable to the business as our primary audience. 

JASON MILLER: I agree. And I have recently finished reading another book on low-code/no-code where the author laid out probably 15-20 different technologies within the book. You're right; it was very easy to get lost in some of the technology speak, though, what's this, what's that, oh it only does this, it only does that. And the approach you took with Katherine, talking about the business impact and how to empower those subject matter experts that can become those citizen developers or no code creators. I think that was a great approach. So, when you think about the message, let's call it the top two or three messages that you were hoping those business users, those no-code creators of the future, wanted to get out of the book. What were those top two or three in your mind? 

BURLEY KAWASAKI: These were laid out in. We wanted to instill some principles that the rest of the book was set to build on top of and around. And those ended up being more profound than I realized. We started thinking and applying them to how we struck at much of the content. The first principle was during requirements and design to embrace the use of no-code tools to perform the design itself. I think it was a pretty fundamental but significant shift. We thought about structuring the lifecycle because it eliminated a lot of unnecessary, typical design ceremonies and artifacts and many things you would have seen if you were picking up Agile methods. A handbook or something is written for developers to embrace using the tools themselves to support and create the requirements and design. The second principle is all about whatever you can build with no-code – you build with no-code. This may seem obvious, but you have so many choices as you put together a more complex enterprise solution. It's about keeping things simple. Fewer number of pieces in a vision or an architecture generally is better. Because these are to maintain and standardize on no-code as much as possible gives you a simpler, more maintainable approach in the future. And then the third principle, which then threads through a lot of the methodology, is around delivering value to users as fast as possible. And it's the whole concept. We talk a lot about everyday delivery and how not to be constrained by predefine release structures or have to wait until the next release or sprint. But when you have a value that you can unlock and deliver to users, when not push it alive, it goes to not of the way you build and release a more continuous delivery type model. But it is also fun how you think about even scoping value into the smallest possible use cases. So that as you complete small pieces that can add value to the release, you rather batch it up into some massive ones. So those are the three principles. Start with the requirement and design, use the tools, build with no-code as much as possible, and then deliver value to end users as fast as possible. Those are sort of three principles that really thread throughout the entire Playbook. 

JASON MILLER: I 100% agree. Not only do you talk about those things. I've been working in the no-code and CRM space for quite a while. But for those who call it uninitiated or folks that have not tried to start putting their toe into the water of no-code and low-code. You and Katherine did a good job in the intro section of the book, talking about what is no-code, where the foundations are, and everything lines. And if you think about that first section, the introduction of no-code, you've got five chapters in there. The way you laid those things out focused on those business users, not the technologists. I think you also did a good job of setting up how technology has grown today. But technology over the last 60-70 years it's just constantly evolved. But the idea of no-code it's not a new idea, right? It's been around for a while. It's just that the tools have gotten so much better. So why was it now the right time to help introduce this to folks? Were some of those things you were thinking about while writing that first section of the book? 

BURLEY KAWASAKI: Yeah, and it's a great question. And even I would say that question answering it with instrumental even the title. Because we intentionally call this the No-Code Playbook, not the low-code/no-code playbook. It's pretty common when you read articles, no-code, low-code, or the combined inflated into a single concept. And everyone writes about it as if it were a single thing. And at some level, from purely the historian level, you can look at the evolution of technologies, as you pointed out. I mean rapid application development and other techniques have been around for a while. And so, in that sense, low-code certainly did influence no-code. You know, created no-code. But I think the important difference with what we are talking about today is that no-code is an approach that has been used by non-developers. Low-code is fundamentally when you unpack it's still used by developers, still used by IT, and perhaps a less sophisticated technology person. But they have to have some understanding of coding, they have to have some understanding of application development. I'm not taking away from the benefits that it has, but it's for an audience that has already to have matured over several decades of development practices. And low-code is sort of thing step for that no-code entirely different in that it's being adopted and used by people that have never developed before. And if you think about a typical enterprise, there are a lot more non-developers than there are developers. And it’s probably expanding that the pool of people inside your business that can build by a factor of eight or ten. So, this unlocks and democratizes how you can think about harnessing innovation and technology. That no-code is doing for the first time is very different from the more incremental evolutions of technology we have seen in the past.    

JASON MILLER: So, there are two questions that I want to follow up on that. The first is the need. So, unlocking those non-technical folks and allowing them to become part of a fusion team. And we'll talk about a fusion team in the next episode of a podcast in the future. But when we talk about bringing those folks in, there are many great statistics from Gartner and others that say, look, there are not enough professional developers in the world to meet the changing demand. So, that's probably one of the big reasons why the advancement in the revolution underway with no-code is happening. Would you agree with that statement? 

BURLEY KAWASAKI: Absolutely. I would say this was happening at a pace now because of the emergence of digital surveilling appetites. When the pandemic hit us three years ago, it almost profoundly created a supply and demand imbalance. Everyone talks about, especially during the holidays, how hard it is to get physical items because of supply chain imbalances. That's just as true in sort of developer talent. You saw this constriction of people that were entering universities. You saw this reduction in terms of the number of HNB visas that were available. And so, the pool of technical developer talent with shrinking which leads to some of the shortages that you've highlighted. At the same time, everyone is trying to get online. Because that's how people buy when you're quarantined. People were investing heavily in online and digital at a pace that different studies have shown maybe four or five years faster than it would have happened, had it not been for that pandemic. It's the supply in-demand, perfect storm where the supply is constricting demand is exploding. And you can't just ask developers to work harder, work twice as hard, five times as hard to keep up. And it creates this ideal condition for something like no-code to be embraced. Because, again, it unlocks a much larger town pool insight most businesses. It also helps to be much more reactive to change; if there's anything true, it's the average. The only constant is a change. Who would have predicted what we see around us in terms of being nimble and agile to respond to the market and follow your customer and adapt to their needs? The ability for no-code to support very rapid iteration, as well as the unlocking of the talent pool, combine to create a tremendous appetite for a no-code.   

JASON MILLER: Yeah, I wholeheartedly agree. And you mentioned what I was going to get to in the second step, which was how everything was accelerated to the pandemic, and now it's become the norm. And no-code, in general, will become the norm. There are a couple of interesting statistics out there. And I recently talked with Phil Simon, author of "Low-code/no-code." He quotes the statistic in his book: by 2023, by 2024, nearly 80% of all applications will be developed either using low-code or no-code. That margin of no code in that 80% will continue to grow for the reasons we just talked about. So, we've got about four or five minutes left here. I want to get into one more topic before we wrap up today. And that is when you thought about the methodologies that needed to change when it comes to no-code. We're going to talk about this in a future episode of this podcast. But when you think about the methodologies that needed to change, what were some of the key points that you identified early on as you were writing this book? Where do these things need to be addressed because they will be fundamental to adopting no-code? 

BURLEY KAWASAKI: Yeah, that's a great question. The first question you have to ask yourself, which we did ask ourselves, was, why do we need to create another methodology? In the last decades of software development, there has been a lot of effort to create and improve. And there are a ton of methodologies out there from Agile, DevOps, and practices. But as we looked at them, it was clear that to embrace or adopt these again truly, it was targeting a developer and a more technical audience. And many of the ceremonies and many things that would make sense were highly effective when developers could adopt them in a team of developers in the case of agile practices or scrum. We're not the right or best suited for business teams that may not yet have gone through any training, do not have the organization for things like scrum masters, or you could ask them to try to become technologists and to go through training. But we ultimately decided it was important to step back and reimagine what the lifecycle looks like. A lot of this is around trying to put ourselves in the shoes of business and trying to think about the pressures there. And in many of the frustrations that the business has today, of waiting on the backlog and waiting until that next release or the next several releases to access some feature, they're looking for. It led to the concept of everyday delivery that we had touched on earlier. Which is to get out small incremental units of value every day, don't be constrained. And we move to still adopting Agile principles but not necessarily the full Agile Scrum. We looked at things like Kanban, for example, which are still very effective techniques but are better suited for the business. And we also looked at ways to reduce a lot of the ceremony or the sheer volumes of documentation that a developer is used to because it documents the stack and it's needed. If you're going to write code to comply with this fact, you think about this more iterative and fluid world that we live in with no-code. The best way to validate something with an end user is to show them a working prototype or work model of the actual solution. And so, we got into this sort of idea, this notion of using the tools to build the design, about that design and prototype. And then just continue to evolve and mature it. And that becomes the working solution so that those sorts of concepts that everyday delivery really ting using the no-code tools that really shaped and created a methodology that we think is uniquely suited for no-code, as opposed to trying to force it, like Scrum or some other developer methodologies and retrofit that into the business needs. 

JASON MILLER: Indeed. Well, Burley, it's been great to talk to you. And what we've covered in this episode was the first two sections of the No-Code Playbook. We've talked about an introduction to no-code and a little bit of history. We also talked about some of the early design things and the thinking we had to address in the No-Code Playbook. Now we're going to get back together in a future episode, and we'll talk a little bit more detail with folks about some of the everyday delivery and how to still maintain governance. And we're going to talk about things like divining the minimal viable product and then attacking those things delivering value every single day while still keeping all of, I'll call it, the technical folks, the IT folks, the governance folks, keeping all of those folks happy. 

For those of you who are watching us on the YouTube channel, please, make sure to like the video, share the video, and subscribe.

For those who are listening to us on your favorite podcast platform, we hope you've enjoyed our time together today. Check out our previous episodes on various platforms, including Apple Podcasts, Google Podcasts, Spotify, Soundcloud, and more.  

To get more information about our products and services, visit our website. And for more insights and upcoming events, check our No-code events page.

Talk soon!