As an implementation engineer in the low-code software space, I have seen my fair share of projects ranging from small, easy-to-implement forms to more robust, complete custom app builds. Using a low-code platform like TrackVia allows for a fast, easy, and cost-effective way to help optimize processes and track data where spreadsheets and pen and paper lack. One of the things that makes low-code so powerful is how quickly you can iterate through the project lifecycle, provided you have the right tools in place. The length of the lifecycle for an application build really depends on four factors: developers, user stories (scope), decision makers, and testing/feedback.
Developers: Are more always better?
Depending on the project, you may have one or more citizen developers helping to build the application. Having one developer works well provided that person has the time to dedicate to the regular iterations you’ll go through during the project lifecycle. With only one developer you won’t need to worry about multiple developers stepping on each other’s toes and spending time on coordination efforts that could prolong the project. On the other hand, having multiple developers can work when processes are delineated, each developer focusing on his/her part. Any overlap should be discussed by those affected and a strategy should be put in place before any toe stepping occurs. Having been part of both solo and co-builds, I can say both have their place, but consider some of these factors when making your decision:
- Process dependencies
User Stories: Quantity or Quality?
This topic was covered rather extensively in a previous blog titled “The Importance of Good Requirements”. Although quality is more important than quantity, both are needed, and they complement each other. As your user stories get more detailed, you’ll realize you need more of them to call out all of the process variations that your application needs to accommodate. You might start by defining a generic process but realize that different roles will need different data entry fields or there’s a slight deviation in workflow and your initial user story quickly becomes two, three or even ten different user stories. As someone who builds apps on a daily basis, having this information in front of me allows for a much faster build and requires less back and forth with the decision makers. Key things to provide a foundation for your project:
- Get your user stories defined early
- Identify key milestones
- Ensure the user stories are vetted at a high level
- Determine how to resolve disagreements
Decision Maker: Provide a Single Point Person
It’s not uncommon to get on a call with a customer, ask a question, and get a variety of different answers from the “decision makers”. We’ve all heard the phrase “too many cooks in the kitchen” and that applies here. In order to keep the project moving in a timely fashion, having one dedicated decision maker is ideal. There may be multiple business users providing their input to the decision maker, but having one go-to person to provide an answer is key. Rather than a chain email going out to a group of people with varied responses coming back in, or a meeting where the whole time is consumed on one question with the back and forths between the business users, a primary point person can help manage these discussions offline and provide the solution succinctly and deliver one response. Many times a formal Project Manager can help facilitate decision making.
Testing & Feedback: The Backbone of Iteration
Probably the most important way to ensure quick and effective iterations, and one of the key features of a low-code platform is the ability to test immediately following a build. Having this ability and getting a subset of end users involved providing feedback can reap exponential rewards. We all know change can be one of the biggest hurdles to overcome in business, so why not get end user buy-in by allowing them to help test and provide feedback early and often? Not only will you catch errors, quickly fix them, retest and move on, but you will also find edge cases and be able to adjust as necessary. Exposing this new software to your end users in this manner will also help to ensure smooth user acceptance testing (UAT), as they’ll be familiar with how the technology works and how processes they’ve previously tested were designed.
To gain more insight into best practices around UAT, stay tuned for next month’s blog post titled “User Acceptance Testing Best Practices”.