Managing technical damage
Technical damage is a new term created and currently used exclusively by Swinlanes. It encompasses anything that harms a flawless user and developer experience. This includes bugs, unreadable or messy code, overengineering, broken patterns, implementation inconsistencies, and knowledge silos. Essentially, it refers to anything that hinders the team’s ability to deliver excellent software quickly and sustainably, without generating further technical damage.
The process of logging technical damage in Swinlanes is different from what you may be used to with a Kanban board. Typically, you’d create a bug ticket and place it in the current sprint or backlog for someone to pick up later. However, Swimlanes requires that all technical damage be logged against the specific feature iteration where it originated. This means an initial investigation by a developer is needed to identify when and where the bug was introduced. This linkage significantly reinforces code ownership, allowing everyone to see at all times how much technical damage a feature iteration has accumulated. Now, let’s add some technical damage.
Let’s imagine that Milana Kurnikova signed off on the development for the ‘Apple Pay’ feature iteration we submitted on the previous page, and Danil has started the QA process. He found several bugs and wants to add them to the iteration for Milana to fix.
In the screenshot above, you can see the first stage, Development, signed off (solid green), while QA has failed (solid yellow). Now, Danil, responsible for QA, clicks the red heart button to flip the iteration to the ‘dark side,’ indicating technical damage.
To flip it back, we would click the heart again, but since we want to add technical damage, we click ‘Log Technical Damage’ instead, which brings up the submission screen.
At the moment, we can only use text (screenshots and video are on the Swimlanes roadmap). Once we submit the technical damage, we’ll see it added.”
We can add new technical damage, mark it as completed, and if there are multiple active technical issues, we can use arrows to navigate through them one by one.
There’s another way to view all technical damages at once. If we flip the card back to the light side and click on it to open the feature view, we’ll see a new black lane called ‘Technical Damage.’ Clicking on this lane will display the full list of technical damages. Currently, Swinlanes only supports adding and completing technical damages; there’s no option to delete them or add them from the feature view, but this is on the Swinlanes roadmap.
The feature iteration in the Swimlanes view will also change. Instead of the red heart, a wrench icon will appear, displaying the number of active technical damages.
But what if a bug is found in a different feature iteration that has already been completed? Once the developer triaging the technical damage confirms its origin, they change all stages, including development, to yellow, indicating that these stages need to be redone. For example, if Danil finds a defect that originated in the first iteration of P2P Payments, which has already been shipped to production, he changes all the stages to yellow. The iteration then reappears in the Swimlanes view, showing up in the lanes of the developers who were involved in its development so they can fix it.
For the sake of workload distribution, it’s not strictly mandatory — but highly encouraged — for developers to fix the technical damage they caused. You can also assign another developer and make them the iteration lead instead to deal with the damage.
Another scenario is when you’ve just started using Swimlanes and a feature has not been created yet, but someone needs to log technical damage against that feature. In this case, you can simply create an empty feature and raise the technical damage against its Foundation iteration.
Last updated
