Agile Software Development Archives

Tag Archive for: Agile Software Development

The complexity of products is rapidly growing, and as a result, the number of requirements needed to satisfy client goals is also expanding. This makes the documentation process time-consuming and potentially risky.

Existing approaches to Requirements Management (RM) aren’t always flexible enough to meet stringent expectations and provide a single source of truth. Everyone involved with a project requires maximum visibility to understand what you’re building – and why.

One study found that the majority of design teams admit that they don’t have a requirements management system in place, and instead rely on cumbersome emails and shared documents. Furthermore, only 15% of teams surveyed had invested in a dedicated RM solution.

Teams that are frustrated with rework, feeling stuck in unproductive collaboration and not moving as fast as they could benefit from adopting an agile approach to requirements management.

What is an agile approach to requirements management?

There isn’t a commonly agreed upon definition of agile requirements management or a single set of processes that will automatically make you agile if you implement it. However, there are concepts, processes and tools that support an agile approach to requirements management.

The foundation of an agile approach to requirements management is rooted in flexibility. Flexibility means you can easily iterate and make changes, so that you end up with a more accurate outcome and avoid off-target deliveries and missed deadlines.

Agile requirements gathering is focused on developing the product faster while addressing customers’ needs more accurately. Collaboration is critical; everyone on the team must have a firm understanding of the customer’s true needs and how they affect RM.

In contrast, teams that don’t use agile requirements are susceptible to unproductive work time, a lengthy review process, excessive rework, and even serious defects in the released product.

How does agile requirements management outperform the alternatives?

Agile requirements management is focused heavily on action. With agile, you create a flexible framework upfront, so product implementation is faster and more accurate. In contrast, other approaches, such as the waterfall approach, have less flexibility and are built on a rigid foundation. But why?

The waterfall approach uses a V-shaped development process. The steps involved with coding, such as discovery, requirements, system engineering and architecture, are performed in a specific order. You can’t move to the next step until you’ve finished the one before it. Once coding is complete, you continue to move through the next processes in a specific and inflexible order.

The strategy behind this approach is that you do as much work as possible upfront, and any decisions made during the early project stages are adhered to closely, without much room for change. Moreover, requirements and design often don’t go through testing until the end stages of the development process, so any potential changes show up late in the development cycle, and therefore are more time-consuming to fix.

Agile requirements management is built on the principle of flexibility, so any potential challenges are identified and resolved much earlier in the process, minimizing expensive and costly rework. A few benefits of the agile approach include:

Improved product design and delivery. A recent 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.”
Improved traceability. The right RM solution can enhance development transparency through traceability. Traceability empowers teams to perform impact analysis more readily, which is critical to product development.
Achieve quicker time to market. Teams are facing more complexity and pressure to comply with industry regulations, and need to measure customer value to search, track and connect interdependent requirements. Achieving faster time to market requires that teams collaborate faster and more effectively, working to build traceability requirements and test cases.

As you work to understand how an agile approach to requirements management benefits your team and customer, it also helps to have a basic understanding of the agile requirements lifecycle and how it works.

Designing with greater flexibility through the agile requirements management lifecycle

The agile requirements management lifecycle is focused on clearly defining a project’s scope, so that you better understand what needs to happen to meet the desired end goal. It provides a high-level understanding of business goals, and outlines what is needed for the project to be a success. Consider taking the following steps:

Understand user stories. User stories give you powerful information about the problem you’re trying to solve. A user story is a quick description of everyday use cases and might include a few sentences about how the user expects the product to perform. A template might be something like this: “As a [role], I need [product] to do [goal of the software] so that I can [benefit of the product].”
Outline the most important requirements. Identify what requirements are most essential based on the high-level business strategy. These requirements may be supported by user stories, functional requirements and more based on the specific client goals.
Transform to product features. This stage is about fine-tuning and translating the details that you’ve gathered into product features. The development team collaborates to ensure that any requirements are easily understood by anyone working to implement them. User stories are linked to features and tasks, so that developers understand what they need to do – but also why they are doing it.

