#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, Sascha, 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 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 is 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 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 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, Sascha, collaboratively, where there's open discussions on the next feature that's been worked on, how it work. 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 and, 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 that functional bridge, so that the requirements and solution can flow freely. And again, it makes collaboration very easy and it encourages very clear and frequent input from all of the stakeholders involved, which also, by the way, help you to test some certain assumptions perhaps that the developers has paid. 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, if you have this mindset of increased collaboration and sort of iterative development, you get very early buy-in from stakeholders, especially end users, 'cause they can see the system or the proposed solution that you're gonna 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 build to give the user something concrete to react to and to validate the design. And, you know, to— and also to, to make sure that the, the development team has got a, a very clear understanding of what's needed. And so again, I think the message is instead of having this, um, 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 have 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 that that feedback is quick, it's frequent, and of course it's not distorted. You know, 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? You know, 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 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, really everyone of that team and the end users sitting there. We're doing high intensity testing, feedback testing, smaller changes, 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 really, really deep commitment and confirmation from the business that this is really sort of 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.

But it is really, really helpful. Looking forward to this one. But yeah, this is pre-low-code and pre-agile. That was 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, you know, 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. And it was actually in, 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 day. 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, your sort of intense sessions as well. And it's just that, that final, that last mile of a project that you could still have changes to, to make a big, you know, impact towards the end of the project. And obviously this is a great enabler for that.

Yeah, I think that's very, very important, these feedback loops. And that's also one of the next, sort of our next pitfall. Traditionally, success was only sort of measured at go-live. So the spec was written and then at go-live people looked at it and say, okay, that's great or not great. 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 your end users throughout the whole development lifecycle. So you just mentioned, Anna, you mentioned that one shortly before go-live. But then, yeah, we will definitely have these sessions where we speak with end users throughout the whole development. Maybe it's an 8-week development cycle. So we have 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 feature a new function and give input and ask questions. So if that is the situation 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 a feature and function initially 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, where you actually 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 yeah, I think that's, that's key. So if you don't do that and wait just for, 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. 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 a system. But I think that 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 built the system with those people part of it and you could, like you say, crowdsource the feedback and 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, where kind of IT provides the opportunity then almost for end users to shine and take credit. And I think that's worth a lot, especially if people look at it and they use it, they feel like they were part of that success story, they shaped it, And, you know, I guess the end goal is for, you know, for the application to become 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, those, 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. Yeah, 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, um, 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 end product or the end result, you know, it is, it is sometimes so drastically different to how you imagined it to look. You know, when you look from it from a starting point, So, and I think that's important because the majority of the backlog that we see, and when I say backlog, I mean future requests and how people wanna shape the low-code application, that happens throughout the lifecycle of the project. It's not something that happens upfront. Everybody sits in a room for 5 days and we decide, this is our roadmap. Ultimate list of features we want to see in the application. So, um, so very powerful methodology, very powerful sort of way of doing things. And, uh, you know, like I say, it still gives you an opportunity at the 11th hour to, to make things better and still apply, um, changes or implement ideas to, to 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 to avoid these pitfalls, you can optimize that even further. And as a big outcome, when you apply 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 applications that are really adopted and loved. That's really the key thing. Otherwise, your return of investment is not there. And this is what we usually talk in the beginning of those projects with business people and stakeholders. What is the return of investment? To actually make that happen, you need to have these applications, um, going live and being used and, uh, and, and then really extend the use of low-code within the whole organization.

Yeah, exactly. And I think, you know, um, 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, you're already on the journey and you're in a process of scaling it across your organization. Um, 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 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 we talk here on this podcast, intelligent automation, everything is really around low-code and as well no-code, most of it really. And yeah, all that's all, all the best practices we talked about today applies there as well, not just for, 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 to our other episodes. We have done a couple on all these important pillars already. So yeah, it would be great if you can just listen to them as well, and they will be very helpful. Lots of tips already. And yeah, I guess if you, yeah, if you like to get started with low-code or like to have more information on low-code, I know everyone is invited 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 is very encouraging to see. So we appreciate everybody that tunes into the podcast. We are looking forward to cover more topics, of course. So keep the suggestions coming in. If there's anything you wish to discuss with either Sascha 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 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 Cutura or 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 get to their automation success goals 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.