May 13, 2022

Using Iterative Development to Release Protection Rules

Lawrence Chang
JP Kadarkarai
Saurav Sarkar
Using Iterative Development to Release Protection Rules


Like many startups, the engineers at Clumio work relentlessly to design, develop, and innovate new and improved features to enhance our customers’ experience. While projects are developed under careful planning including capturing of requirements, writing a design doc, and other typical activities associated with software development, there can be no substitute for a good feedback loop. Such was the case with the development of Protection Rules, a recently released feature that helps customers protect data according to a set of priorities and conditions, aka rules.

When development of Protection Rules began, the engineering team set out to align its approach towards iterative development with an emphasis on garnering feedback rather than try to imagine and develop what may or may not have been a complete solution from the start. In software development, the latter approach is typically known as the waterfall method while the former can be associated with rapid application development, a version of Agile that focuses on rapid prototyping and adaptive processes.

Iterative Development

With the approach set, the team had a mantra during development: focus on the minimum viable product (MVP) that allowed for feedback rather than design for every obscure detail. As such, the first goal was to get a single Rule working. A Rule could be thought of as a basic set of conditions and an action to take when such conditions were satisfied (e.g. “if this, then that”). In the case of Protection Rules, the conditions helped narrow down to a set of assets to protect while the action was to apply a policy to them. Even though at one point the UI allowed for the creation of multiple Rules, rather than add more development time and delay the release, the team chose to focus on getting the code for one Rule right. Even with a single Rule, the engineering team could demonstrate to PMs and UX how the experience of creating a Rule would feel. Moreover, the fixed focus allowed for a tighter feedback loop between development and test. Validation suites could now focus on testing depth rather than simple breadth and any blockers or suggestions from test engineers could be addressed in subsequent stand-ups and sprints.

With feedback from the first milestone in-hand, the team set out to work on the next phase of development: allowing for the creation and prioritization of multiple Rules. While the UX team got direct feedback on how numerous Rules could be visualized and prioritized over one another, the Engineering team worked closely with UX to rapidly develop this mechanism. Once the team was ready for feedback, a demo was given to the broader Sales Engineering and Customer Success teams. Furthermore, Clumio’s cloud-native, continuous deployment platform allowed the team to leverage feature flags to continuously release Rules into production. Now the field could try out Rules at their own leisure, provide additional feedback, and showcase to customers upon request.

Within a matter of days, two immediate points of feedback became clear. First, since Rules had the potential to impact a large number of assets, previewing what assets could be affected was critical for customers to know up-front. Second, while the creation of Rules made protection of a collection of assets quick and easy, allowing for and prioritizing direct protection of a single asset was equally important. In other words, in some cases customers wanted the ability to override multiple Rules for an asset with a specific, targeted protection. While these two features had always been discussed, their priorities were now clear. Moreover, given the learnings from previous milestones, the engineering team was also in a better position to make recommendations on the UX as to how previews and direct protection could work. The team’s prior focus on an MVP even allowed for a change to the database schema that better aligned with updated requirements from feedback. In short, the team iterated across several phases of development, gathering feedback along the way from multiple stakeholders, to ensure that development for previews and direct protection matched expectations.

By this point, Protection Rules had started to be showcased to customers. Feedback from the field was trickling in and as such our last milestone, which was to integrate support for Organizational Units (OUs), started to take shape. OUs represent business units within an organization and in particular, customers wanted an easy way to understand which OUs had Rules and which did not. After several UX reviews, the engineering teams moved quickly to develop the solution and conduct an additional demo session with stakeholders including now the documentation team as Protection Rules was preparing for wide-release.


While Protection Rules are in production, iterative development is an ongoing process. The team continues to optimize Rules based on feedback while also thinking about new and innovative ways where Rules may apply. For example, prioritizing backups based on conditions, aggregating assets to create reports, and other such use cases outside data protection.

Oftentimes our CEO Poojan Kumar has highlighted Clumio’s ability to deliver features at a rapid pace and leverage our cloud-native architecture such that customers visiting the Clumio UI “one fine day” are delighted to see something new and important show up. Iterative development and adaptive processes are one of many ways in which engineering at Clumio is looking to move fast but be grounded in real-world feedback. As Clumio continues to push the pace for data-protection in the cloud, we’re all looking forward to many more “fine days” ahead.

This post was originally published on Clumio Engineering on Medium. Subscribe to our blog for exclusive content from our engineering team.