Agile requirements management helps give you a foundation on which to build, and best practices arm you with strategies that are proven effective at helping you move in the direction of agile.

What are the best practices for agile requirements management?

The agile requirements process helps you capitalize on opportunities faster through earlier launch dates and a prolonged market window. As a result, you can get to market more efficiently with fewer resources spent. To support this, it helps to understand best practices around agile requirements management, including:

Create collaborative processes. You need the ability to accurately capture and communicate the project’s requirements, goals, program and interdependencies to minimize friction throughout the entire process.
Support real-time collaboration. If you want to improve efficiency, collaboration is a critical tool to accomplish that goal. You need the ability to immediately note and prioritize critical decisions, as well as pull in any required contributors and reference historical context to get rid of communication bottlenecks.
Solidify understanding through virtualization. Visual context helps people understand information easier and supports faster decisions. Mind mapping, for example, assists with recognizing data quickly and in context.
Pay attention to the current state and any future potential gaps. You need the ability to understand and respond to change. Identify implications of potential product changes to minimize late-stage changes and rework by ensuring the development teams have the latest data to make informed decisions as requirements evolve.
Implement live traceability. A large benefit of agile RM is increased flexibility. Live traceability enables you to easily navigate upstream and downstream relationships to understand the impact to change and coverage across development.
Fast-track decision-making and reviews. You need the ability to conduct virtual reviews of requirements, test cases, user needs, or test results and to track discussion, changes and critical decisions across teams.

Best practices are a good starting point to figure out how to develop agile requirements management. The next step is to look at your existing tools and ask: Do they support agile requirements management? And if not, examine the alternatives so that you can reap the benefits of an agile process, with support from the right tools.

Selecting the right agile requirements management solution

As you move toward more seamless and agile project requirements, it’s important that you have the right technology in place to support you. Here are a few tips for selecting the right tool:

Examine the flaws in the tools and processes that you already use. Understanding your existing tools, what works and what doesn’t, is essential to future success. Look at your current planning, project management, design, testing and more to determine what isn’t working, so you can figure out what will work better.

Find out where requirements fall apart. A tool with more advanced collaboration, design and modeling capabilities can assist with defining exactly what you need to build. If you’re challenged with understanding the impact on requirements, for example, you require a tool with greater traceability and enhanced reporting capabilities that integrate easier with automated testing tools.

Create a plan that is flexible with change. Keep any future changes in the backdrop while making decisions about technology. Understanding changes that may evolve in the future, such as increased government regulation, helps you stay ahead of what’s next.

Products and systems will only continue to get more complex, driving the need for agile requirements management. Increased complexity translates into more time spent tracking requirements, which is why having the right tools in place is critical.

Requirement Management tools that are nimble enough to keep pace with evolving market demands empower product development teams to leverage technology that fits their existing tech stack and fits easily into their daily workflow.

On May 20th, BeanStock Ventures brought together a panel of medical device software experts, including Jama Software VP of Customer Success, Clay Moore, to bridge the gaps between modern software development and regulatory requirements.

The topic: Agile development. The panel explored if Agile could maintain its adaptive nature and still being complaint under guidance provided by TIR45, a recognized consensus standard by the FDA.

During the webinar, the panel de-mystifies the idea that Agile development lacks the proper controls for producing safe and effective software and that the regulation is burdensome. They cover a range of exciting topics along the way.

The panel explores key issues about Agile and TIR45, including:

How the Agile Manifesto is trying to encourage us to find the proper balance – not get rid of the discipline and documentation that we need, but to find a better balance between that and developing useful working products.
How the development of a foundation of requirements is the single most important design control activity because requirements which form the design input establish the basis for performing tasks and validation of design.
How TIR45 helps address common misconceptions about applying Agile at scale with multiple teams, and the need for documentation.

The panel also offers insights to topical Agile questions like:

How does one balance employing Agile methodology alongside predicting project timing accuracy?

“Perhaps predictability isn’t the right word. A better word might be adaptability, that we can respond to changes in a healthy way that still meets the business needs to be predictable.”

-Kelly Weyrauch, Owner, Agile Quality Systems

