Tag Archive for: tech debt

The popularity of Agile methodology, along with the increasing trend toward automation in software development, has pushed requirements management solutions to evolve. The misconception that Agile methodology doesn’t work in regulated industries is outdated, but regulated industries have, justifiably enough, specific expectations of their requirements management (RM) solutions, and those expectations continue to drive change in the market.

A recent report from Forrester Research, “Now Tech: Agile Requirements Management Tools, Q2 2018,” outlines the state of the market for Agile RM solutions and lays out the questions customers should ask when selecting the right requirements solution for their space.

Why invest in requirements management?

According to Forrester, it’s not just highly regulated industries and organizations involved in complex product development that can benefit from a requirements solution.

In spite of the “a coalition of Agile aficionados arguing that it’s unnecessary to formally collect and manage requirements,” the report suggests that best-in-class RM solutions can significantly improve product design and delivery for Agile development teams: “In the face of increasing regulations, connected products for the internet of things (IoT), and scaling Agile practices, AD&D [application development and delivery] leaders long for something to bring traceability and auditability to their processes without sacrificing speed.”

Why do you need traceability?

The right RM solution enhances development transparency through traceability. Traceability is a roadmap that shows you where in the product development lifecycle each requirement or business rule was implemented. With traceability, teams are better-equipped to perform impact analysis – i.e., to assess the consequences of proposed changes. This is crucial in complex product development, where simple changes can have far-reaching impacts, and it’s tough to isolate every system component that might be affected by a change in requirements.

Teams facing increasing complexity, pressure to comply with industry regulations, and the need to measure customer value must be able to search, track, and connect interdependent requirements. Achieving a faster time to market demands that teams collaborate quickly and effectively while they work on building out traceable requirements and test cases.

Why is it important to reduce tech debt?

Forrester reports that RM solutions can also help Agile teams reduce technical debt. Agile teams are focused on moving quickly, so they sometimes fall back on fixes that are easy to implement right now, but that will require rework down the line. Basically, tech debt refers to the work you’ll have to do tomorrow because you cut corners today.

You can’t avoid tech debt entirely, and you shouldn’t even try; you can’t move quickly without accumulating a little. But as the Agile methodology becomes even more widespread and project complexity continues to grow, RM tools will help development teams understand what has been done, what will be affected in the next sprint, and how to improve collaboration within distributed teams.

Finally, the report suggests, development teams can use RM solutions to embed visual modeling, design, and prototyping into their product development process. By modeling customer journeys, business processes, system designs, and user-interface components, teams can ensure that the final deliverable meets stakeholder expectations.

How has Agile changed requirements management?

Agile teams expect to move fast, so RM solutions looking to penetrate this market must meet developers’ need for speed. Transparency is another priority for Agile teams, and the transparency and traceability offered by an RM platform empowers teams to move beyond what the report dubs “static, text-based requirements.” As we noted above, traceability enables more effective and timely impact analysis, a critical consideration for rapidly evolving requirements.

Even though plenty of Agile teams see the value of a requirements solution, Forrester notes that “vendors have shied away from the term [requirements management] and evolved their offerings to fit new product niches.” Part of this avoidance of the term is because people tend to associate “requirements management” with clunky, tedious processes that lacked the efficiency and ease of use that current solutions offer. In contrast, the requirements solutions favored by Agile teams are less highly specialized; they have different capabilities and focus on different segments of the development lifecycle. As such, the Forrester report suggests that Agile teams consider whether the best solution for them is not one solution but a combination.

How do you choose the right requirements solution?

To maximize success in requirements management, the report found, teams should choose a platform that works for their discipline (product management, engineering) and their industry (medical, automotive).

As we wrote in our recent post, “Systems Thinking for Complex Product Development,” collaboration is easier and delivers better results when teams are encouraged to find approaches that are effective for them within their disciplines.

