5 tips for high-quality app delivery at DevOps speed
I like to think of agile software development as a Formula 1 race. Just as drivers make pit stops throughout the 300 km race to make adjustments based on measurements gathered from the 120+ sensors in their vehicle, software professionals perform sprint planning activities based on information from the previous sprint.
DevOps is more like drag racing, though—it’s over in less than four seconds. In this fast-paced DevOps environment, there's no time to act on the metrics that have been gathered during the race. Metrics are still relevant, but how we use them has changed considerably over the past 10 years.
We used to mark feature and user story quality as green (good), yellow (meh), or red (bad). And we used to track metrics such as test coverage, number of defects detected, and regression ratios. But as we got more experienced with agile, we had a big epiphany: A user story has only two meaningful statuses, "done" or "not done." If it’s "done," it’s really complete. The notion that a user story can be "done, but with a few defects" is ill-conceived. Statements like: "Yeah, it’s done for the moment. There are a few things we’ll need to fix later though," were abolished from our team discussions.
If a user story is "done," we mean that it’s ready for release. A "not done" status means that it’s not ready for release for any number of reasons. Perhaps we haven’t started development yet; or it’s been fully tested, but one small defect remains to be fixed. In other words, there is no longer any gray area between our "done" and "not done" states. A story is either ready for release, or it's not.
Here are five tips to help you move fast and still achieve top-quality software delivery.
1. Define a good, robust development framework
Configure all of your processes and methodologies in advance, and make sure they are all aimed to produce a quality product. All stakeholders need to realize that the only way to move quickly and release with confidence is to follow a strict set of project guidelines that define how to develop, test, monitor, and deliver, and what actions to take in case of failures along the way.
2. Define and track the ‘done’ criteria
The "done" criteria must be unambiguously defined, and the development and testing framework must be configured to gather metrics automatically as the user story makes its way to the finish line. If "done" is well defined, and the criteria are being tracked, you’ll know when you’ve reached the finish line because the story will really be done, not because some metric or statistic says that it is.
3. Have reliable warning lights
Most of us are not drag racers. But we do understand a few things about the everyday vehicles we operate, and we know when they need some attention. When your engine is overheating and the check engine warning light turns on, you’d better pull over or risk irreversible damage to the vehicle. The software development equivalent of this warning light is a wide range of automated tests. When tests fail and the build is red, you must stop and check the problem. Ignoring it won’t make the light go away, and you risk major damage to your product.
The fuel gauge tells you how much further you can go. The parallel in software development is story point capacity. If you are low on story point capacity for the sprint, consider cutting content so you can reach the finish line with enough "done" user stories to make the sprint meaningful.
4. Gather enough data to learn and improve
Though it may be impossible to act on metrics until the next sprint, gathering as much data as possible is critical for the success and continuous improvement of modern software teams. We need to take advantage of this world of big data, in which we analyze every piece of information possible to fine tune our planning, estimation, execution, test coverage, and more. Nourishing a culture of retrospection and improvements based on data is possibly the most important factor in delivering quality results.
5. Study the entire race track
It’s not enough for a race driver to look only at the few meters of road ahead. The driver must continuously look much farther down the road and prepare in advance for curves, speed bumps, potholes, and other conditions that require adjustments. In software development, it is similarly necessary to consider the quality of the complete feature or epic, and not just individual user stories.
Here's a common problem in agile projects: Each of the small user stories work fine, but the feature itself isn’t complete, or it's inconsistent. Make sure that some people one your team keep an eye on features and cross-system business flows, and that they work alongside the developers and testers who are mainly focused on user stories. This broader outlook ensures that the collection of user stories comprises a coherent and valuable product.
This is also true for cross-product quality: Sometimes a user story will have a defect that you decide is not important enough to fix. And that’s OK. But when all of your user stories have these "insignificant" defects, they can collectively render the product unusable. This is one of the reasons early customer feedback and constant validation rounds are critical to delivering the right product.
The next starting line
Drag race drivers don’t have time to analyze metrics during the race. Their car is set up at the starting line based on metrics gathered from previous races—not the current one. As soon as the race begins, they push as hard as they can till they reach the finish line.
In software development, the development and testing framework is configured to gather data automatically as the user story makes its way to the finish line. If you can trust your framework, you’ll know when you’ve reached the finish line because the story will be done and you can analyze the data later to see where and how you can improve next time. You can have speed now, and improve quality from one sprint to the next.
Not much can be done except pour on the gas during a four-second race. But if you’ve defined your done criteria, and set up your development system to collect the data to monitor them as the software speeds its way through the pipeline, you’ll know what the status is at any given moment in time. And just as important, you’ll have the information to improve performance and get your next sprint in even better shape as it comes to the starting line.
Image source: Flickr