#42 Low-Code Development, Agile Best Practices and Pitfalls to avoid

Hello and welcome to another episode of the Process and Automation Podcast with the Automation Guys. So today we thought we will go back on the low-code application development. And when we speak to our customers and our prospects, yeah, We, we all also hear a lot of problems from problems they have had, maybe was previous projects. And, and today we thought we will cover some of the pitfalls of low-code application development so you don't have to do the same mistakes again. And yeah, I think that, that's, that's what we want to cover today. Shall we cover what is low-code and why low-code development in general matters, Arno?

Yeah, sure. So of course, for some of our listeners that haven't heard about low-code, low-code is a discipline of software development whereby you use no coding or minimum coding to create enterprise-grade applications. And what that means is that you can create software up to 10% faster by using a low-code platform and the configuration of the platform that allows you to assemble business applications. So, you know, low-code development is becoming very mainstream. A lot of businesses are utilizing it. And, you know, if you do it right, low-code allows you to deliver better functionality than, you know, compared to conventional development at a faster pace. And also you can rely on small, smaller teams, smaller development teams to deliver the software. And of course, when you collaborate with end users. Low-code lends itself to that sort of end-user collaboration software development. It's a very powerful methodology to create applications. And, you know, what we're seeing out there, Sasha, is that, you know, many IT teams out there that is starting to use low-code is only really starting to scratch the surface of the potential of it. And, you know, we see a lot of pitfalls in some low-code project where these low-code projects are run with high-code approaches. So what we wanna cover today is really to touch on how, you know, how do you get the full power of low-code and low-code development from your existing IT team And, you know, how do you shape that team to bring it out of that sort of conventional Java and C++ and C# development and bring those methodologies and those ways of development, which can be a bit bloated at some stages or some instances and kind of address some of the common pitfalls, I guess, to really, you know, sort of exploit low-code better in your organization and, you know, to roll out projects using low-code, you know, without, you know, those pitfalls and encountering those pitfalls.

Yeah, and we today, yeah, it will be sort of 4 pitfalls and if you take those things on board, I'm sure your projects will be far more successful than before. So let's, let's jump, jump straight into pitfall number 1. What we see as well, you mentioned, you touched on this, Arno, earlier, so the development teams are maybe too, too specialized in high code and very often too big. And so that, that really This is what we see with the traditional development teams full of excessive inter- and intra-dependencies and effectively with low-code, you will generally go for an approach where you have a small team with all the skills you need to really go from idea to application. That kind of idea. And then, and these small teams, they stay together sort of across the projects so they don't have to spend time learning how to collaborate in general. And these small teams, they have a really good set of functionality or skill set, something what we generally need more in the market to, to do more of these low-code projects. So you have generally people who are the product owners, so that's, that's the role that does not really develop the features, but so comes, comes into the, the project or into the team from, from a, from a business perspective. You have roles who are very skilled, UX design skills, people who, who can really build at that really user experience and really good user interfaces, interaction design, all that kind of stuff. Technical design and architecture skills, business analysts really gathering and digging deep into the business requirements and of the user needs. And of course you need this testing and, and someone who's leading that, that small team. And typically Maybe that will be a Scrum Master. If you're familiar with that agile methodology, Scrum, Scrum Master would also be part of that role. And with this small, powerful unit, you can really get everything done. You don't have to go into another team and ask for help. You can really, as that, that unit, you can, um, yeah, really from idea to deployment, go live, um, you can get it done.

Yeah, exactly. And that's, that's, that's a good point. I think, you know, what you're talking about is this sort of people that's interchangeable with inside the roles. So, you know, you touch on the fact that you've got a product owner and that's the person that obviously need to transform something on behalf of the business. And again, What we see in a sort of a streamlined, optimized low-code team is that the product owner won't necessarily get involved in any of the technical elements of the project at all. It's good for project or product owners to understand the capabilities of what low-code can offer so they can articulate that to the business, including the benefits of it, how quickly it is to roll an application out. But of course, like you've touched on those other disciplines, a good UX designer, a technical designer, a person that's in charge of architecture, a business analyst that looks after the requirements and tease that out from, you know, sort of the end users, a test function, and then obviously a team leader or a Scrum Master. So what we're saying is that, you know, we want to design our low-code team So they embrace collaboration and they, they should also be multi-disciplined. So a good UX designer should also be somebody that can develop some low-code elements of a system, for example, or somebody that does testing should also be able to, be able to collaborate with the end user on a requirements point and If you create this sort of interchangeable roles with inside the team, you kind of minimize dependencies, specialized dependencies between people, and you create a truly sort of agile and nimble makeup of the team so that people can do some of the different disciplines, including end-user engagement, being able to talk to end-user. And like you mentioned, If you compare this to traditional high-code development where there's a dependency on a database person to go and create a database, well, you don't have it in this instance because obviously everybody in that team knows how to configure a low-code data storage area in the system. So it just speeds that, that that part of the process up.

