Tag Archive for: Agile Teams

Tag Archive for: Agile Teams

A Step-by-Step Guide to the Requirements Gathering Process

In the quest for a successful product development process, there are any number of steps that could go wrong or lead to release delays or cost overruns. Few, however, are as vital to a good outcome as the requirements gathering process.

The requirements gathering process is central to a timely and efficient release of a product that fulfills expected deliverables. Unfortunately, this important step is too often rushed, condensed, or truncated. When all of the relevant stakeholders aren’t consulted for input, the requirements document won’t include everything necessary for a successful product, and the process may be doomed to failure before design even begins.

To help you gather the right requirements from the right people, Jama has assembled this step-by-step guide to the requirements gathering process.

A Step-By-Step Guide to the Requirements Gathering Process

If you’ve waited until project kick-off to start gathering requirements, you may have already waited too long. Requirements gathering should begin as soon as possible—even before the official beginning of the project, if possible.

RELATED POST: What is Requirements Gathering?

And requirements gathering should be an ongoing process. Obviously, there’s a point where the real design work must begin, but you should always have an ear and eye open to catch additional requirements as they arise. The earlier you can catch new or revised requirements, the easier it will be to integrate them and avoid delays or cost overruns.

With that somewhat fluid and holistic perspective in mind, there is still value in defining a more linear process that can give a framework for ongoing requirements gathering. Here is a good starting point for gathering requirements for your next project, broken down into three phases:

Phase One: Requirements Elicitation

The initial phase of requirements gathering is elicitation, which is just a process of collecting all of the top-requirements from all relevant stakeholders through a series of sessions, meetings, surveys, interviews, or other means. The elicitation process can be broken down into four steps:

1: Establish stakeholders. The very first step in requirements gathering is figuring out whose input to include in the process. You can split stakeholders into three basic groups:

    • Internal stakeholders: These are the people inside the company or on the development team who have a direct interest in positive outcomes. Internal stakeholders can include the project sponsor, managers, SMEs, and others.
    • Technical stakeholders: Technical stakeholders are the teams and leaders responsible for developing and implementing the project or product. This group may include developers, testers, solution architects, and other support teams.
    • External stakeholders: This group will have an interest in the outcome of the project, but will not necessarily be directly involved in development. External stakeholders may include compliance and regulatory groups, business analysts, or customers and end users.

2: Define initial scope of the project. Defining project scope is key to avoiding scope creep along the way. While it’s important to recognize that the scope may change after requirements gathering sessions, defining the initial scope can help keep the project from getting out of control early on.

3: Set up requirements gathering sessions. Once you’ve established the various stakeholders, start holding sessions to gather requirements. These meetings could include internal or external stakeholders or even a combination of both. For a successful session, follow these guidelines:

    • Establish a clear agenda ahead of time. Write out the main points to be covered in the meeting, including any specific questions or development items for which you need to write requirements.
    • Take notes. Never assume that someone else is taking notes! Write your notes under each agenda item so that you start grouping requirements. For example, if you know that a particular integration will be necessary, make notes under that heading on your agenda to keep those requirements together. Review your notes immediately after your meetings and send to internal teams to make sure everything is captured in one place. Save your notes to a shared folder for the entire team.
    • Start creating tasks. After notes are completed, use them to start creating tasks and action items and defining deliverables. Set up future meetings as needed to capture additional action items and requirements.

4: Get creative. Initial requirements gathering sessions may be focused more around technical stakeholders or business analysts, but be sure to include time to gather input from creative team members—marketing, design, and others. It’s also good to include sessions with end users, sales team members, and others who can offer input on what features and benefits the final product should include.

For a deep dive into requirements gathering techniques, visit: 11 Requirements Gathering Techniques for Agile Product Teams

Phase Two: Requirements Documentation

In the documentation phase, the development team organizes input in the form of user stories, functional decompositions, feature descriptions, and the like. We break this phase into three steps:

  1. Write the Marketing Requirement Document (MRD). The MRD is the document that expresses a customer’s needs or wants in a final product from the development team. This document will help define customers and their pain points, identify competitors, and establish business needs and desired business outcomes.
  2. Revise scope, if necessary. This isn’t an opportunity to completely redefine the project concept or scope, but rather a modification step that takes into consideration all of the requirements gathering sessions. The point of this step is simply to make sure the scope is defined as completely as possible to avoid future scope creep.
  3. Write the Product Requirement Document (PRD). Or collect the requirements in some other format that your team or organization has agreed to use—a spreadsheet, a database, or a requirements management tool like Jama Connect. This document should include relevant insights from the MRD and other supporting early notes. It should also integrate user stories, feature descriptions, functional and non-functional requirements, etc. It should have four main components: purpose, features, release criteria, and timeline.

 Phase Three: Submit for Review