Does Agile help you tame change?

“Don’t try to tame change. Embrace it as a natural thing of doing product development in today’s rapidly changing world. And Agile provides mechanisms to be in control of those changes.”

– Kelly Weyrauch, Owner, Agile Quality Systems

What’s the right level of regulatory burden?

“It is generally not the regulations that bring the burden. It’s an organization’s interpretation of them. And nearly every case when I see an organization saying they have a burdensome process, it’s because they did it to themselves. They defined their process, they defined the documentation requirements, they defined the sequencing of things and the rules behind it, in a way that’s burdensome.”

– Kelly Weyrauch, Owner, Agile Quality Systems

So much more was covered in this informative session. To see what you missed, head over and watch the on-demand webinar now.

WATCH NOW

WEBINAR: TIR45 | An AGILE Approach to Software Regulatory Compliance

Are you ready to seamlessly move from CLIA, Research Use Only (RUO) or Emergency Use Authorization (EUA) to a clinical software product?

Join us as we discuss an AGILE approach to software regulatory compliance. We’ll be hosting this informative panel discussion with the owner of Agile Quality Systems and principal author of AAMI TIR45, Kelly Weyrauch, and our partner (and panel host) Beanstock Ventures as we to discuss bridging the gaps between modern software development and regulatory requirements.

This panel de-mystifies the belief that Agile development lacks the proper controls for producing safe and effective software and that the regulation is burdensome. We will share experiences, ideas, and tools you can use for your software regulatory compliance while still staying adaptive and effective.

Date:        Thursday, May 20th, 2020
Time:        10:00 – 11:00am PST

Our panelists include:

Adam Darmstadt – VP of Product Development, BeanStock Ventures
Adam is a software engineer with over 19 years of medical device and life science industry experience.  Adam and his team are passionate about using lean and AGILE methodologies to speed up reaching the end goal without compromising quality.

Clay Moore – VP of Customer Success, Jama Software

With over 20 years of experience architecting and delivering SaaS-based enterprise solutions, Clay and his team help medical device development teams modernize their approach to requirements, risk, and test management to improve quality and delivery.

Kelly Weyrauch – Owner, Agile Quality Systems & a Principal Author of AAMI TIR45

As one of the principal authors of AAMI TIR45 “Guidance on the use of AGILE practices in the development of medical devices software”, Kelly has worked with the FDA and industry leaders on the application of AGILE practices to the medical device world.

Watch the recording now!

WATCH NOW

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.”

In 2001, gathered together in Snowbird, Utah, a group of 17 like-minded software developers brainstormed ways to quickly build software and get it into the hands of end-users. Out of this meeting the Agile Manifesto was born.

The iterative and incremental methodology of Agile has generally been accepted as a modern approach to software development and has high adoption rates across many industries. However, with fluidity and responsiveness to change at the forefront of Agile’s methodology, many organizations believe that Agile is not compatible with highly regulated industries. Lack of planning and documentation, they wrongly believe, are reasons why Agile cannot work for those building products under regulatory compliance.

The truth is that using Agile for product development within regulated industries is actually true to the Agile Manifesto. Here’s why:

Agile is a Set of Values, Not a Set of Rules

The full Agile Manifesto is a succinct and comprehensive overview of the framework’s principles, and the gist is quite simple. Agile is a methodology that encourages teams to iterate; to communicate with stakeholders, customers and suppliers; to not go crazy with documentation; and to be good human beings at work. Pretty simple, right?

So why do many organizations in regulated industries believe that Agile is not feasible?

While dealing with audit requirements and regulatory compliance, the idea of fluidity and “responding to change over following a plan” may have those in regulated industries cringing. But where in the Agile Manifesto does it say that planning and documenting have no place in your software development process? It doesn’t.

The truth is, adopting Agile values just means you are agreeing to open communication, iterating and focusing on delivering a product. Values are just one part of the product development process – organizations in highly regulated industries can adopt Agile values but still select a stricter framework and strategy to adhere to regulatory standards and document their processes.

