DevOps Blog

Here’s What You Need to Know


Tackling Technical Debt Blog Series

Part 3: Prioritizing Technical Debt (What to Fix First)

Welcome back to our blog series, “Tackling Technical Debt.” In Part 1, we discussed the different categories of technical debt you may encounter in various projects. We then covered a couple of scenarios that show taking on technical debt can be a strategic decision that helps the business in Part 2. In this third post, we will help you create a plan for tackling existing technical debt.

Over time, software development projects can accrue technical debt through intentional and unintentional choices. When teams intentionally choose technical debt, they make a plan to address it later when they have more time, more resources, or more funding. Unfortunately, these tasks are not always well tracked or get delayed for more urgent requests. The growing list of technical debt tasks becomes more daunting to resolve. How do development teams and business leader prioritize which technical debt to fix first? The answer lies in a modification of the time management matrix first popularized by President Eisenhower. .

What is the Eisenhower Matrix?

It’s a system for prioritizing tasks into four quadrants based on their urgency and importance:

Basic Eisenhower Matrix

Product Managers and software teams use a variation of this matrix by renaming the axes to “Value” and “Difficulty” to rank feature requests:

Basic Eisenhower Matrix diagram
                showing priority and difficulty axes

This same matrix is also useful for prioritizing technical debt by ranking each task by its value and level of effort to fix. This can be tracked in software, or your team can use a whiteboard and sticky notes to move tasks around.

Defining Value

Software teams can determine the value of fixing specific technical debts by asking these questions:

  • Is it critical to fix now because it is breaking the system? These will rank higher in value.
  • Is it a barrier to a business need like scalability or urgent feature requests? These will rank high in value but lower than the critical fixes.
  • Is it a nice-to-have or simply old technology but not tied to a business need? These will rank lower in value.


Ranking Difficulty

Most teams will already have a ballpark idea of how easy or difficult fixing specific technical debt, so use this axis to rank the effort of each task. These questions can help teams determine the difficulty:

  1. Is it limited to a specific class or function? These will be easier to solve.
  2. Is it limited to a specific application or owned by one team? These take a bit longer, but the payoff will make future changes easier to implement.
  3. Is it systemic across multiple applications, the architecture, or require buy-in and work from multiple project teams? These can be the most difficult to resolve but ignoring them for too long will turn them into critical issues.


The Path Forward

Move forward with execution after technical debt tasks are placed on the matrix. Critical tasks that are easy to fix will be done first, while very valuable fixes that are more difficult to do will be started but take longer to complete.

Basic Eisenhower Matrix diagram
                showing priority and difficulty axes with suggested scheduling blocks

Software teams might be able to solve items in the lower left quadrant (easier, less valuable) alongside a related feature update or when the urgent tasks are completed. Whenever your team encounters new technical debt, rank it against the existing debt to see if it’s more urgent or more valuable to fix. This continuous cycle will help software teams re-prioritize tasks as new information becomes available.

This is Part 3 in a series on Managing Technical Debt.


Tackling Technical Debt Blog Series

Part 2: Taking on Tactical Technical Debt

This is Part 2 in our blog series on Technical Debt, where we explore why and when DevOps teams should take on technical debt by choice.

Technical debt can be a result of unintentional actions (“sloppy coding”), acquired over time (aging systems that need to be replaced), or conscious decisions to meet business objectives. In all cases, the decision on whether to address technical debt now comes down to the balance between opportunity costs and business value. Let’s look at three scenarios where teams must decide between acquiring technical debt, delaying releases, or incurring additional costs.

Scenario 1: Shortening Time to Market

In this scenario, your organization wants to release a new application feature that customers want. Adding this feature now would help grow your company’s revenue by attracting new customers. You are worried your customers may switch vendors if your app appears to be lagging.

In an ideal timeline, your developers would create robust, reusable modules that could be used for future requests, but it will take an extra month to develop and test that code. Alternatively, they can create a feature-specific routine that can be coded and tested in one week. The difference between doing it “right” and doing it “quick and dirty” is four weeks, enough time that your competitor may beat you to market.

In this scenario, the right call may be to take on short term technical debt to get this release out the door, and then immediately start work on the reusable solution while your sales team is winning customers.