Once you’ve conducted multiple requirements gathering sessions and completed the initial documentation, it’s time for review.

  1. Confirm requirements with stakeholders. Involve as many of the original stakeholders as possible. Ask them to review the requirements as defined in documentation. Are the requirements clear to all parties? Did the product development team miss any important requirements? Revise any requirements that are unclear to all parties. Be sure to get sign-off on individual requirements by relevant stakeholders.
  2. Conduct prototyping and testing. Wherever possible, conduct initial prototyping and testing on a working model of your specification. Perform feasibility, usability, and product concept testing. This step should be conducted at the same time as the previous step so that results can be shared with stakeholders.
  3. Prioritize requirements. Once requirements are clarified and signed off, the team should prioritize them with as specificity as possible. More than just noting whether a requirement is a “must have” or “nice to have,” prioritization should also involve ranking each requirement within the higher categories.

There is much room for overlap between these phases and steps, and it may feel overwhelming to undertake the entire requirement gathering process before any design or development begins. However, spending the time to conduct a thorough requirements gathering process can save time and money and create a much higher probability of success for your project.

Common Pitfalls of Requirement Gathering

Even when a thorough process is undertaken, teams can encounter challenges and pitfalls along the way that risk introducing delays into the project development process.

  • Making assumptions or not clarifying requirements. When faced with a long list of stakeholders or requirements gathering sessions, it’s tempting to make assumptions. Take the time to clarify, ask more specific questions, and get as much detail as possible. And be sure to be as specific as possible in your confirmation process!
  • Focusing on HOW instead of WHAT. Requirements should address WHAT a product MUST do (the functional requirements) and WHAT constraints it will have on how it achieves that functionality (the non-functional requirements). Don’t let assumptions about tools, features, techniques, implementation, or other development concerns influence how you gather and write requirements. Just listen to the needs of stakeholders and write the requirements to those needs.
  • Failing to adequately consult stakeholders. This pitfall could take several forms. It may mean not conducting enough sessions at the beginning of the process, or it could mean not adequately confirming requirements before beginning design and development. Be sure to get a thorough review and sign-off of all requirements before moving on to the next phase. One way to do this is with a good requirement management (RM) tool such as Jama Connect. With a requirements management tool, everyone has access to the same information, and notes and other feedback can be attached directly to requirements for traceability purposes.

Requirements Gathering for Agile Development

While the requirements gathering process outlined above is ideal for many projects, Agile teams have different needs, and an extensive requirement gathering process could interfere with their results. Agile teams expect to work fast, and scrums and sprints are typically just a few weeks, at most.

For Agile teams, a robust requirement management tool can streamline requirements gathering and management without sacrificing results. With a tool like Jama Connect, teams have transparency and access to requirements at all times, allowing easy annotation and clear traceability. Requirements management products encourage collaboration throughout the ALM product development process and offer clear advantages over static tools such as spreadsheets or simple documents.

Comprehensive requirements gathering is the key to a successful product development process. By clearly defining requirements and scope up front and getting sign-off from all stakeholders before full design begins, teams will have a much clearer path to product development success. While it’s no replacement for a requirements management solution like Jama Connect, which automates Live Traceability™, download this project requirements template to make things simpler.

 

requirements-management-hub


Adopting an Agile Approach to Requirements Management

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.   

requirements-management-hub

 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.  

RELATED POST: What is Requirements Traceability and Why Does It Matter for Product Teams?

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.  

RELATED POST: 11 Requirements Gathering Techniques for Agile Product Teams

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.  


One of the biggest challenges for companies at the enterprise level is remaining competitive in a climate full of innovative entrepreneurs and nimble startups. A company that has been around for decades, and has entrenched hierarchies and bureaucracies, risks falling behind up-and-comers who have the flexibility and culture to remain nimble.

But size doesn’t have to be an impediment to implementing Agile teams. Even global behemoths can use Agile principles to remain on a path of growth while still responding to customer needs like a startup.

In an article for Harvard Business Review, authors Darrell K. Rigby, Jeff Sutherland, and Andy Noble look at several different companies that have implemented Agile methods successfully and review what worked, what didn’t, and how companies can launch Agile teams that work — and position themselves for a more competitive market going forward.

Challenges and Benefits

Scaling up Agile offers enticing benefits to leaders who face a constant barrage of challenges from energetic, nimble startups. What leader wouldn’t want a more responsive, adaptive organization?

But turning Agile teams into a reality can be tough for companies with clearly established hierarchies and slow-moving bureaucracies. It’s one thing to know that organizing multidisciplinary Agile teams would be beneficial; it’s another thing entirely to clarify which functions are suited for Agile principles and how many Agile teams to launch.

Not All Functions Have to Be Agile

