Circular breathing is basically breathing while continually playing your instrument. You have to breath air in through your nose while sustaining a note. If you want to try it but don't have a wind instrument handy then the next time you're at lunch try blowing through a straw into your drink while breathing air through your nose...it's not easy and it takes some practice. Agile development teams typically get some time to check and adjust, but not much time - maybe a day every few weeks. Teams have to keep evolving the software products they're working on as new requirements come in. Agile teams also have to continually improve their process as they're building and delivering software. Many business partners don't allow their teams to stop and take a breath, they're expected to keep on sustaining or improving their development pace without pauses or breaks in delivery. To accommodate this teams need to learn to circular breath their development processes.
At this point you may be saying - no way, we're supposed to get a tech debt sprint every once in a while, or maybe you expect your sponsor to understand that you've built buggy software on their dime and you need time to go back and fix it. Right, that doesn't sell so well. Even if you are able to sell it why would you? With CI/CD tools available today you should be able to deliver fewer bugs and more features with calculated tech debt ratios that balance time to market over flawless code. Or maybe you can slice off some functionality from your legacy app and deliver it with faster, more CD based methodologies. If you keep a constant eye on agreed upon metrics you should be able to check and adjust immediately instead of having to pause and take a week go back and fix any messes you made. Here are some ways that I like to manage this into my agile projects.
My favorite code quality tool is SonarQube. If you're running SonarQube you should have a good idea of how much tech debt you're accruing while writing and delivering code. I like to run SonarQube in the path to production so there is always a clear picture of how much debt we're running up along with delivery. Depending on the estimated longevity of the code we're working on we can make some compromises with quality at times. For example if we're building something for an ad campaign that will last for a few months, we're likely to allow more bugs than key components of our e-commerce site. If you have been able to convince your stakeholders to stop every once in a while and fix stuff then running SonarQube nightly and reacting based on trends works pretty well. However I prefer to run it on every production ready candidate. If bugs come up that don't meet the threshold fix them before merging/deploying your updates. When you incorporate this into your development process your estimates will end up including the time to fix these issues and your velocity and estimates will end up including more quality. If you don't like SonarQube then at least pick out some other static analysis tools that you can run on your code in your CI process.
As I talk about in my book, Agile Metrics In Action there are numerous agile metrics you can track continuously to keep an eye on your team health. Recently I've been working a lot with teams that are adopting more automation, moving toward continuous delivery, and striving for continuous deployments. In that context one metric we've been very focused on is number of deploys over environment type. For example, a team with 10x more deploys in their test environment than their production environment is usually not managing their changes in a way that can be deployed without disrupting the consumer and usually needs better tools for local testing or more sophisticated pipeline testing. When I start to see that trend it usually means it's time to dive in and figure out what that team needs to get to their goals. In the spirit of circular breathing I like to work with the team to identify the root of the problem, then add a story or two every sprint to address it. As with the previous example these adjustments end up averaging into velocity and your continuous delivery cycle. For this particular metric we end up shipping Jenkins (used for building/testing/deploying) data into Elasticsearch so we can report on it through Kibana. You can usually do the same thing with whatever data speaks to the problem you're trying to solve.
So the next time you're listening to your favorite didgeridoo piece or drinking with a straw, think about how you incorporate continuous metrics into your agile development cycle for better and more consistent delivery. You'll find that if you can incorporate these quality and process metrics into your development cycle and work through them as with any other change you make to your software you'll be able to sustain your pace and keep your sponsors happy.