Yeah, and some companies or some people might say, okay, all these skills, well, do I need a person each for all these skills? Then suddenly I have a team again of like 6, 7 people. This is already quite large in my thinking. So this is what we hear sometimes. No, no, you can to kick off. Sometimes people can wear different hats, so these skills need to be available. It doesn't need to be that they necessarily sit with the same person. Yeah, yeah, could sit with the same person. So that's, that's very important as well. So you don't need to have a team of 7 people to start off with, and as long as these skills are available, you can get going.

Yeah, absolutely. And I think, you know, a product owner in a, in a very small low-code project, it could be a a version 1 of a project could actually be the lead end-user stakeholder. That person could functionally be responsible for what needs to be achieved to drive efficiency or to create automation. But you could have one person fulfilling the UX design, the technical design, the business analysis, Talking about requirements, the testing, and then obviously the rollout of the application and Scrum Master duties like having a standup with the product owner every morning to say, or periodically to say, with the— with, well, I've implemented this feature now, can you have a look at it? Can you provide feedback? Of course, if the project is larger, then you would have multiple people fulfilling these particular roles. But I think the key here is that it's truly cross-functional, what we expect from low-code developers or members of the low-code development team. And they can act in all of those different sort of disciplines. So it's sort of a generalized specialist, if you want to call it that. And again, they are cross-functional. They've got good skills to collaborate. They can understand requirements translation into a solution idea, for example. They can articulate that. So again, I think if the team is too big and too specialized, that, that's generally what we would consider to be a pitfall we, we would like to avoid.

Absolutely. So let's, let's jump into the, the second pitfall. So you're not digging deep enough into the problem. So when you think about traditional software development, it really relies on business analysts who sort of the connection, the translator between the business users and the technology teams. And yeah, so usually these, these two sides are very siloed from each other. So we talked about these skills, if it's not necessarily siloed, then it works much better. So, um, um, yeah, so, so usually when they are siloed they're experiencing problems of being separated and, yeah, and developers attempting to really go really crazy into the problems and not really good with communication. And yeah, so instead of programmers with a decade of Java experience, look for, for developers who are more, more really interested in solving problems than writing code. And this is what, what low-code is all about. So it's not about writing writing lots of code. So they may have one of those two technical specialties as well as the sort of the general knowledge of software development and the business domain. So that's, that's a really, really good combination. And yeah, as you find the right people, you should also foster a culture of asking open-ended questions and Otherwise people say yes, no, that's really, really not really getting you anywhere. So yeah, never take a requirement sort of at face value. So you always should ask why. So in some cases you should dig not just one level of why, you should maybe have, you should dig deeper and have maybe 3 or 4 times of why. Very similar like what the kids are asking, isn't it? When they're growing up, they're asking why, and then you have to explain, and then why, and so on. So, but then you really you dig deep and you get the full understanding. And yeah, so all this interviewing was why, and asking open-ended questions will happen usually at this project initiation, of course. And it was those collaborative sessions, was everyone included? Yeah, you will really find out what's the goal. Of the application. And yeah, so that's— it's super important to dig deep. Otherwise you will at some point go live and it's just missing all the expectations someone had for the project. So to sort of summarize this, you should really have these 5 areas. So what do you want to achieve with the application? Which end users and stakeholders will benefit, and what is the problem or the need the application must address. So what are the current pain points, bottlenecks, and, and all the other desired benefits of that application? And what must-have features and functions should the application have? And, and then you come up with, with your why questions. Why Why are these features and functions sort of must-haves? And yeah, and at some point, yeah, you're quite, quite, quite close on what is really needed and what are the measurable business goals for that in order of priority, etc. So yeah, so these, these are really, really important areas to look at. And if you Do not want to, uh, have a disappointment at the end. Um, please avoid that pitfall.