Leaders looking to scale up Agile need to recognize that not all functions have to be organized into Agile teams. Agile teams are best suited to functions related to innovation — and indeed, the methods first caught on in IT departments. Operations such as purchasing and accounting may not be the best place for Agile teams.

However, the authors of the Harvard Business Review article point out that once Agile teams are launched in some functions, they will, by necessity, interact with other parts of the business. These fledgling Agile teams risk creating friction with departments still operating under traditional top-down hierarchies and existing bureaucracies. In order to keep both parts of the business functioning and positioned for success, leadership itself needs to understand and adopt Agile approaches.

Bosch, the German multinational engineering and technology company and an early adopter of Agile methods, attempted to implement a “dual organization” — that is, the company deployed Agile teams across the newest, “hottest” initiatives while keeping traditional functions operating as usual. But this implementation didn’t have the transformative effect the company hoped for, so it tried again in 2015. This time, members of the management board were divided into Agile teams, and the project evolved from an annual project to a continuous process. Now, Bosch has a mix of Agile teams and traditionally structured units, but nearly all areas have adopted Agile values and are more collaborative and adaptive.

Read this blog to learn more about Agile software development practices for regulated industries

A Blueprint For Implementing Agile Methods

Implementing Agile methods across the organization requires a different perspective and outlook from the traditional top-down, project-focused approach used by leadership in the past. In fact, the very nature of those old systems runs counter to Agile principles.

The authors highlight several keys to successful Agile implementations:

  • Scaled, gradual launches: With rare exception, the companies that succeed with implementing Agile teams do so by proceeding gradually. They may start with an initial launch of teams best suited to the methods, evaluate the success of those teams, and then role out new teams across functions that make sense.
  • A taxonomy of teams: “Taxonomy” is just a way of classifying teams and functions. This system follows Agile’s modular approach by classifying different components of the business and then integrating them. For instance, a company could identify three functions — customer experience teams, business process teams, and technology systems teams. It would then create a cross-functional team from these functions — one designed to solve one specific problem.
  • A transition sequence: Leaders should identify those initiatives that offer the greatest value and the most learning and then position them for launch by making sure the team is ready to begin. The authors offer a checklist of attributes of a team that’s ready to begin, including focus on a high stakes major business opportunity, commitment to Agile values, principles, and practices, and support from senior executives.
  • Strong buy-in from top leadership: Whether the company completely reorganizes to start over with Agile teams or begins by implementing Agile in a few functions and letting it spread organically, none of the implementations would succeed without full support from top leadership. Leadership should be committed to addressing impediments and driving the adoption of the team’s work.

To learn more about common problems with Agile and how to solve them, check out our webinar, “How to Avoid Common Pitfalls of Agile for Embedded Systems.”

No Limits

In practice, there is no limit to how many Agile teams a company can implement across the organization. Agile teams can even work in “teams of teams,” where each smaller team is responsible for one small initiative that feeds into a larger initiative. And as Agile teams gain traction in the company, more traditional functions can adopt Agile methods and implement teams as well. Agile methods have been implemented in sales, marketing, and even HR functions.

Scaling up Agile is at once intimidating and enticing, but those companies that implement Agile teams successfully see major improvements to their businesses. Not only do they respond and adapt more quickly to market changes and competition, but they often see better financial results, greater customer loyalty, and higher employee engagement. For those enterprise level companies struggling to keep up with a rapidly changing market, scaling up Agile offers a way to stay competitive now — and far into the future.

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

Agile Methodology for Medical Device Developers

This is a guest post from Jason Swoboda, general manager of the medical device engineering firm, Velentium. It originally appeared on their blog. 

Medical device developers face a common challenge: Harnessing the best ideas from the Agile methodology on projects that, because of their regulatory environment, appear to demand a classic waterfall model.

It’s not that the classic waterfall model is bad. Among other advantages, it’s a very clean way to visualize and map a complicated process. But anyone familiar with the debates surrounding development models is aware that, as with all models, the waterfall model has limitations. One of the first and most frustrating limitations that developers frequently encounter with the classic waterfall model is its demand that requirements be nearly complete before design can start.

“I can’t move forward until you deliver complete requirements,” the developer says to the end user.

“I can’t clarify requirements any further until we see a first-pass iteration of the product,” the end user responds.

“But I can’t develop an early version of the product without knowing what I’m supposed to make!”

At this point we no longer have a waterfall model; we have an eddy. We’re caught in an infinite loop and we haven’t even made it out of phase one.

The waterfall model is laid out the way it is because, when it works, it helps developers minimize waste and forestall misunderstandings. Clean labels and discrete phases should also, in theory, ease workloads for documentation, oversight, compliance transparency, and process improvement reviews. But actual conditions rarely conform to these convenient patterns. When they don’t, we’re confronted with a choice: attempt to force conditions to fit the expected pattern, however frustrating and inefficient that may be… or adapt on the fly as best we can.

