How creating an Appian solution is just like building a robot
Every January, high school students around the world eagerly await a livestream from New Hampshire announcing the FIRST Robotics Challenge. FIRST taps into the excitement of sports to present a game that changes each year to inspire the next generation of science, technology, engineering, and math professionals.
Industrial sized robots are built in a six week time frame to accomplish the game’s task in the most efficient way possible. I have been involved with this organization for 15 years, first as a student (pictured above) and now as a volunteer. Through my involvement, I have noticed that the process to build a FIRST robot is very similar to how an Appian consultant would go about creating a software solution for one of our clients.
Understanding the problem: Immediately upon receiving the game challenge, students get to work deconstructing the problem. They pour over the 100+ page game manual to understand every nuance, they rewatch the announcement 10 times to make sure no detail was missed, and they flock to the robotics message boards to see what their peers are discussing. Analysis is conducted on the most advantageous way to score points and diagrams of the field are drawn to understand sizing considerations.
At Appian, we begin with either a discovery phase (if time allows) or a sprint zero to understand a client’s business problem. We conduct process analysis to map existing operational flows, develop personas to understand potential users, and identify major impediments our clients face.
Formulating a strategy: With a solid understanding, students get to work brainstorming their game strategy. They create prototypes to rapidly test proof of concepts and sketch out rough ideas. Often, teams look to past competitions for inspiration to see what features made previous robots successful. The overall strategy for what tasks to accomplish are discussed and decided upon as a team.
Appian teams perform similar actions once the problem is identified. We create story maps that show how the process can be streamlined, we draw mockups to generate a design of the solution, and we start to assign loose priorities to functional areas to determine key features. We leverage past experience, existing work, and our low-code platform to identify ways in which we can accelerate the development process.
Documenting requirements: Robots are either sketched out by hand or designed in CAD, depending on the team’s capabilities. Tasks are created to address the different features (arm, electrical, drive, etc.) and a build schedule is established. The designs are reviewed by the team to ensure outstanding questions are answered. As the team builds and tests the robot, the design may be modified for improvements.
At Appian, we document our requirements as stories following Agile methodologies. Stories are created in a grooming process to determine their acceptance criteria and dependencies. The stories are rolled up into larger features and a release plan is made.
Building the solution: Once all the analysis has been formalized and agreed upon, it’s time to get to work fabricating the robot. This is a complex process with many moving parts where teams need to coordinate their efforts to ensure the subteams have no dependencies and that integration of the systems is possible. The progress of the robot must be tracked closely and any impediments are escalated. In addition to physical construction, software must be written to control the robot in both an autonomous and teleoperated condition.
The Appian team goes through a similar process where we are working on a tight time frame with potentially many people to deliver a product that may have numerous dependencies and system integrations. We use Agile tools and practices to monitor our progress, track that our sprint commitments are being met, and that our velocity is accurate. We write our code to work in a variety of environments and handle a multitude of scenarios.
Testing thoroughly: Throughout the building process, the robot’s mechanisms are incrementally tested. As a result of the testing, there may need to be modifications made or entirely new approaches created. The robot is tested in different scenarios to ensure that it is ready for the competition. Additionally, it is essential that software bugs be discovered and resolved prior to the competition so that the team can perform with a minimum debugging effort.
As the Appian team develops, we perform many levels of testing. This can include: unit testing, peer reviews, smoke testing, functional testing, automated testing, user acceptance testing, performance testing, and more. As the team finds defects, priorities are assigned to them in order to assess their work order. The goal is to catch all of the bugs in the development and test environments, before the application goes live.
Deploying the product: At the end of the six weeks, the robot is “bagged” and there can be no more work performed on it. The next time the teams see their robot will be at the competition. Hopefully all hardware and software issues have been resolved before this point so the team can focus on operating the robot by the time the competition starts.
At the end of our development process, which can be as short as an Appian Guaranteed project of eight weeks, we deploy the application to the production environment. From here, the system is live and users are focused on leveraging it to improve their operations.
Iterative Improvements: Although the robot has been completed, teams are able to make changes to them at the competition as things break or can be slightly improved. Teams take note of how other students approached the problem at the competition and they reflect on how they can improve for next year. Appian teams may continue working on an application if there is an additional workstream or production support. Enhancements are prioritized to improve the system. Teams perform retrospectives in order to improve their internal dynamics moving forward.
Building a robot is very similar to creating an Appian solution. There is a logical order of steps to follow, they are both built in a tight time frame, and at the end of both processes, there is a working product that must produce results. It is impressive what FIRST students are able to accomplish in six weeks. Just like how there is excitement with building a robot for a competition, I find it thrilling to have a robust working custom software solution in as little as eight weeks.