Yeah, exactly. So the third pitfall, um, that I want to touch on is just to do with feedback, um, general feedback when you develop an application. And I would say that generally, people will say feedback is very slow, it's very scarce, and it can sometimes be distorted. And with low-code, we can remove some of those obstacles that slow projects down when you look at high-code projects, for example. And with these traditional development practices, the feedback loops are, are really a sort of a, almost like a ferry between two places where business users on the one side and developers building applications is on the other side. And, you know, you constantly have to ferry the information back and forth very slowly, probably sometimes via email or long meetings. So it's a very high latency process and there is a risk that there's distortion when information gets or any feedback is ferried between the sort of the two parties, the business side and application developers. So a solution for this to avoid this pitfall emerges when you can bring the business users and developers very close together to create these applications. And like you said, Sasha, collaboratively, where there's open discussions on the next feature that's been worked on, how it works. Perhaps it could involve a sort of a visual wireframe, how that particular feature will be configured in low-code, and it could be discussion around that. So low-code really bridges that gap that we require to sort of ferry the feedback between business users on the one side and application developers on the other side. Because of course, what we can do with low-code is quickly create something, showcase it and say, is this what you mean by a reconciliation screen, for example? And the business users can say, yeah, we like that, but can it also have this, this and this? So it's very easy to communicate that and build that bridge almost a functional bridge so that the requirements and solution, you know, can flow freely. And again, it makes collaboration very, very easy and it encourages very clear and frequent input from, you know, all of the stakeholders involved, you know, which also, by the way, help you to test some certain assumptions perhaps that the developers has paid. And, you know, and it And it goes a long way to actually finding the right solution because it is something that you can sort of experiment with. And again, you know, if you have this mindset of increased collaboration and sort of iterative development, you get very early buy-in from stakeholders, especially end users, because they can see the system or the proposed solution that you're going to provide in the system very early on. So with conventional development, everything happens in the silo and the sort of the value comes out at the end of the project. So with low-code, we could sort of show the users the application and they can validate it and sort of influence how it takes shape before their eyes. And like I said earlier, you know, you could use prototypes and in-progress builds to give the user something concrete to react to and to validate the design. And, you know, and also to make sure that the development team has got a very clear understanding of what's needed. And so again, I think the message is instead of having this, the slow ferrying of feedback between the business and the development team, low-code kind of bridges that gap. And, you know, we see that daily, we see that daily where we are very comfortable having a developer, you know, interacting with the end user, discussing the design of a component. Pre-low-code, that would've been unheard of because that developer would've received a sort of functional brief somewhere. They would've had some idea of what's required. They would have no sort of direct input or direct feedback as they construct a feature or build a feature from the end user. So again, coming back to pitfall number 3, let's ensure that feedback is quick, it's frequent, and of course it's not distorted. It's a single, to the point, this is how it's going to work, this is a proof of concept we've created or mockup, are you guys happy with this? Get the results you need.

Yeah, we're going to an extreme actually next week on those kind of things with the feedback. We get everyone, so 12 people in one room. So it's sort of the sort of close, close before go live, but then we're really in one room sort of focused going through it, high intensity, sort of one week in one room, just pizza goes in to all the stakeholders, all the developers, the UX guys, and really everyone of that team and and the end users sitting there, we're doing high-intensity testing, feedback testing, smaller changes, small last tweaks. So that's a bit of the extreme side, but that is so helpful because you're closing the last glitches within a couple of days together and get sort of, while you're doing this in this week, sort of the, the really, really deep commitment and confirmation from the business that this is really sort of the, the product that we want to go live with. It doesn't mean it's set in stone anyway because we are agile and the next iteration is coming up anyway. Yeah, it is really, really helpful. I'm looking forward to this one. But yeah, this is pre, pre-low-code and pre-agile. That was It's just a 200-page document, the waterfall approach, and you just had to do it.

Yeah, I mean, we, as recently as last week, had a similar, I guess, a similar sort of session prior to go-live, and it was a day before go-live, and we discovered that a particular journey required a piece of information which the end user wouldn't be able to provide. So we could almost, as part of that acceptance, real-time sort of pivot away and create a solution using a lot of smart people in the room, but to say, well, we can actually circumvent that problem by changing a few things on how the application work. It was actually in the kind of acceptance meeting where that was briefly discussed. Everybody, we had consensus from everybody that that solution would work. And the low-code developer just went and he sort of just implemented there and then and on the fly. Now I know that's an extreme case, but it just shows you the hyper-agility that it provides you. Where people have got confidence in the fact that the ability to change and pivot is there. As long as the solution is clear and people understand what it is, it can be done. And that ensured that those project deadlines, which was really critical because it was to do with patient care, that was met. And we could go live that afternoon. And, you know, a lot of the sort of the project stakeholders just said they've never experienced something like that before because that would've been such a big blocker for them. Whereas with this, it is just another, it's just another thing that low-code offers you is that ability to fix problems very quickly and, sweep them away and, or move them out the way and move forward. So very, very good story, you know, similar to what you say with your sort of intense sessions as well. And it's just that final, that last mile of a project that you could still have changes to make a big, you know, impact, you know, towards the end of the project. And, you know, obviously this is a great enabler for that.

