You know the story. You worry about technical debt but it seems so abstract. Your organization is following an agile methodology but there are a few steps you tend to skip repeatedly (e.g. mostly testing). Your development team assures you that they can’t make their sprint deadline if they have to write unit tests or fix the ones that break – if they even have any unit tests. You give in hoping that the next release goes better than that last one.
You’ve heard of companies successfully releasing product updates every week, but your lucky to release once a quarter. Then after each release you spend weeks fixing errors your introduced into production. You’re convinced that agile will work but your not seeing that types of returns other companies are claiming to get from their agile methodology. What is missing?
If the above scenario sounds like your organization you may be the victim of too much technical debt. How can you tell if you have technical debt? What exactly is technical debt? Some technical debt is unavoidable and even necessary but how much is too much?
Here are some warning signs that you may have technical debt:
- Inability to adequately test your application or services before each release.
- You only have manual tests and testing takes longer after every iteration.
- You replicate your production data into your testing environment. You know its bad but your development team tells you it’s the only way to really be sure it works in production.
- You have to patch production frequently after each release as a new deployment is too risky and the next release is months away.
- Small code defects consistently create major production problems for operations.
- The blame game: Developers frequently blame others for errors and then try to resolve the problem by restricting the number of changes in the code base.
- “Brent” syndrome (from The Phoenix Project): The organization is dependent on one key (and often very helpful) individual that is a critical bottleneck. The organization cannot move faster by increasing resources as “Brent” is the only one that understands the code base.
If your looking to reduce your technical debt while improving your agile the following SLC DevOps Days presentations and workshop will help:
- DevOps Theory vs Practice: A Song of Ice and Tire Fire – Baruch Sadogursky, JFrog
- Creating Capacity to Make Tomorrow Better Than Today – Damon Edward, Co-Founder Rundeck
- Testing in DevOps Era – A change in Mindset and Skillset – Biswajit Das, Automation Architect
- Continuous Delivery was never about faster – Ken Mugrage, Thoughtworks
May 14th and 15th, Noahs Event Center
Sign up now! Early Bird tix are all gone and tickets going fast!
