Low-code appeals to customers thanks to its incredible development speed and ease-of-use. But, what does low-code project delivery actually look like?
As early adopters of low-code, we’ve matured our agile process gained from those early experiences to realise all the benefits of low-code. This process has evolved over time and allows us to deliver the expected level of protective governance and control in our low-code projects – much like we would normally deliver alongside traditional development.
In simple terms, we have taken the key controls that we need from agile, adapted our team’s composition to support rapid development, and increased the openness of channels for feedback and communication. This has effectively created a streamlined low-code development process based on experience which can be adapted according to the project size, complexity, and requirements.
Ideal Team Composition
Our experience has led to a change in the way we compose our teams for both large and small projects for low-code deliveries. We know that development of low-code is quick, but this alone does not ensure a quick delivery even for low-code projects. We all know that delivery of quality assured, supportable, robust, fit-for-purpose solutions takes more than just developers. Part of the trick is to have the right ratio of people carrying out the right tasks in a project team at any one time.
A slightly unusual and perhaps controversial choice we have found to be considerably successful is to have a lower ratio of developers to other roles such as Business Analysts (BA) and testers than you would ordinarily use for traditional development. If we think about this on a basic level, this is just about ensuring one low-code developer's productivity levels (which, as we know, are considerably higher than a traditional developer’s) have sufficient assistance from other roles to support them. As simple as this sounds, this is often overlooked in the early stages of low-code development.
We think very carefully about all these roles, and the resourcing of them from our colleagues. The versatility of skills that our developers have can be key here and, depending on the type of project, assigning our colleagues according to their versatile skills can be a real game changer.
The role of the BA is especially important, and their maintenance of the backlog needs to be meticulous and continuous. Communication and refinement should take place daily with the Product Owner to keep up with the demands of the fast-moving project to allow for a good stock of small well-defined stories with acceptance criteria. We’ve found that a higher ratio of BAs to developers (compared to the ratio within traditional development teams) works quite well. Business Analysts prevent developers and testers from being placed on the bench, or worse, from stories being started without being well-defined, leading to rework or the wrong definition of done.
It is often the case that Technical Architects are brought into low-code projects when the going gets tough or a technical issue is stumbled upon. We’ve found that having a Technical Architect attached to the project team from the start gives the project a higher level of confidence from the outstep to succeed on time and on budget. The Technical Architect, with their high level of technical maturity, contributes to the project by taking hold of the unknowns and identifying dependencies early on. These dependencies may include data, systems, third party services (i.e. ones for security and hosting) and can be managed and communicated according to their assessed risk impacts. This proactive management gives direction to the team and allows building blocks to be in place for the developers before they need them. Working on dependencies earlier on reduces the time spent on workarounds such as Mock API data feeds, or rework after additions later in the project such as security, etc.
You may also consider, as we have done, establishing a role of the “low-code developer architect”, either by upskilling very technical low-code developers or allowing our existing Technical Architects the opportunity to specialise directly with low-code platforms. We encourage both paths of learning, and we find our projects are rewarded just as much as our colleagues are with their new challenges.
We believe our enhanced team composition allows our developers (and testers) to run at the low-code “accelerated pace” through support of the Business Analysts’ strong hold of the backlog and the technical scaffolding provided by the Technical Architect.
Where we have smaller projects that require less team members, we still don’t scrimp on the roles we feel necessary for a low-code team. Sometimes this means that a team member may need to wear multiple hats, and this can work well where some multi-talented developers are mature, skilled in Business Analysis and comfortable and organised by splitting their work across several roles. We also find that our low-code developing Architects really help bridge the gap in these smaller projects. You will note this really just refers back to the versatility of skills that we were discussing earlier.
Adapting Agile to Low-Code
As in typical agile projects, we also engage and complete sprints during our low-code process. These sprints are probably shorter than normal, taking 1-2 weeks on average. This is due to the speed of the delivery of functionalities, but it’s important to note that this is no less than what is recommended by low-code advocators. These frequent sprints allow customers to see their applications taking shape quickly as well as keep them engaged, excited, and in control of the delivery process.
At Objectivity, we emphasise the importance of having a well-structured team, within which there are various roles. For instance, it’s quite important for us to have a dedicated, active, and knowledgeable Project Owner assigned to the project on the client side who can take responsibility and make decisions on behalf of the project. This is especially critical for us because of the frequency of delivery and because of our open, continuous communication channels, which call for decisions to be made quickly. Although this may seem scary at first, especially to our Product Owner and stakeholders, our customers have actually found this approach to be extremely beneficial not least by finding smaller frequent collaboration more manageable than infrequent lengthy meetings. Our open collaboration channels lead to functionalities, stories, and issues being generated in smaller manageable chunks and allow our customers to more easily focus on individual topics and functionalities. We’ve also found that this positively correlates to higher levels of user satisfaction of the end product.
As we’ve already mentioned, low-code development moves along quickly, with refinements being carried out according to the sprints we have. In certain circumstances we’ve increased efficiency by implementing triangle meetings to support mini-refinements for more complicated user stories.
These triangle meetings take place between the BA, developer, and tester who will be assigned to developing and testing the story, respectively. It gives a chance for detailed workflows, requirements, and acceptance criteria to be fully understood by all parties. This ultimately reduces the risk of misunderstandings as it often unearths different questions and impact scenarios which haven’t been raised before and can be answered before the work is started.
When moving from traditional development to a low-code toolset, it can be easy for overeager teams to allow their developers to race ahead at great speed without the support of experienced Business Analysts, Software Testers, and Technical Architects. Having this type of support is quite valuable in terms of making sure that the project is ideally tailored to business needs and requirements.
Low-code development is an adventure and, as we already suggested, it’s easy to get excited and rush ahead. We’ve found that speed doesn’t have to compromise quality, but you must put in place certain rigid controls and procedures from the outset. Time invested in these procedures quickly becomes second nature and the benefits far outweigh any initial inconveniences. In fact, we find that our developers feel that they learn and share more and feel ownership of the whole code by embracing a few simple procedures.
We insist on peer code reviews and empower our developers to actively share knowledge of the applications they work on. We regularly hold project level developer-only retrospective sessions to cover niche technical areas or recent user story implementations. We have coding standards that are well-defined and understood for all our low-code platforms, which can be tailored to a given a project at the beginning. We have a lead developer for each project who ensures the right decisions are being made in line with the low-code toolset on the project. Decisions are discussed and communicated to the team alongside the Technical Architect, so queries and objections can be raised, leading to the very best solution. Continuous learning is encouraged, and juniors are mentored every step of the way. Having a dedicated developer project chat channel increases productivity by allowing developers to easily bounce ideas and ask for code reviews.
We’ve learnt the need for good preparation, control, and quality to safeguard the whole build including future enhancements. We devote time to ensure branching strategies are clearly defined for development and an appropriate process for an automated build and deployment as part of our DevOps is established.
It’s vital for these robust strategies and procedures to be in place to support the speed of sprint deliveries and the added feedback that these deliveries bring. Without these, we would miss key opportunities to be agile with the business objectives – which additionally helps keep the stakeholders engaged and interested.
Reflecting on the points above, you may yourself recognise our BizDevOps movement into low-code processes as something worth adopting within your business as well. In line with this movement, our business stakeholders are closely aligned throughout our DevOps process. This has been achieved by the combination of our agile adaption, project team roles, collaboration and open channels of communication at all steps, and through our implementation of a robust DevOps strategy built to support the fast pace of low-code development.
Our journey has been a challenge at times, but one with infinite rewards not least to say we have a BizDevOps process model that can be adapted easily for each project we undertake. We encourage you to adapt your own teams and agile approach, whilst holding onto the underlying importance of control and communication.
We wish you well on your adventures with low-code and hope that some of our tricks and experience will help you enhance the delivery of your own low-code projects. If you’d like to learn more about low-code development, visit our website.
About the Author
Sharon Smith Rapid Application Developer As a long-standing employee at Objectivity, Sharon has held various roles during her 24-year tenure. She is a highly analytical team player who has gained multiple skills from working in traditional development, support teams, and business analysis. She currently works in the rapid application practice as an Advanced Mendix Developer where she can use both her technical and customer facing skills to benefit the agile teams we have on low-code projects.
For more information, download Objectivity’s latest white paper on low-code: “Gain more by doing less”.