Yeah, I think, um, yeah, that's, that's very, very important, these, these feedback loops. Um, and that's, that's also, um, one of the next, um, you know, sort of our next pitfall. Um, traditionally, um, success was only sort of measured at go-live. Um, so that spec was written and then go-live, people looked at it and say, okay, that's great, or it's not great. Um, sure, there was user testing and maybe that was all fine because test cases were derived from sort of the, the spec. So functionally, yes, it's maybe the right product and you go live, but somehow users don't get it at the end, isn't it? So that's— this is why it's very important that, that after the initial discussions and going deep on the requirements in the so-called Sprint Zero, after that you, you should continue focusing on, on your end users users throughout the whole development lifecycle. So, so you just mentioned, Anna, you mentioned that one shortly before go-live, but in, yeah, we will definitely have this, these sessions where we speak with end users throughout the whole development, even maybe it's an 8-week development cycle. So we have every, every 2 weeks at least sort of a catch-up and a review of what's going on and invite them into the design process at every, every feature, new function, and, and give, give input and questions. So, so if that is the situation for, for everyone involved, it is very enjoyable. They can see the product building, they can feel they're building a product together with the developers, they can immediately identify big problems which come up. Maybe, maybe a feature and function initially was, was a really good thought-through function or feature, but then as soon as you sort of grab it and start using it, you think, ah, it doesn't work. So we have to go back to the drawing board. So if you have that constant cycle during development, maybe give them sort of the keys to a demo system and they can play around with it. So yeah, so that's— this is where you actually, um, where you will be successful at the end, or this— these things will make, make, make the success at the end by including them during that development cycle.

Yeah.

And crowdsource feedback, so throughout the company and But yeah, I think that's key. So if you don't do that and wait just for development team comes back after 8 weeks to go live or something, then yeah, there's always something which is not as someone thought in the beginning.

Yeah. And I'm a firm believer of Sprint Zero design. You know, that, that's the place where you kind of build a very deep understanding of your end users' needs and the pain points. And generally, that's a very good foundation to build the system. Um, but I think that, um, having end users part of that journey gives them ownership of what you're building. And I think the successes that comes out of those low-code projects is attributed to the sort of the end users and their inputs. And I think that, you know, it gives them satisfaction and opportunity to shine because they could really look at something that's been produced and see the features and their suggestions and all of the good ideas that they've contributed towards built into the system. It's very hard to design a system from day one that's got, you know, all of these great feedbacks and accounts for all of the sort of feedback that users provide as you create a system. It's very hard to sort of look into the future and understand what that would look like and what that feedback will be. So if you build the system with those people part of it and you could, like you say, crowdsource the feedback and, you know, the ideas from them, bake it into the system. That coupled with good initial Sprint Zero design, that's when you truly get to really, really special outputs, you know, where kind of IT provides the opportunity then almost for end users to shine. And take credit. And I think that, that, that's, that's, that's worth a lot, um, you know, especially if, if people look at it and they, they use it, um, they feel like they were part of, of that success story, they shaped it. And, um, you know, I guess the end goal is, is, is for, for, you know, for the application to, to become, uh, as much theirs as the application team, and they can kind of celebrate the success together. So very, very important, like you said, common pitfall, success is only measured at go-live, but it should be from day one where we sort of create those early releases, involve the users, like you said, give them the keys so they could run internal demos for a broader user group. And give them a sense of ownership.

Yeah, and Sprint Zero, yeah, it's absolutely important, um, um, but it is definitely— is always a moving target, um, yeah, after, after the Sprint Zero has been defined, um, in reality, um, so yeah.