Be careful with this decision. Frequently, all feature requests appear to be critical when they’re not, and teams who do not methodically track technical debt with concrete plans to address it will find themselves spending more effort to update dirty code.

Scenario 2: Minimum Viable Product

Whether your DevOps team is a startup strapped for cash, or an enterprise testing the waters with a proof of concept, you’ll encounter scenarios where you don’t yet have funding to create the full product “the right way.”

Teams in this scenario may choose to take on technical debt in order to delay costs until the next round of funding is won. In this case, the immediate work is required to prove viability to the investors.

Keep track of the design trade-offs to avoid issues scaling your product later. Make a plan to address technical debt when that funding comes in.

Scenario 3: Unclear Business Direction

Technical teams should avoid taking on technical debt to meet unclear business objectives. While delivering a quick and dirty version might seem faster, it will take twice as long if your team misunderstood the requirements. Get clarification, then make an informed decision on prioritizing new work versus paying off technical debt.


The decision to take on technical debt should not be taken lightly. There are good cases for taking on technical debt, like Scenarios 1 and 2. Regardless of the reasons for taking on technical debt, it must still be repaid. Track and plan when your team will address it before the interest slows down future work.

This is Part 2 in a series on Managing Technical Debt.


Tackling Technical Debt Blog Series

Part I: Categorizing Technical Debt

Organizations and software development teams investing in DevOps culture and tools must take inventory of their current technical debt and how they plan to address future technical debt. Over time, software teams that do not effectively manage technical debt become burdened with slower software cycles and spend more time paying “interest” on the debt, just to keep the software working. This “interest” diverts resources away from implementing new features, makes it more difficult to automate builds and deployments, and reduces the benefits of adopting DevOps.

What is Technical Debt?

The term “technical debt” was coined to describe the costs of taking short-cuts or the “wrong” approach to create functional software in the short-term. In other words, it’s a design decision that is fast now but requires a fix or more support in the future. These short-term decisions result in code that is more difficult to read, modify, extend, or maintain in the future. While all technical debt has a cost, not all technical debt is bad. Let’s examine the different types of technical debt developers may encounter:

Acquired Technical Debt

When product managers and development teams take over an existing software system or project, they inherit all of the decisions made by the previous team. The current team may not have chosen to code or implement the same way or may have the benefit of knowledge that was not available to the original team. This type of technical debt is acquired technical debt.

Unintentional Technical Debt

The next category of technical debt arises from either honest mistakes or sloppy coding. An honest mistake could be building an app that cannot be easily updated to support a new unforeseen platform. Sloppy coding introduces technical debt because it introduces bugs and maintenance effort into the software development cycle. With unintentional technical debt, the development team does not make a conscious choice to take on debt.

Short-Term Technical Debt

Business leaders and development teams may consciously make decisions to take short-cuts or do things the “wrong” way in order to ship a product more quickly. In this situation, the benefits and costs of taking on technical debt should be part of the decision-making process, along with a clear plan on when to address the technical debt after release. This kind of intentional technical debt can be beneficial to organizations.

Long-Term Technical Debt

In other cases, development teams may choose to take on technical debt for strategic purposes by delaying developmental costs and efforts. One example is building an app that supports a single platform while planning to support additional platforms after the organization raises the next round of VC funding. Similar to short-term technical debt, document the reasons for incurring debt and when the team will address it.

Inventory Your Debt

It’s challenging to pay down technical debt that you don’t know you have, so if you choose to incur debt for short or long term strategic reasons, be sure to track it. If you take over an existing project with acquired debt, add the debt management tasks to your list of development activities.

Some organizations track technical debt in the product backlog, and some track them as defects. Regardless of how you choose to track technical debt, implementing code standards and automating both development and testing tasks can reduce the amount of unintentional debt you accumulate during future development.

This is Part I in a series on Managing Technical Debt.


How DevOps Implements Agile Principles

It’s important to note the difference between Agile methodology and specific implementations like Scrum. Agile’s 12 Principles are compatible with the DevOps approach to Software Development Life Cycles (SDLCs) and can be applied throughout the value stream. Scrum is focused inwardly on the development team and may need modification to include Ops teams. Let’s examine how DevOps enables Agile Principles:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Customer satisfaction implies quality software, which is a goal of DevOps through earlier involvement of Operations teams and continuous testing. DevOps also works to ensure continuous delivery.

“Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.” DevOps enables change though fast, iterative deployments.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.” DevOps uses automated testing, automated builds, and collaboration to achieve increasingly fast release cycles.

“Business people and developers must work together daily throughout the project.” An essential aspect of DevOps is breaking down silos to eliminate bottlenecks in the value stream and increase collaboration between teams. Although Agile originally focused on closing the gap between product owners and development teams, DevOps extends that collaborative culture to include operations, InfoSec, and other stakeholders.

“Working software is the primary measure of progress.” DevOps balances shorter release cycles with quality control. Through automation and earlier testing, errors are caught earlier and corrected quickly.

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” The fast pace of DevOps may appear unsustainable from the outside and would be if it required manual processes for each step. Instead, DevOps attempts to automate as much of the build, test and deploy processes as possible. Automation allows the teams to focus on their work without burnout.

“Continuous attention to technical excellence and good design enhances agility.” DevOps applies this principle throughout the value stream by identifying bottlenecks, improving processes through a combination of tools and behavior, and then looking for the next improvement opportunity.

“Simplicity--the art of maximizing the amount of work not done--is essential.” Through a combination of automation and working with both upstream and downstream stakeholders, DevOps avoids wasting hours on the wrong deliverables.

Organizations that combine Agile and DevOps realize higher benefits than organizations implementing just one or the other.


Why Agile is Still Relevant for DevOps

As more organizations adopt DevOps, it’s easy to believe that development teams can forget about Agile. Instead, organizations should recognize that Agile and DevOps work together to deliver higher quality software quickly.

In “The DevOps Handbook,” authors Gene Kim, Jez Humble, Patrick DeBois, and John Willis state that “Agile often serves as an effective enabler of DevOps, because of its focus on small teams continually delivering high-quality code to customers.” DevOps began in the Agile community with the first session exploring the application of Agile principles to infrastructure occurring at a 2008 Agile conference and evolving from there.

According to a December 2017 Forrester study organizations with a unified Agile and DevOps program realized faster business value, improved functional quality, greater frequency of delivery, and better business/IT alignment than companies with Agile-only or DevOps-only programs.

So how do organizations combine DevOps and Agile practices? Agile teams should include operational needs earlier in sprint planning. Traditional Agile roles such as Scrum Master and Product Owner will change to ensure operational needs, deployability, and testing are included in the scope of work and that projects are successful when Operations accepts the build.

Agile practices, DevOps tools, and culture changes from both frameworks enable teams to collaborate better to balance faster deployment cycles with high quality. ReleaseTEAM’s experts provide organizations with the knowledge, tools, and training to successfully streamline and evolve their software development cycles. Contact us to learn more.


Jumpstart Your DevOps Project with the Right Team

DevOps promises significant benefits: improved collaboration between teams, increased innovation and automation, improved quality and higher ROI. Realizing these benefits depends on aligning the organization culture and evaluating, implementing, and using the right supporting technologies. Asking developers and operations teams to research, evaluate, plan, and adopt tools from an ever-growing number of vendors while performing their regular tasks can be overwhelming and costly. Hiring additional employees with increasing levels of DevOps expertise to keep the entire project in- house adds to salary overheads and operating expenses.

There is a solution that offers predictable costs and timelines while providing the required expertise to complete your DevOps transformation: hiring the right DevOps consultants. Consultants bring expertise from implementing hundreds of DevOps projects and understand what tools and platforms work best in different industries.

What Do DevOps Consultants Do?

DevOps consultants work with clients to determine the desired goals and success metrics for the DevOps implementation. By providing an objective, outside perspective, DevOps consultants help organizational leadership align and address improvement areas more quickly.

Working closely with development and operations teams, consultants will audit the Software Development Life Cycle (SDLC) through a process called value stream mapping. This assessment determines the bottlenecks in the SDLC where implementing DevOps will have an immediate impact. The DevOps consultants will submit a report with their findings and recommendations.

Once the joint DevOps team has identified the bottlenecks to address, the DevOps consultants’ experience evaluating, deploying, and using a variety of vendor tools eliminates the need for the organization to waste months of effort and resources testing tools in-house. The DevOps consultants provide training to the development and operations teams to improve process and tool adoption. This saved time means faster implementation projects and lower costs overall.

How Long Is The Typical DevOps Engagement?