And while documentation is not discouraged in Agile, teams are encouraged to view working software as a better indicator that the product meets requirements rather than reams of documentation.

Why Choose Agile for Regulated Industries?

Waterfall has traditionally been a popular choice for highly regulated industries. And yet, the number of organizations adopting Agile now due to very low success rates with Waterfall is rising. With fixed requirements and rigidity as the basis for Waterfall processes, there’s very little room for change and flexibility as requirements evolve.

On the other hand, teams who have adopted an Agile methodology are highly focused on creating products that meet end-users’ needs. And Agile gives them the flexibility to be both iterative and fluid.

Agile methodologies also allow for (and encourage) communication between customers, stakeholders and suppliers. You’ll be able to see in real time what’s working and what’s not and, in turn, keep tabs on what your customers want. By constantly reexamining customer needs and wants, Agile teams are more likely to deliver a product that meets users’ expectations. This, simply put, can be your competitive advantage.

Agile not only makes good business sense but may also help your employees feel happier and more fulfilled at work. Adopting the Agile methodology empowers your engineering and product development teams to change as they need and to use their professional judgement. It allows them to have open communication, to know that what they’re building is useful, and to feel that they are being respected and heard.

Leveraging Jama Connect™ for Agile Documentation

When adopting Agile in highly regulated industries, it’s important that you work closely with auditors — internal or external — to clearly communicate your documentation processes. This is where Jama Connect™ comes in.

Jama Connect is your single source of truth when it comes to complex product development. It allows you to document and communicate your requirements and what you’re setting out to build, and gives you a record of who, what and why things changed along the way. Plus, if you decide to make a change or switch directions, everything is fully reversible.

Real-time collaboration within Jama Connect gives you a platform to discuss change by connecting comments, decisions and reasoning throughout the project. With closer communication (in accordance with Agile methodology), teams experience increased productivity, a shorter design process and critical context for improved decision-making.

Jama Connect provides your team with valuable information to help them decide when and how to make changes.

Is Agile Right for Your Team?

While Agile is compatible with all industries — even those with strict regulatory standards — it all comes down to choosing a methodology that is right for your team. A good place to start is by identifying what values are most important to you and your organization and examining your processes to understand what you want to achieve.

Download our whitepaper, Agile for the Enterprise, to learn more about successfully implementing Agile in regulated and governed industries.

The Jama Support Community is a forum for Jama Software users to interact and collaborate with other users and with Jama support engineers. It’s full of resources for everyone from novices to masters, including tutorials and webinars, help guides and FAQs, feature requests and announcements and a robust knowledge base. For today’s post, we spoke with one of our Jama Support Community power users — frequent contributors with great questions and powerful insights into using Jama — about how their organization uses Jama and the value they’ve seen from the Support Community.

Harald Hotz-Behofsits is a product owner at Frequentis AG, an Austrian tech company with staff in 50 countries. Its core business is mission-critical software for the air traffic management sector, but Frequentis also builds voice communications and information systems for defense, public safety, public transportation and the maritime market. After graduating from university, Hotz-Behofsits worked in the Austrian office of Scientific Games until joining the team at Frequentis in 2001.

As a product owner, Hotz-Behofsits works on an agile software team tasked with developing mission-critical software in accordance with international standards. His team needs a product development platform that generates documentation to support traceability from requirements to design to test cases to test results.

Frequentis relied on IBM Rational RequisitePro until 2012, when the team grew “quite unhappy” with its drawbacks, says Hotz-Behofsits, and began looking for alternatives. Jama Software popped up on the company’s radar early on, and in June 2013, Hotz-Behofsits became Frequentis’s first Jama Connect user. Five years later, Frequentis has about 400 projects in Jama Connect.

Hotz-Behofsits cites Jama Connect’s “intuitive user interface” as one of the things he likes most about the platform: “It’s easy to get new people on board,” he says. Hotz-Behofsits’s team uses Jama’s REST API and Jira integrations and makes heavy use of Velocity reports. The team also exports data into Office templates. Jama Connect’s Review Center, Hotz-Behofsits says, gets “daily use,” with what he estimates are 5,000 to 6,000 reviews. Review Center gives teams context and visibility by illuminating the relationship between stories and activities. In addition, Review Center helps teams achieve traceability by demonstrating what happened and why throughout the product development process. Hotz-Behofsits also relies on Review Center to understand how defects have been detected and addressed during the development process.