Before investing in a RM solution, Forrester suggests that Agile leaders engage in some strategic thinking to determine which RM platform will deliver the most value in concert with other tools and solutions. Decision-makers should:

  • Audit the tools already in use. Company and industry requirements drive investment, so understanding the existing ecosystem of tools already in place at your organization is essential in choosing the best RM solution for your particular needs. Take a close look at your Agile planning/project management, design, testing, and continuous integration tools to determine the best solution for your organization.
  • Identify where requirements fall apart. If you have issues uncovering requirements to begin with, consider a tool with more advanced collaboration, design, and modeling capabilities to help you define exactly what you want to build. If your challenge is understanding the impact of requirements, passing tests, or avoiding bugs in production, you need a tool with greater traceability and robust reporting capabilities that can integrate with automated testing tools.
  • Anticipate change. What changes are ahead for your industry? How will you be affected by new or evolving government regulations? Will your products be integrated with sensitive customer information? Now is the time to start laying the foundations for compliance with these future requirements.
  • Right-size the need for documentation. What’s the future of Agile at your organization? Are you looking to scale Agile companywide? Even if you don’t need a super-robust RM solution now, you’ll need to implement some governance early unless you want to be drowning in technical debt.

To learn more about how Jama Connect® stacks up against other requirements solutions, download our eBook, “Selecting the Right Product Development Platform.”

Technical debt refers to the implied cost of rework necessitated by choosing a fix that’s easy to implement now, rather than a better resolution that would take longer. In simple terms, tech debt points to the work your team will have to do in the future as a result of cutting corners today. 

That said, tech debt isn’t a negative indicator across the board, and it’s impossible to avoid altogether. Sometimes taking on tech debt makes sense, like when you need to speed your time to market or account for last-minute spec changes.  

Complex software that requires extensive refactoring — that is, restructuring of existing code — is particularly associated with tech debt, but refactoring is not only a response to problems with the code. Refactoring often represents an evolving understanding of a problem and the best way to solve it.  

Still, it behooves teams to minimize unnecessary tech debt. In our ebook, “The Essential Guide to Software Development Team Metrics,” we dig into metrics to assess the speed, accuracy, quality and health of your team. Seven of these metrics are especially important to bear in mind when working to minimize tech debt: 

Ticket churn 

Also referred to as “ticket bounceback,” ticket churn is a measure of how many tickets have been moved back in progress over a period of time. Ticket churn gauges rework, so high ticket churn can indicate increasing tech debt, and is likely to impact your team’s velocity and overall product quality. 

New vs. closed bugs 

Track how many bugs are opened against how many are closed to find the rate at which your team clears bugs. This metric is an indicator of your overall tech debt, as well as whether your team is moving in the right direction in terms of general code quality.  

Bug burndown 

Development and quality assurance teams use bug burndown to understand open bugs and their projected closures based on the average bug closure rate. Teams that don’t keep a close eye on bug burndown can lose a handle on their overall product quality and take on excessive amounts of tech debt in their effort to fix bugs quickly. 

Percentage of high-priority bugs 

This straightforward calculation — dividing the number of current, high-priority bugs by the total number of bugs — is simply the percentage of bugs that your team has tagged as high-priority (sometimes high-severity) due to their impact on customers or the product as a whole. Tracked over time, this metric illuminates part of the story of both product quality and tech debt. An increasing trend of more high-priority bugs is often symptomatic of a team struggling with product requirements, test cases and test suites.  

Code churn 

Code churn reflects the number of lines of code deleted and added in the same line. It’s a measure of activity over time that highlights hotspots in your code.  

With brand-new features, a lot of activity in one area isn’t a problem, but over time, code churn should diminish; if it doesn’t, you’re doing too much rework and accumulating an unnecessary amount of tech debt. High code churn can also predict a drop in quality and speed.  

Code coverage 

Also called test coverage, code coverage is the percentage of lines of code that are executed when running your test suite. Fundamentally, code coverage refers to how effective your test process is at producing a quality product. As a rule of thumb, coverage should be in the 80-90% range.  

Code coverage doesn’t measure the inherent quality of your product; rather, it helps reveal the process your team is undertaking to achieve a quality product. Code coverage highlights breakdowns in your test process, like when new code is added but not tested.  

If your code coverage percentage drops over time, devote more resources to test-driven development (TTD) and make sure untested areas are covered. A high-quality test process heads off quality issues and reduces tech debt, setting your team up to be nimbler in the future.  

Frontend app response time 

Frontend app response time, or the average time it takes for your pages to be available to end-users, helps your team identify when important product updates or infrastructure upgrades are necessary to keep your solutions running smoothly.  

Usually monitored closely by DevOps teams, frontend app response time is critical to product success. Your product might add huge value, but users will start looking elsewhere if it’s too slow. An increase in response time often suggests rising technical debt: your short-term solutions are creating long-term problems for your customers and your team.  

Get the full story on metrics for development teams: Pick up The Essential Guide to Software Development Team Metrics now.