Every agile software engineering team wants to do these three things:
- Accelerate feature development
- Improve feature quality
- Release features often
The reality is that as we focus on improving one thing, sometimes it is at the expense of another. If we focus on accelerating feature development, feature quality could suffer. If we focus on improving feature quality, development could slow, potentially delaying the release. But what if we could have it all?
I’ve been a developer on the Workforce Safety solution since last May. Appian began developing Workforce Safety as a way to help our customers operate safely and effectively throughout the COVID-19 crisis. I knew from the start that the team would need to build quality features as quickly as possible, but I didn’t realize how quickly. Shortly after I joined the team, I learned our objective was to release new versions of the solution with robust, high priority features on a monthly basis. This accelerated release cadence forced us to rethink our processes. We needed an approach that would allow us to build multiple full-fledged features and adhere to our quality standards in a shorter timeframe than we had ever attempted.
It took us some time to figure out what methods worked best to meet our ambitious objective. The method that I believe made the biggest impact was the feature design process. This process involves working as a team on a high-level technical design document before diving into actual development. The document is informal and collaborative; we discuss everything we know about the feature and write down ideas, questions, and development plans for all major requirements. Once the important technical decisions have been captured and the whole team is aligned, the building can begin.
A comprehensive feature design doesn’t have to follow an exact template, but it should answer four important questions:
What data changes do we need?
- Identify new tables that need to be created, or new columns that need to be added to existing tables.
- Determine what columns need to be indexed.
- Decide if views are needed. If so, design a view definition that will perform well in high loads.
- Ensure that the chosen data structures take both data capture and data querying into account.
- Determine if new reference data is required, how it will be stored, and where it will be stored.
What queries and business rules do we need?
- Identify new queries that need to be created, and existing queries that can be reused.
- Plan the query designs to include necessary aggregations and filters.
- Determine an appropriate batch size for each query.
- Flesh out logic for complex business rules, and design each rule to be reusable in all areas of the application that rely on the business rule logic.
What workflows do we need?
- Outline new workflows and consider the order in which the activities should occur.
- Identify any existing workflows that can be reused.
- Think about the expected load on this workflow. Design the workflow and its iterations in such a way that it will perform well in the maximum expected load.
- Consider possible race conditions, and choose a workflow that prevents them.
What UX do we need?
- Prepare detailed mockups for new UX.
- Consider making UX reusable throughout the feature when possible.
- Get feedback on the mockups from UX experts.
- Get feedback on the mockups from the development team to ensure all possible scenarios are accounted for in the mockups.
The entire development team is involved in this process on the Workforce Safety project - outlining plans, making suggestions, asking questions, creating test objects, etc. This collaboration strengthens team alignment and makes us even more prepared to begin building. During development, we are able to write code in a way that meets the requirements at both the story level and the feature level.
Since we started using the feature design process, I’ve noticed an enormous improvement in our quality and our velocity. We build more and more every sprint, with tickets rarely bouncing back due to bugs or missing requirements. On top of that, we find fewer regression bugs every release, because we take the time during the feature design to fully analyze how the new functionality will merge with the existing functionality harmoniously.
So it turns out you actually can have it all. Or at least get close to it. With rapid feature development and excellent feature quality, regular releases (even monthly releases!) are much more achievable. The feature design process takes practice. But if you’re willing to invest in it, it’s a great way for your team to start building your software faster and better.