Learn how to avoid common pitfalls of the Agile methodology in embedded systems by watching our webinar. 

That’s why the Agile methodology is so appealing: it offers options that anticipate and prevent the bottlenecking and potential crisis points to which static development models are normally vulnerable. But which approach is right for medical device development?

Velentium believes that if you become too attached to any one model — even one that has “agile” in its name — you’re no longer “agile” by definition. Rigidly adhering to a single approach for every effort by definition cannot be flexible, speedy, and nimble.

At the same time, Velentium is also a company whose principles dictate their practices. So, here’s their guiding star: take a continuous deployment approach to projects. Focus on delivering value as early as possible, and then adding value iteration by iteration until the project is completed. They shed light on their development practices in the text and models below.

Velentium’s Iterative Development Process

Agile Methodology for Medical Device Development

As we develop sequentially around these quadrants, the first question to ask is: What’s the smallest slice of the final product we can build that contains a basic version of the most important functions of the whole? (Randy Armstrong’s “Know Your Why” is really helpful here). The answer will guide us through our first rotation. Then, as we prepare for the next turn around the spiral, we determine which of those functions would be the most valuable to expand first. What’s our next benchmark? Which additions will enable testing we can’t meaningfully conduct yet? What does the end user need to see first? What will help clarify requirements or refine project scope? If the project were unexpectedly cut short immediately after the next iteration, what would be the most valuable functionality we could implement by then? These are the questions that will guide our decision-making for what to do at the outset of each development round or sprint.

This process involves key stakeholders, to whom iterations are shown for feedback at regular intervals. Development proceeds in partnership, with open lines of communication and process transparency.

If you overlay this process atop the classic waterfall model, it looks like this:

Agile Methodology for Medical Devices

It still starts with the requirements. We want them as complete and as clear as possible. But we don’t let compiling them exhaustively impede forward momentum, and we don’t expect them to remain static for the duration of the project. Instead, we anticipate changing needs due to evolving market conditions, new research or regulations, and clarification achieved through the development process itself.

We’ve found it’s important to chart the course as well as you can, start moving, and be ready to incorporate new data and updated information into a dynamic master plan as you go. So, in the midst of lingering unknowns on requirements, we move ahead to early design. We let design (and design feedback) inform and complete our requirements.

Then, when we move from requirements and design to implementation, what we or our clients learn during implementation may cause us to revisit requirements and design, and so forth. As we move through iterative development — always seeking to deliver value early and add value often — we loop through project phases in progressively longer loops, all the way into validation. We never want to get bogged down any individual step. At the same time, we don’t want to miss an opportunity to add value because we’ve arbitrarily “moved on” from a previous phase: we believe those decisions should be governed by project scope and cost/benefit analysis, not workflow theory.

To learn more about implementing the Agile methodology into your process, download our white paper, “Agile for the Enterprise: 5 Steps to Helping Teams Move More Effectively.”

Development teams need the most effective solution to manage product development complexity, but can’t afford to restructure their entire process and workflow.

That’s why integrating leading product development solutions like Jama Connect™ and Jira Software is the best answer. We recently explored some of the benefits of bringing the two solutions together in a recent webinar, “Managing Hardware & Software Product Development Complexity with Jama & Jira,” and wanted to share a few of the advantages with our readers.

The Document Dilemma

In the past, Microsoft Excel or Word may have done a passable job at housing requirements and specifications. However, even those who believe those types of tools were once effective have long since realized that they are no longer practical when it comes to complex product development.

It’s likely you’ve been there — staring at a worksheet with 100+ rows and 10+ columns of data. In an effort to add clarification, you also have a Word doc with a list of specifications. You send the documents via email for your team to read through, and then attempt to comprehend and submit actionable feedback that will impact the outcome of the entire project.

You dread getting the responses back because you know everyone has a different method for submitting feedback and version control will be a nightmare. Even with tools like SharePoint or wikis, collaborating via documents makes it impossible to get timely and actionable feedback from multiple team members in a way that maximizes efficiency.

The Answer: Database Solutions

Database solutions like Jama Connect and Jira Software ease the pain of managing complex product development.

These solutions are purpose-built to help you execute specific pieces of the product development lifecycle, and are known to outperform competitors in those functional areas. Here’s a quick glance at how the two platforms complement each other.

Jama Connect
Answers the questions: What are we going to build? Why are we building it?
Areas of focus: The upstream definition process — making sure you’re doing the right things to successfully build the right product.

Jira Software
Answers the questions: How are we going to build it? When are we going to do it? Who is going to do the work?
Areas of focus: Task tracking and making sure those tasks are being completed.

Integrating Jama and Jira Creates a Juggernaut