A successful DevOps transformation takes time to ensure the project tackles the right problems, teams are onboard with culture changes, and measurable results are delivered. DevOps consultants can be hired for the entire transformation or for specific portions of the project: the initial value stream mapping process, tool evaluation, tool implementation and integration, or organizational culture change projects.

The journey to DevOps follows steps that help your employees perform better in phases that ensure all parties are aware of their responsibilities and have the right processes and tools to succeed.

Increased ROI

Hiring external expertise helps organizations avoid costs by speeding up the adoption timeline, avoiding mistakes of choosing the wrong tools, and compelling teams to work together towards the common goal. The less time it takes to implement DevOps, the sooner the organization starts to realize the benefits.

Ready to Adopt DevOps? ReleaseTEAM provides clients across all industries with the expertise to confidently choose the right DevOps tools and drive process and culture change for success. Contact us to find out more.


DevOps, Security Regulations, and Productivity

DevOps is often associated with rapidly releasing new code in pursuit of shorter software development cycles and continuous improvement. What happens for industries with high levels of regulations that can be time-consuming? Are government contractors, healthcare software solutions, and other regulated industries simply unable to adopt or benefit from DevOps?

The answer lies in finding the sweet spot between doing things faster and doing things right. Companies that implement DevOps without quality controls or verifying that they’re delivering the right product won’t pass regulatory compliance, while companies that avoid change will be slower to market than competitors.

Include Regulatory Requirements from the Start

Include applicable regulatory requirements at the beginning of your DevOps planning, rather than attempting to retrofit them afterward. Design automatic compliance checks for each development phase that ensure the required documentation and approvals are complete.

DevOps Automation Informs Audits

Automation is an essential aspect to DevOps to improve efficiencies and speed to market. It has another benefit when it comes to regulatory compliance: it provides detailed documentation of repetitive tasks and removes human error. Complete your audits faster and with more confidence when you implement DevOps automation.

Constant Feedback, Constant Improvement

DevOps removes barriers between teams to encourage feedback earlier in the development cycle. This means issues with the code and product are fixed earlier than in traditional waterfall methodologies. Catching issues early avoids scenarios where non-compliant releases are in production with no fix on the horizon.

Compliant Software, Delivered Faster

It is possible to meet regulatory compliance and deliver quality software more quickly with DevOps by following these simple steps:

  1. Include regulatory auditors in the stakeholder process early in the planning phase.
  2. Automate tasks with clear documentation for easier audits.
  3. Design and incorporate automatic compliance checks.
  4. Use constant feedback to find and resolve compliance issues earlier in the development cycle.

Organizations in a highly regulated industry, can implement DevOps, deliver quality software quickly, and be compliant. Successful DevOps implementations include regulatory auditors early in the planning, use automation to streamline audits, incorporate automatic compliance checks, and leverage constant feedback to find and resolve compliance issues earlier in the development cycle.


Mapping Your Value Stream: The First Step in DevOps

One of the first steps an organization takes before planning and implementing DevOps is to map out the software development value stream to determine where DevOps will provide the best ROI. You can improve efficiencies throughout the entire software development lifecycle by automating the least efficient development tasks and reducing friction between teams.

What are Value Streams?

The value stream concept predates DevOps methodology and is most closely associated with lean manufacturing. In a manufacturing environment, companies use value stream mapping to identify and eliminate waste, making the manufacturing process more efficient and reducing costs. For example, a widget company would trace and document every step it takes to make each widget in a flow chart. Using that data, they can identify and eliminate sources of bottlenecks in the process. Once one bottleneck is eliminated, value stream mapping shows where the next inefficiency is in the manufacturing process, and the company works to eliminate that. Value stream mapping can be applied to other industries, including software development. What activities are adding value to the finished application or system? What activities are not only slowing down development but also creating overhead that provides zero value to the customer?

The Link Between Value Streams and DevOps

DevOps focuses on eliminating bottlenecks in the software development process to deliver software faster, with a higher return on investment. Often, organizations discover that breaking down barriers between different teams helps reduce these bottlenecks and manages constraints in a way that increases overall productivity. The term “DevOps” demonstrates the links between the “Dev” (Development) and “Ops” (Operations) teams.