Hotz-Behofsits uses the Jama Support Community for “inspiration and innovation.” “By sharing solutions,” he says, “everybody gains.” Questions asked by other users, he says, can spark new ideas. When users share their insights or workarounds on the Support Community, everyone has the opportunity to experiment with and even improve upon others’ solutions. Just as the Jama Connect platform empowers collaboration between stakeholders and across teams, the Support Community allows users working in different roles at different organizations to collaborate on how best to leverage Jama for success.

As a seasoned Jama Connect user and a regular presence in the Support Community, Hotz-Behofsits recommends that new users of the Jama Support Community start by querying the existing content, since the chances are that at least some of their questions have already been answered.

Hotz-Behofsits would recommend Jama to a colleague who needed to manage requirements, test cases, test activities, traceability and – “of course” – the review process. For Frequentis, Jama Connect has become a crucial platform for achieving traceability across requirements, clarifying work order (i.e., why something was changed when), and reporting and addressing defects.

Connect with Harald and other fellow Jama users on the Jama Support Community.

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.

As part of an ongoing series, we’re looking at insights and trends uncovered within the Harvard Business Review Analytic Services study, “Bridging The Gap In Digital Product Design.”

Product development is already a stressful endeavor. For companies focused on merging hardware and software into smart products, it’s only getting more intense.

According to the Harvard Business Review Analytic Services report, “Bridging The Gap In Digital Product Design,” nearly 90% of companies are either adding or planning to implement digital technologies to their products.

Given the new process and competitive landscape, 80% of those same businesses say they’re feeling extra time-to-market pressure. Not only that, but an even larger majority (89%) believes the strain will only grow in severity.

“There is pressure to always innovate and create the next generation version of your product,” Jama Software’s vice president of product, Jennifer Jaffe, says. “Sitting in that market is, by definition, a very uncomfortable place— specifically for a lot of companies who have been around a long time and who didn’t used to have all these pressures.”

Driving business concerns are fears of disruption. From cell phones to taxis, home energy management to automobiles, it can feel like no industry is immune to being blindsided by new technology. While companies can’t stop a savvy new competitor gunning for their position, how they innovate in response is crucial.

Software vs. Hardware

Traditional product companies are used to building hardware. When you add software development to the mix, there needs to be some alterations to the process.

That’s why one of the biggest priorities for businesses adding digital technologies to their products should be creating a plan to integrate the hardware and software teams. To do this, businesses must have a firm understanding of their existing development process, its necessary documentation, and logical gaps.

They’ll also need to recognize that software developers and traditional hardware developers work very differently. Figuring out how to unify these two practices, so they’re operating in tandem and not as opposing forces, is key. One of the best ways to do that is by having a method facilitating open communication and accountability.

“Most critical is having real time transparent communication, so that when things change on the software or the hardware side, all parties are informed and can adapt,” Jaffe says. “Without that collaboration, the two teams run the risk of working in isolation and developing products that are incompatible with each other.”

When to Innovate

Another area to consider when moving to connected products is not trying to start from scratch with every release. If a strong hardware platform has already been built, for instance, it makes sense to reuse it. Then, you can focus on incremental gains that can be handled in software updates.

“The more you can put the heavy lift of innovation on the software side,” Jaffe says, “The more likely you are to be able to respond quickly and create lots of different, compelling variants of your product’s experience — and do it as cheaply as possible.”

In that case, the product management team can set about envisioning the requirements of the future and brainstorm all the different use cases for the coming years. For instance, maybe that means creating hardware that can scale to accommodate a heaver usage on processing or memory. Then, looking ahead, if 80%-to-90% of the hardware requirements will basically remain unchanged, the development team can really be pushed to innovate on that extra 10%-to-20% of a new product.