Bringing together Jama Connect and Jira Software allows you to work in the solution that best fits your workflow, not the other way around. They are both flexible solutions that adapt to your process — whether that’s Waterfall or Agile or something in between.

They can also be used together in a variety of industries and applications, from semiconductor to medical, from aerospace and defense to automotive, and even IT organizations building strictly software projects.

Jama Connect is used for business objectives and epics (i.e., requirements), as well as status and relationships in the stories phase. It puts all the content in one location so the versioned document dilemma you’ve experienced disappears. Within the system, you can:

  • Collaborate with ease using communication and review capabilities
  • Seamlessly capture and manage decision history and version control
  • Ensure requirements are tied to test cases with coverage analysis upstream and downstream

To complete the loop, Jira Software tracks tasks and progress. It’s the bidirectional synchronization between the two systems that allows you to maintain consistency and alignment throughout the development process.

Defect Management: An Integration Use Case

The integration between Jama Connect and Jira Software is also a powerhouse when it comes to defect management.

In addition to capturing requirements and specifications, Jama Connect also employs test management and houses the tests planned to validate those requirements and specifications.

If tests fail and will create a defect as a result, that information is passed to Jira Software for those defects to managed and fixed.

Furthermore, team members who work in Jama Connect can change the priority of a defect in that system. The information is then available to team members who work in Jira Software. Team members working in Jira Software can continue doing their burn downs and execution, with visibility into where the defect originated and what high-level requirements might be impacted.

By integrating best-in-breed solutions, day-to-day users of each specific software don’t have to bounce back and forth between different tools or change their workflow or process. Yet they can still benefit from sharing the necessary information between both solutions.

A Closer Look

We get many inquiries about Jama’s integrations, and most frequently they involve Jira Software. To hear more about the key benefits of using these two first-class product development solutions, watch our webinar.

Better time-to-market is a priority for any development team, but it can come at the cost of accuracy and quality. There are many metrics to track progress and evaluate success in dev teams, but the following are especially crucial for those seeking to balance speed against accuracy and quality.

Cycle Time

Cycle time measures how much time is spent working on an issue – in other words, how long it takes the issue to “cycle” from one state to another (usually from open to closed). You can look at cycle time by type (how long it took a bug to go from open to closed) or by status (how long a bug sat open before it was closed).

Monitoring cycle time helps you set accurate expectations and identify bottlenecks or other pain points affecting your team. A spike in cycle time often points to a breakdown or a blockage somewhere in your process, meaning it’s time for an open conversation about what’s working and what’s not.

Release Cycle Time

This metric tracks your team’s total time per release: from the moment when a release began to when it was shipped. Tracking release cycle time can pinpoint holdups and process inefficiencies that delay delivery. Understanding release cycle time also helps you determine the accuracy of your ship dates and manage expectations around future releases.

Velocity

Velocity measures your team’s delivered value: the amount of value-added work, like features ready to test or ship, delivered during an agreed-upon time period.

Teams generally calculate velocity across three or more intervals to establish average velocity. Average velocity serves as a baseline for setting delivery expectations, understanding if your team is blocked and determining whether your process changes are working.

Your volatility is also relevant – that is, how much and how often iterations deviate from average velocity. High volatility signals that something is broken in your process or team.

Throughput

Throughput is your team’s total work output: the number of features, tasks, and bugs that are ready to ship or test within a given time period.

Usually, teams refer to last period’s throughput, but average throughput can be an especially helpful metric when it comes to capacity planning: comparing average throughput against the current workload tells you when your team might be overloaded.

Throughput helps measure your alignment with your goals. For example, if your primary goal is bug-squashing, you should expect to see plenty of defect tickets being resolved; if you’re focused on features, you should see more feature tickets than bugs. When your team’s progress is blocked, or their energies are pointed in the wrong direction, throughput drops.

Open Pull Requests

Pull requests are how developers ask their teams to review changes they’ve made to a code repository. This metric measures how many pull requests in a given repository —  or across all repositories — have been opened but not closed.

Your number of open pull requests will affect your throughput and iteration flow, so keeping an eye on this number can improve your team’s delivery time.

Tracking open pull requests over time also helps you spot bottlenecks in your feature delivery process.

Work in Progress

Work in progress (WIP) is the total number of tickets or issues that your team is currently working on. Like throughput, WIP is an objective measure of a team’s speed as a present moment indicator.

Ideally, WIP remains stable over time; an increase in WIP can identify inefficiencies in your process or signal that your team is overstretched (unless you’ve added more team members, of course!).

You can also divide your WIP number by the number of contributors on your team to get a sense of average WIP per developer. This number should be as close to a 1:1 ratio as possible, since too much multitasking tends to affect the quality and accuracy of your deliverables.

Iteration Flow

Iteration flow is a visualization of the status of your tickets over time. Flow is a good description, since this metric visualizes the shift of work from one status to another as your team moves toward completion through a defined process. It measures time to delivery along with the repeatability and health of your process.