Well, I would say that, um, if I look back at projects where users are involved from the start, it would be very hard to create a backlog, a project backlog, with, with all of the ideas and all of the nice things that they would like that makes their life easy in the application. So when you look at the, the end product or the end result, you know, it is sometimes so drastically different to how you imagined it to look, you know, when you look from a starting point. So, and I think that's important because, you know, the majority of the backlog that we see, and when I say backlog, I mean future requests and how people want to shape the the low-code application, you know, that happens throughout the life cycle of the project. You know, it's not something that happens up front. Everybody sits in a room for 5 days and we decide, you know, this is our ultimate list of features we wanna see in the application. So very powerful methodology, very powerful sort of way of doing things. And, you know, like I say, it still gives you an opportunity at the 11th hour to make things better and still apply changes or implement ideas to make the end result even better.

Right. So I hope these 4 pitfalls, effectively adopting a few agile best practices, help you to transform what you're doing at the moment and transform how you develop applications going forward. So it's all actually how to, how to get even more out of low-code. Low-code itself is something we're really passionate about and talking about a lot here in the podcast and on Clubhouse. But yeah, with those best practices and to avoid these pitfalls, you can optimize that even further and As a big outcome, when you apply these, these best practices, you will streamline development with tight and agile teams. You will really define how— define the right problems and really get a deep understanding of your users and make it as easy as possible to collaborate with business users. And it will help you to sort of ensure successful application applications that are really adopted and loved. That's, that's really the key thing. Otherwise your return of investment is, yeah, it's not there. And this is what we usually talk, talk in the beginning of those projects with business people and stakeholders. What is the return of investment? And to actually make that happen, you need to have these applications going live and being used. And yeah, and then really extend the use of low-code within the whole organization.

Yeah, exactly. And I think, you know, it doesn't matter if you're just getting started with low-code and you're new with it, or low-code, you know, you're already on the journey and you're in a process of scaling it across your organization. If you adopt these sort of few best practices and avoid some of the pitfalls, you know, you can truly transform long delivery timescales and sort of just delivering okay applications into very rapid development outcomes that delivers outstanding results. So, you know, so I think, you know, you want to be in that place where the results are driven by the input from all of the stakeholders involved. Do so by means of collaborating with the business users, you know, and ensure that the applications feel great, they work, and, you know, they solve the problems and continue to build them, you know, continue to evolve it into something better. You know, don't feel pressured or pressurized to, you know, implement something too big. I think understand what would be a meaningful initial build, what would make a difference, and then really just build on top of that, you know, get wider feedback, bring more features in. And I think, you know, once you've got that culture with inside a business, you know, you set yourself up for some really you know, good opportunities to deploy these applications that makes a big difference to people's lives.

Yeah, so it's applications maybe also in the wider sense, isn't it? So we would speak as well about not just low-code apps. Low-code could also be low-code robotic process automation, it could be low-code chatbots.

Absolutely.

So everything low-code these days and everything what we talk here on this podcast, intelligent automation. Everything is really around low-code and as well no-code, most of it really. And all the best practices we talked about today applies there as well, not just for low-code apps. So yeah, and then if you're interested to hear more about low-code and other areas of intelligent automation, yeah, listen, listen to our other episodes. We, we have done a couple, um, on, on all these important pillars already. So, uh, yeah, it would be great if you, yeah, can just, um, yeah, listen to them as well, and they will be very helpful. Um, lots of tips already. And, um, yeah, I guess, um, if you, yeah, if you like to, to get started with low-code or like to have more information on low-code, I know everyone is invited to, to get in touch with us, right?

Yeah, absolutely. And thanks to all our loyal listeners, everybody that listens to the podcast. Thanks for all the suggestions. We've had a tremendous sort of following in August, which, which, which is very encouraging to see. So we, we appreciate everybody that tunes into the podcast. We are looking forward to, to cover more topics, of course. So keep the suggestions coming in. If there's anything you wish to discuss with, with either Sasha or myself, you want to get started with a low-code project, you want to get started with automation project, you don't know where to, to start, or perhaps you might have an existing project that's in flight and you want to hear more as to different approaches and use some of our experience to shape the project, you know, please feel free to get in touch with us, either Sascha and myself, via the automationguides.net website link. And, you know, we're more than happy to continue the conversation with yourselves and, you know, and to help people out there to, you know, to get to their automation success goals that that they might have for this year and beyond as well.

Great. Yeah. Thank you very much, everyone. Thanks for listening and let's automate it. Unfortunately, that's it again with this episode of the Process and Automation Podcast. If you like this episode, please give us a 5-star rating And don't forget to subscribe to this podcast so you don't miss any upcoming episode. We hope you will tune in next time. And until then, let's automate it.