This is also where a product development platform can really give developers an edge. With a simple, efficient solution for saving and reusing your hardware requirements, teams can focus on innovating iteratively.

That’s also why more than half of the companies going digital are partnering with software or other companies to assist with the digital transformation, according to “Bridging The Gap In Digital Product Design.”

What to Focus On

Today’s market is driven by consumer choice. Whether we’re talking about watches or coffee makers, customers have high expectations from products, and there’s a heavy push to constantly move forward. When one company’s product family goes smart, it almost feels inevitable competitors will too.

So businesses must listen to their customers to develop requirements. “The companies that are getting disrupted are oftentimes legacy companies whose business model, technical model, or both, don’t support newer methods for developing products,” Jaffe says. “And, specific to this idea of building to customer requirements, they’re companies that don’t have specific practices or tools to bring customer requirements to the forefront when they’re defining their product.”

Before production, then, companies should be putting prototype ideas in front of consumers for feedback on usability and value. And then running those customer requirements past engineers to sift through what’s feasible. Also, ensuring the requirements are documented in a clear way will keep various teams aligned throughout the process.

Moving Forward

All these shifts and crunches can significantly rattle a traditional product company not used to dealing with them. Keeping your team laser-focused on the evolving process will guide it to success.

“You have to prioritize the work that’s being done by your product development team and then not allow additional scope to creep in,” Jaffe says. “You really have to be judicious about the decisions you make, about what to prioritize, what to work on, and make conscious decisions to say no to projects that aren’t priority one for your development team.”

One thing that titans of any product category should avoid is kicking back with the belief that their winning days will be endless.

“A new, fresh company can come in today without all the legacy of old development practices, of old expectations of what it meant to serve a market,” Jaffe says. “Not only can they be more nimble and receptive on the technology front, but frankly, as a business, they can pivot quickly in the face of shifting consumer demand. That’s how they roll.”

Get a deeper look into the pressures driving companies to develop connected products with our report, “Bridging The Gap In Digital Product Design,” featuring insights from nearly 300 innovators from a variety of industries, including manufacturing, technology, healthcare, financial services, and more.

After learning about the Agile Fluency Model at ProductCamp, I began to wonder where Jama Software’s product-development organization fell within the framework. While I could see evidence of our fluency in the first and second levels, I was uncertain about our competency in aspects of the third level.

At Jama Software, Agile Software Development practices have been in place for several years. In the past few, we have made a series of investments in both our engineers and the broader organization.

In particular, we’ve focused on refactoring workshops, continuous integration, test-driven development, pair-programming, collective code ownership, and DevOps culture. We ship software at a cadence that makes sense for the various markets we serve. Some markets have a tolerance for monthly releases, whereas others operate on a biannual schedule in accordance with their regulatory environments or risk tolerances.

Jama Software’s Approach to Agile Software Development

One practice we’ve adopted, which is consistent with a three-star team, is we have a system of self-organization within our engineering group. Engineers are free to move to different projects and focuses as their interests change. At the same time, we provide strong support for gelled-teams, which consist of individuals whom enjoy working with one other and have gained an efficiency in doing so in particular areas of the product.

An important tenet of a three-star team is that business experts have permanent memberships. So each development team on a consumer-facing project works with a product manager to represent customer and business needs, for instance, or a UX designer to ensure a feature meets design quality. However, those individuals aren’t embedded or collocated with the team. Instead, business experts often work with multiple teams at the same time.

Though we don’t fulfill the criteria of having dedicated business experts and designers embedded on our teams, at this juncture in Jama Software’s growth, it’s appropriate we operate this way. While we’re certainly no longer a neophyte startup, we try to stay lean in our operations. This ensures team members at all levels of the process have a better understanding of what we’re building and why. Practices such as including the engineering team early in the user research process, and brokering out what exactly is going to be built, is an important counter-weight to the direct embedding of an individual for a specific project.

Staying flexible with Agile Methodologies