Monitoring iteration flow helps highlight breakdowns in your process and get ahead of delivery problems, and it gives everyone on your team a tool to evaluate the predictability of their work.

Difficulty of Feature Implementation

This metric reflects your team’s perception of how difficult it was to implement a particular feature. An anonymous poll every sprint that asks your team to weigh in on the challenges of implementing the most recent feature(s) is a good way to collect the qualitative data you need.

Your team’s perception of the difficulty of feature implementation can have a huge impact on product roadmap and sprint planning. This metric helps you understand when your team would benefit from additional resources or extra training – or when they are ready to tackle more challenging work.

Should we release faster?

This metric represents your team’s perception of whether the team should speed up its cadence of releases. As with difficulty of feature implementation, you’ll need qualitative data to evaluate this metric. You’ll get the best information by polling your team every month or every quarter, since this metric doesn’t tend to fluctuate as much from sprint to sprint.

How your team feels about the pace of their sprints can give you insight into velocity, throughput and overall team health, while adding crucial context to your release window accuracy metric.

To get the full story on tracking data points for development teams — including more information on how to measure them and why ­— download our eBook, The Essential Guide to Software Development Team Metrics.

Agile Fluency: A Look Within

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

As Jama grew, our Engineering department began to change overnight. Teams were outputting consistent velocities, we had upped our abilities technically on how we measured areas such as performance and quality, we began 8-week planning cycles, we doubled our Engineering team and we had a strong roadmap to follow but for some reason it didn’t feel right. Identifying what that was exactly is where the challenges began. Why was it that we’ve come so far as an Engineering team but didn’t feel we had reached the Agile utopia we were seeking?

So What Were the Issues?

First and foremost, we called ourselves an Engineering Team, which meant that we were all in this together and operating as the collective whole, however when you really observed what was going on you saw static individual teams focused on only their projects. This became clear one day when I was in a meeting with Product and was told that the “top priority project” needed protection to get it out the door. I put it in quotes because at that time I thought there were multiple priority projects but no clear communication on which one was higher than the other. I then decided to test this with my team. In 1:1’s I asked a sampling of my team members, not on that project, what they thought was the top priority. The way in which I received the answers told me we had an issue. Half of the people I asked didn’t know and thought that what they were working on was a priority project, the other half answered correctly but with a very guarded response, as if they were going to be judged if they got it wrong. I then asked one key question to some of them, “Do you feel empowered to help that priority project if it needs it”. The answer was “no”. Not because they didn’t want to do the right thing, but because of the pressure they felt to get back to the project they left and get it on track again. The teams felt they were being measured on hitting certain sprint goals even if the business made the decision for them to do something different that affected it. We needed to get to a model that allowed teams the flexibility to protect our priorities without a feeling of guilt for those ones they left.

Teams believed that with more measurement came scrutiny. I started hearing comments that teams felt the business cared about velocity numbers more than the value being delivered from them and because of this they were more focused on how to make their burndowns look good, rather than taking chances and shifting during a sprint if that affected how the burndown presented itself. Hearing this cut to the core of my being because I wanted teams to take chances, innovate and change the sprint if it no longer made sense. Why continue to build in a direction when you know it’s the wrong path? Also, I know that there is always a story to tell behind burndowns regardless of how they look. I’ve had plenty of teams show me poor burndowns, but then the explanation as to why, is where I find the true value of a burndown, because the team iterated and learned something about the project that forced a shift. This is what we needed to reward the continual learning and change to reach the overarching goal as we drove to the end of the project, not every burndown’s success.

Another issue was around Engineering Priorities. Some examples include items such as infrastructure improvements, removal of tech debt, automating certain processes or refactoring problematic areas of the code that slow us down. We tried our best to recognize these issues within our team and tell teams to budget a certain amount of time out of their sprints to take this on. This “peanut butter” approach seemed like the right way to go but it was very apparent progress on those items was slow, or abandoned all together, because it was too hard to balance those priorities with the project work teams needed to get done. More often than not, a team would begin their sprints, find new work because of discovery and this additional work would overrun the time we allocated for the Engineering Priorities. Now in this model we make projects out of them and Engineering gets a budget to form a team and take these on every cycle. This brings more focus instead of the context switching within a sprint from project work to something that may not be related.

Cross-pollination of technologies, team processes, best practices and overall learning about the application was low. We had our Agile ceremonies and other meetings to talk about these in a cross-functional setting, but in the end teams would go back and continue to practice what they always had done. As a smaller engineering team I had newer employees tell me they didn’t even know their peers that well on other projects. This just seemed strange given we’re all within a small vicinity of each other. So why not give teams a chance to change up their team composition based off of people they wanted to learn from, processes they wanted to try or technologies they wanted to learn?

