Overcoming DevOps Cycle Challenges by Using Smaller Tasks, Getting Feedback Earlier

[#1]

Receiving and improving on feedback is one of the core practices in DevOps cycle. According to the State of DevOps report, companies with shorter feedback cycles are identified as higher performing. When you receive important feedback too late, you’re hit with all sorts of issues with deployment, production, and customer feedback.  By delivering smaller batches, you can get more focused feedback on a faster timeline. 

Here are a few tips for making the most of your feedback cycle:

Practice Smaller Tasks

Let’s practice creating smaller tasks with an example. We have an online store and envision this feature, so we create a task:

Clearance Sales:

If our inventory has old stock, automatically create clearance sales on our website.

Reduce the price depending on the age of the stock.

How can we split this up? A good guideline is INVEST:

• Independent: Make the task as self-contained as possible, with no dependency on another task.
• Negotiable: Leave space for discussion and changes after feedback.
• Valuable: Provide value to the stakeholders.
• Estimable: Be able roughly estimate its size. It shouldn’t be open-ended.
• Small: The task should ideally be able to be completed in hours or a few days.
• Testable: Provide the necessary information to make testing the task possible.

Given these guidelines, think about how the feature can be split up into tasks. Here is my attempt:

• Create a prototype. Emulate the feature manually by adding a hard-coded clearance sale on the website.
  Motivation: We can quickly see if customers are interested in the feature.
• A task to develop the database tables and queries to find the right items for a clearance sale. Hardcode the price reduction.
  Motivation: We can deploy this, ensuring the database changes do not cause issues in production. We also specified that the price reduction is initially hardcoded, reducing the task complexity.

• Provide REST endpoint for clearance sale.
  Motivation: We can deploy this and test it in production without customers using it.
• Create UI for clearance sale, hide behind feature flag.
  Motivation: We might enable it for our team and some customers
• Release feature for everyone.

By breaking it up into smaller batches of work, we can notice bugs in production and have a smaller change log to find where the issue could be.

Avoid Planning Too Far Ahead

If you create tasks for months to come all for a large feature, you lack the flexibility to pivot based on the feedback you receive along the way. Create only the tasks focused on your most immediate needs, otherwise you run the risk of wasting your time or backing yourself into a corner.

For example, after we deployed our prototype, we found that customers preferred an actual search filter over a single sale. When we updated the feature accordingly, we noticed a fixed price reduction was good enough, eliminating the need to develop a dynamic price reduction.

Another example is with the Apple M1 MacBook.  They took incremental steps towards it over the years, beginning with fat-binaries from Power-PC/Intel transition before progressing to using the ARM in the iPhone. From there they took small steps such as building their own chips and continuously improving them until they were able to be integrated into laptops.  Each step gave them an opportunity to gather feedback and improve their designs.

Summary

‘‘In the technology value stream, we often get poor outcomes because of the absence of fast feedback. When feedback is delayed and infrequent, it is too slow to enable us to prevent undesirable outcomes.’’ G.Kim, J.Humble, P.Debois, J. Willis. The DevOps Handbook. 

In software development we have the luxury that we can easily split up work into smaller tasks, completing these tasks and collecting feedback very early.