As we continue to progress as an organization, there will be some practices of a three-star organization that we’ll strive to achieve for the benefit of our own agility. As I mentioned above, we release on a monthly cadence to our hosted customers. For our on-premise clients, we follow a six-month schedule. While Jama Software has a release schedule that may appear longer when compared to consumer market applications, “move-fast and break things” isn’t a mindset that would be appreciated by the companies using our product.

Jama Software builds a solution for customers developing complex, mission-critical products, many of which are regulated. Bugs in our product development platform can lead to bugs in their products, which can result in both financial and fatal consequences. Many of the companies with this kind of regulatory overhead engage in mutual validation of our product when new releases are made available, and only bring them into use across their organizations once it has passed internal controls.

To this end, while continuous integration is an important part of our engineering ethos, and we would like to reap all the benefits of continuous delivery, it’s unlikely that we will push updates of our product to customers multiple times per day.

For software companies making use of Agile Methodologies, it would be a disservice to consider their application an all-or-nothing situation. Applying the practices appropriate for your business context is the most pragmatic approach. However, it’s also important to continually challenge traditional methods of project management to gain the benefits provided by Agile.

One suggestion for those who want to up their game in Agile is to choose a practice and focus on integrating it into your process until you achieve mastery in it. Just as with software development, process improvement is a practice best undertaken with incremental and steady approaches.

For more insights into adopting Agile practices across your organization, check out our on-demand webinar, “Agile Product Delivery Connects Your Business with Development Teams End to End.”

In my prior blog post about pair-programming, I introduced the concept and explained why Jama Software adopted it as a practice in our engineering group. While we have seen many benefits from pair-programming, the practice may not be appropriate for every organization or team, and also does not come without costs and challenges.

In the year or more that we have had teams utilizing pair-programming, we have become familiar with the costs and challenges. This has been helpful for learning how to adjust to the practice on an individual and team-level and ensure that its application has been successful.

Costs

At first glance, pair-programming appears to be an incredibly inefficient use of expensive software engineering talent. Organizations that have no experience with pair-programming will often be initially skeptical for the obvious fact that two engineers are working on the same task. The apparent overhead of pair-programming tends to be the primary factor in push-back from engineering management when pair-programming is being considered for adoption.

It is indisputable that pair-programming adds an overhead to development efforts by increasing the man-hours required. However, assuming that pair-programming doubles the cost is a reductive misconception that equates programming with time typing on the keyboard; ignoring the analytical aspects of it.

Empirical studies have yet to quantify the exact costs or benefits of systematic pair programming as compared to individualized work. The most commonly cited statistic indicates that it can add a 15% increase to the time it takes to complete a task over an individual developer working on it.

Our experience has shown that this additional cost is minimal in comparison to the benefits it provides our teams; better quality, better understanding of the code, and lower risk. It is these benefits that allow us to become more agile in the long-term. In this sense, pair-programming is a strategic investment in the software and the team charged with improving and maintaining it. Despite increasing the time to complete a task, pair-programming also aids in reducing the count of bugs not caught during the development process, and improving the extensibility of the system over time.

Pair-programming, just like any other Agile Software Development technique, is one that should be applied to the appropriate situation. While pair-programming provides a great way to ensure better design in the codebase and lower the risk associated with having one person responsible for a system, it is not the right instrument for every task.

Poorly applied pair-programming leads to the worst-case outcome of doubling the time needed to complete a task. In order to use pair-programming effectively within your organization, it is important to be cognizant of situations where it is unnecessary and can be an unproductive use of knowledge workers.

Challenges & common pitfalls

There exist some common situations & indicators of non-performance for pair-programming that are important to bear in mind. Being mindful of these circumstances can help identify necessary adjustments to make pair-programming more successful within your organization.

Situational issues

Pair-programming is NOT the right tool for every task

When a task is simple enough, such as a dev-chore, a defect writeup, or a spike, pair-programming is not always appropriate. Adopting pair-programming in all cases is not efficient and can severely limit the productivity of a team and increase the costs of development efforts exponentially. When a Scrum team discusses new development work, is it important to identify whether or not pair-programming would be beneficial for a particular task. Being dogmatic in applying pair-programming is never appropriate. A good rule of thumb is that pair-programming is best applied to production code that needs to be maintained.