The second method DevOps uses for reducing bottlenecks is automating processes and approvals. If the value stream currently depends on employees completing manual steps and waiting for repetitive tasks to be approved, consider automating these tasks. Organizations cannot just put developers and operations teams into the same room and expect improvements, nor can they prove automation is improving efficiency without measuring the current process. Value stream mapping documents the flow from idea to release and provides the metrics that organizations need to focus improvement efforts.

Continuous Improvement (CI)

A key tenant of DevOps is that the software development and delivery process can iteratively and continuously improve. Once an organization has eliminated the first bottleneck, that phase of software development will be more efficient. However, upstream activities may not be able to complete their tasks quickly enough to provide inputs into the optimized workflow, and downstream activities may not be able to absorb the additional throughput. Those inefficiencies then become the next candidate for process improvements and automation.

Make the Most of Value Stream Mapping

Value stream mapping is a process that can be efficient or inefficient on its own. It takes time to trace the software development process. Mapping can also disrupt teams as they document their tasks, learn new tools, and adapt to cultural changes. A poorly planned value stream mapping project can slow down the development cycle and miss important data, so it’s critical that organizations work with DevOps experts to guide them through the process of value stream mapping.

Ready to get started value stream mapping?


DevOps is More Than Tools

DevOps promises significant benefits: improved collaboration between teams, continuous software delivery, continuous testing, increased innovation and automation, improved quality and higher ROI. Your organization is interested in those benefits, but implementing DevOps is more difficult than merely choosing a tool and setting a mandate. Where should you start your journey?

Choosing a Starting Point

The first step to implementing DevOps is evaluating current and new projects where DevOps can help break down bottlenecks and deliver value. New software projects, with new teams, can quickly adopt DevOps without fighting ingrained patterns of behavior or duplicating work from legacy systems. However, existing projects may realize the most return on investment by making the leap -- if you have first evaluated the bottlenecks in the current software development process and have established precise requirements for the DevOps implementation. This process is completed during Value Stream Mapping.

Do it Fast or Do it Right?

Some organizations naturally move quickly and if they ship a product with errors, they can issue a fix promptly without adverse outcomes for their customers. Other organizations work under strict regulations and requirements for every change, and mistakes can result in severe financial penalties and even loss of life if the systems are used for healthcare or military purposes. In DevOps, all of the different teams that work on software from concept to support are responsible for the product. DevOps processes not only create a more efficient software development cycle, but they encourage developers to use automation and test early and frequently, leading to higher quality software. The adoption of automation and earlier detection of defects facilitates regulatory compliance and reduces rework common in more traditional workflows between siloed departments. The value of DevOps is that you can do it right and still be fast to market.

Evaluating DevOps Tools

There is no single DevOps tool that an organization can deploy and be able to declare themselves a DevOps shop. DevOps is more than tools, but tool selection is a daunting task in itself. What tool should your organization choose for continuous development, continuous testing, continuous deployment, planning, collaboration, and operations? How will each of the different departments use the tools in a cohesive strategy to ensure all work and requests are captured? How does each of the tools contribute to automation of the entire software development lifecycle (SDLC)? How will they integrate with each other? These are just a few of the questions to answer when evaluating and selecting DevOps tools. The tool evaluation process can be time-consuming, involve repetition for each tool selection, and include several stakeholder groups. ReleaseTEAM has experience in a variety of toolsets that integrate well in complex production environments. We use our extensive background and deep knowledge to reduce expenses and risks for your organization.

Jumpstart DevOps with Outside Expertise

It can be tempting to task existing employees with researching DevOps and create an internal project to adopt DevOps. This approach will cost you more money and effort than investing in a DevOps consultant to help you through the evaluation, planning, and adoption process. Your employees are intelligent and critical to the successful DevOps implementation, but the entire team needs to be on board for DevOps to work. A partial implementation falls apart, and can result in frustration, rework, delayed releases, and lost revenue. The journey to DevOps follows steps that help your employees perform better in phases that ensure all parties are aware of their responsibilities and have the right processes and tools to succeed.

ReleaseTEAM works with your team to assess your software delivery lifecycle through value stream mapping. We identify the areas where DevOps will provide the most value, assist you in choosing and implementing the right toolsets, and successfully guide your teams through the transformation the first time. If your organization has specific government regulations and security clearance requirements, ReleaseTEAM has the right experience and resources that keep you compliant throughout the process.