Self-Selecting Teams

I Wasn’t Alone

After feeling this way for some time and hearing more and more feedback on how teams felt I began to wonder if it was just me or did others see it. I needed to see if Product felt this way, so I reached out to Derwyn Harris, one of our co-founders that’s in the Product team. Over lunch we discussed what we saw happening with the teams, challenged ourselves on what we thought we wanted out of the teams and talked about teams self-organizing around projects they could make the most impact on. The conversation was all laid on the foundation of empowerment and autonomy with the goal of increasing quality and decreasing lead time. In the end we walked away with a common goal and understanding of what we saw and what we wanted to change.

But wait, there’s more! Cristian Fuentes, one of our Engineering Managers, was also thinking of a way to further protect our team’s priorities to get work out the door, and Shane Patrick, our Sr. QA Manager, was building momentum around a centralized QA Team to help offload regression cycles from the other teams to protect project work. All of our ideas, thoughts and observations were coming to a head, which made it very clear that there was time for change at Jama.

“WE” Weren’t Alone

There was also validation in the industry of others trying models like this and having success. Two of the major players were Spotify and Valve, each doing something a little different but again built on the goal of empowering their engineers to make choices. Using these as case studies to gain confidence in our direction was key.

It Wasn’t Easy

Even though we had all this momentum from a leadership perspective we needed to make sure our teams understood what we were trying to do and why, gain alignment and test our theories. Derwyn created a Circle of Influence diagram to help us identify key stakeholders in the process and their overall support for it. A lot of conversations began with team members to get their feedback, and concerns, that helped us refine our approach. All of this happened over the course of a couple of months, because we knew we needed to make sure this was the right thing to do for Jama and our teams. A successful rollout required patience, listening and a build-up to buy-in.

Let’s Do This!

Now that you have some of the backstory let’s roll into how the teams formed around our priority projects. As of right now, we have an 8-week planning cycle that we plan for. Within those 8 weeks we run sprint lengths of 2 weeks. The goal of this planning cycle is not to load up all the sprints, because we all know that’s impossible and so much changes early on that rearranges your later sprints anyway, the goal is to provide enough clarity so the teams can have solid direction and know the release goals their striving for.

First we need to know our priorities. Product utilizes a process to help calculate this called Weighted Shortest Job First. This method combines a number of different criteria to help us evaluate a project’s importance. We use this method not only on roadmap features, but also on our Engineering priorities. It’s not an exact science but it gets us close.

Once those Product and Engineering priorities have been identified we provide one list for the teams to look at. This helps to bring clarity on the priorities and highlights ones we need to protected so we can get them out the door. Protection comes in different forms but simply put, if there is something a priority project needs, or if there is something that could potentially interrupt that project, teams around them are empowered to figure out creative ways to absorb those risks and keep them on track.

For us to get a good idea for the size of the projects they must also have an estimated duration in sprints and potential roles needed on the project to make it successful. For example, Project Unicorn could take up to 2 sprints to accomplish and it needs 3 Engineers and 2 QA Engineers on it to make it successful. This helps to recognize if a project is staffed appropriately and also exposes potential future scenarios for teams to roll off onto other projects.

Team members then get three votes after the Product Managers, or potentially a Technical Leader of the project, have had a chance to pitch their ideas to the teams. We are now doing this in a Science Fair format before the 8-week planning day. Once they have heard all they need to about the projects, they get to place their #1, #2 and #3 votes on the ones they are the most interested in, or feel they can provide the most value to the business. Once this is done the results tell us a variety of different stories:

  • Were teams able to staff the priority projects so they could be successful?
  • Did team members choose to move away from a project because they could influence higher priority ones?
  • Did we pick up Engineering projects that help with our efficiencies? (Examples: removing technical debt, shoring up infrastructure, increasing automation, etc.)
  • What were the projects that didn’t get chosen and why?

We then record the results and input them into a spreadsheet so we can further evaluate the choices. The goal is to not only make sure the top priorities are staffed, but we also want to do the best we can to place team members on projects that they have chosen (more to come on this). What’s fascinating is the number of scenarios and possible team combinations that you can form by reviewing the choices.

After we’ve done our best to predict where team members next tour of duty might be we open it up for collaboration and discussion. There may be more concerns that we didn’t think about, or other dependencies identified after self-selection has finished, but we try to get as close as we can so people know who they’ll be planning with when we roll into the 8 week planning day.

 

Self-Selecting TeamsThe Results

We are now in our fourth 8-week cycle utilizing this process. We continue to evaluate, change, iterate and find better ways of utilizing this model. Here are some observations after practicing this for a while now.