Pair-programming is NOT right for everyone

Pair-programming is an activity that takes place outside of the comfort level of some engineers, and it cannot be forced upon them. Deciding to engage in pair-programming needs to be a mutual decision of the scrum team, and the practice needs to be open to criticism within Sprint Retrospectives for potential refinement. It is best to gradually introduce the practice, as with every Agile concept, for those who are tentative on the idea.

There can also exist other issues within a team that make pair-programming a difficult undertaking. Pair-programming puts two engineers in very close contact with one another, and can be problematic if relationship issues, or personal hygiene issues are present.

Remote pair-programming

Pair-programming benefits immensely from team members being co-located. When teams do not share the same workspace, difficulties such as delays in coordination, the integration of technical tools, internet connection speeds, and the possible need for additional technology to support pairing are introduced. Remote pairing can add immensely to the existing overhead cost of pair-programming.

Indicators of non-performance

Lack of engagement

Both engineers must be actively engaged throughout the pairing session in order to gain the benefits of pair-programming. To mitigate potential distractions, some pairs agree to not check their phones or emails during the session, leaving that for breaks. Many also use the Pomodoro Technique, to ensure that energized work and breaks take place at regular intervals during a pairing session.

Silence

If the driver is silently typing code without consulting the navigator, or the navigator is not providing insights, then something is awry. Pair-programming is about active and candid analysis of the existing code and all new modifications being made to it. This is best performed through conversation.

“Watch the Master”

“Watch the Master” is a scenario that often occurs when one person in the pair is more experienced that the other. A common situation for this phenomena is a senior engineer working with a novice engineer. The senior engineer may skip what they think to be unnecessary explanation, while the novice engineer may feel to timid to ask questions or challenge the approach taken, deferring to the senior member of the pair. This is similar to the aforementioned problem of silent disengagement, and does not provide the benefits of mentoring that pair-programming provides.

Side-effects

Loss of Confidence

When first being introduced to pair-programming, some engineers feel that they lack the same understanding of their work than what is produced when they work as individuals. This is a circumstance that is especially common for the novice programmer in a senior-novice pair.

It is important within a pair-programming setting for each participant to be honest about their understanding before moving onto the next major phase. This loss of confidence is in many ways a side-effect of pair-programming’s primary effect of reducing strong code-ownership in favor of collective code-ownership.

Lack of confidence can also indicate of a lack of trust for their counterpart in a pair. As individuals work together, it takes time for trust and mutual confidence to build. Pair-programming can be a great exercise for improving rapport between team members, but it takes time and effort.

Lack of code-ownership

Related to the loss of confidence one might have about pair-programming is the perspective that it erodes code-ownership over implemented features. Code-ownership is a nuanced concept, that has both meaning to engineerings and managers.

Code-ownership can be a source of pride for the engineer who implemented a feature as an individual contributor. For managers, knowing the sole point-person for a portion of the code base is is useful when trying to put out fires. Letting go of these landmarks in favor of a team-focused ownership concept can be a tough cultural change for an engineering group.

Two engineers being responsible for the code output of a user story may at first glance seem as though it reduces accountability and responsibility. Reducing accountability or responsibility is NOT one of the goals of pair-programming; instead it is a tool to increase accountability of the entire team by moving the needle towards collective code-ownership.

Pair-programming, at least in the case of Jama, was a way to push us towards a culture of collective code-ownership, where every member of the team feels both responsible and capable of contributing towards the progression of the software, rather than particular individuals. Having one engineer too tightly coupled to code they have written in the past is an organizational anti-pattern and a risk to the business.

What’s next?

For many engineers & software engineering organizations, pair-programming is a novel way of working that turns the commonplace individual-contributor mode of working on its head.

As I explained above, adopting it as a practice is not without it’s challenges. If you are still convinced after reading this post that it is something you would like to try, do so on as small of a scale as possible. You might first try pair-programming on an individual level with a fellow team-member, and then branch out by trying it at a scrum-team level. If you are feeling very confident, you might even try mob-programming, an approach that involves the entire team.