Priority projects are getting picked up and staffed with the talent they need to succeed. Through the first three 8-week cycles we staffed a lot of projects, and sometimes it was questionable if we were taking on too much. Because of this Product Management wanted to make sure we were not spreading ourselves thin, so we’ve started to implement WIP limits to meet our teams capacity and self-select on fewer projects. At the time of this post we will be starting our first cycle with these limits in place.

Cross-pollination is happening. Team members are learning more from each other. Some may be back end developers getting exposure to the front end, or just different technologies all together. Others may be on teams that are trying new processes such as Mob programming and pairing techniques that follow them to their next team. Agile techniques such as retrospectives, planning, estimating, etc. that are done differently from team to team are being shared. And knowledge of the application as a whole is increasing as team members with diverse experience of the application come together to solve common goals.

Teams are aware of the top priorities and have conversations around how to protect them. Because of this we feel more aligned as a team and are willing to accept project impacts if a team shifts off of theirs to assist in getting the higher ones out the door. The process increases fluidity in our teams to do this when we need to.

Still Working Out the Kinks

We’ve come a long way as a team with this model but are still evaluating and adjusting as we go. We’re far from perfect but I’d like that to be our goal. Here are some areas we continue to refine and recognize:

Not everyone receives a project they voted on. Because we don’t have infinite skill sets amongst team member’s certain projects may require someone with deep domain knowledge or technical skill because without them certain projects would cause risk. The good news is, this has only happened to a very small number of people, for the most part the majority of people get to be on a project that they picked. However, we try to remain sensitive to those that didn’t receive their pick so we can make sure we’re giving them their pick next time we run through our project selection. Long story short, no guarantees depending on business priorities. We have to keep the lights on, right?

We’re trying to “gauge happiness” by sending out surveys asking questions to our engineers. We did our first one in March and if you’re to look at the answers from a 10,000 foot view things look positive, and I do believe the results are exposing a level of happiness, however I’ve retrospected over the survey with my team and the next round we’re going to be more explicit on the questions we were asking, as they were too subjective and open for interpretation. Regardless, we’re trying to measure how people feel in this new model and are paying attention.

We’re getting better at trying to define Engineering Priorities and the value behind them. We want to do a lot of “good stuff” but also realize we only have so many people to do it with. We have to be careful with what we choose, so we can get the biggest bang for our buck.

Metrics, metrics, metrics. We have abandoned some of our metrics because we weren’t sure of the value they were giving us and instead felt more administrative. But we still have to prove the process is working so we’re continually reviewing how to best measure and represent epic lead time and quality measures. Also we still use agile Velocity and Burndowns to see how teams are doing, but those are only snapshots in time so we try to make sure we’re keeping our eye on the prize which is overall health of our projects as they reach completion.

We continue to evaluate work in progress project limits to find the magic number the teams can handle. This model is built to have fluidity in it so we must make sure we protect that as much as possible and aren’t spreading ourselves too thin.

How Do I Get Started?

Maybe this process sounds good to you and you want to try it out, but how do you know if it’s right for your company? I’m sorry to say that I can’t answer that for you. Only you know your culture, problems you have and how this could potentially help you solve them. But what I can do is provide you with some potential thought points for you to think about as you determine if this will work or not.

What problems would you be solving by trying something like this? Make sure you have a clear understanding of these by sharing them with your peers and leadership so you can validate them. This is the start of the buy-in process. If others around you identify the same issues you already have momentum.

Have clear goals that you’re trying to achieve. For example, our goal was to empower our employees to make choices which in theory should decrease epic lead time and increase quality. We’re still measuring these as I pointed out earlier but we are seeing results.

How flexible is your company? Do you already work in a company that’s Agile and accepting of change or do you work in a regulated environment that is change adverse because it may introduce too much risk and uncertainty? If it’s the second, rollout will be slow and painful so find ways within it to make very small, incremental changes that in the end align to your goals.

I mentioned this briefly in the “what problems are you trying to solve” paragraph, but felt it is important enough to give it focus. Make sure you have leadership support. It was key at Jama that we had this from our Engineering and Product VP’s as well as the Director of Product. Without their willingness to let us turn the world upside down and try something different, the idea would have died after initial conversations. They’ve been instrumental in giving us the freedom to implement this while also being very involved in its success.

And last but certainty not least, do you have TRUST? Trust from the business and trust from the people around you? If we didn’t have this, I don’t know where we’d be today. For example, imagine going to your Product Management organization and saying “Hey, those static teams that you’ve relied upon for the last few years, we’re going to blow them up and allow them to do what they want based off of priority”. Talk about a scary message to accept, but we were trusted by those around us that we have the talent and understanding to do the right thing.

So what are you waiting for? Don’t get bogged down and accept your problems that in the end lead to low morale and poor quality products. You’ve hired smart people to do great things. Empower them to do so regardless if it’s something like this model or another idea you have. Be brave, give it a try, iterate on it and change your organization for the better!