JAD Team Roles

A JAD team is made up of several different roles, each with separate responsibilities. Some references identify as many as 10 different roles, but most agree on six basic roles:

• Executive Sponsor—This individual is typically the manager or executive of the business unit that will operate or own the finished product of the project. As such, this team member is also the decision-maker, problem-solver, and resource provider.

• Project Manager/Facilitator—This team member has the responsibilities of managing and planning the activities of each of the JAD sessions. The Project Manager must coordinate with the Executive Sponsor to keep the project focused on identifying the requirements of the product to be created.

• Stakeholders—Without stakeholder contributions, there is essentially no “joint” in JAD. Stakeholders provide input from an end user’s point-of-view, preferably from different levels of an organization.

• Recorder—This team member has the responsibility of documenting the JAD proceedings and the ideas, suggestions, discussions, and decisions of each session.

• Technical Advisor—Typically this individual is an IT representative who provides technical input and assists in the development of logical models for the project’s outcomes.

• Observer—This role is not always a part of a JAD team, especially when the project scope is simple or narrowly defined. When an observer does participate, he or she attends the JAD sessions and observes the proceedings objectively.

JAD Sessions and Workshops

JAD sessions are scheduled and chaired by the Project Manager, who invites all members of the JAD team, including any observers and technical advisors. The purpose of each JAD session is to initiate ideas and suggestions that may provide the best solution to the issues of a User Story. JAD sessions, when integrated into an Agile framework, are usually a part of either the requirements phase or the development phase.

At some point in the project, the ideas and suggestions documented in JAD sessions will require decisions to be made. In a JAD Workshop, the Executive Sponsor and any other key decision-makers join the discussion to hear the questions and discussion points that have come from the JAD sessions. If decisions cannot be made, further sessions and workshops may be needed.

DevOps

DevOps, which is the acronym for the Software Development (Dev) and IT Operations (Ops) deployment methodology, combines an organization’s software development and IT operations resources into one team that work in parallel and collaboratively throughout the development and deployment of a software solution. The overall goal of DevOps is to break down the roadblocks that have existed between the legacy approaches to software development and IT operations.

The DevOps philosophy is built on what is called the CAMS model. CAMS is an acronym for Culture, Automation, Measurement, and Sharing, which are the key principles of DevOps. As depicted in Figure 12-5, the CAMS model can be viewed as a pyramid made up of layers, each of which provides a foundation for the principle above it.

The key principles of DevOps are as follows:

• Culture—Every organization has a unique culture that is created from the management philosophy, the beliefs and actions of its employees, its location, its building and environment, and many other factors. In the context of DevOps, culture is defined to require the following characteristics in the organization:

  • Create a collaborative work environment

  • Eliminate the assignment of blame

  • Empower organization-wide responsibility

  • Motivate continuous improvement

  • Automate continuous improvement and continuous deployment (CI/CD)

  • Prioritize the needs of customers and clients

  • Learn from failure

  • Combine expertise

• Automation—Many people who are new to the DevOps methodology believe that it requires the automation of everything possible. Not sure if that would be a good or bad thing, but that is not what DevOps means by automation. The automation principle of DevOps relates to frequently applied, repetitive, and manual tasks that can be performed to their completion without needing human assistance. DevOps automation reduces the development life cycle, human error, and the size of the development team.

• Measurement—One of the key objectives of DevOps is continuous improvement. To ensure that is happening, DevOps team members must capture and analyze performance and effectiveness data, which includes business operational data and metrics from the software development life cycle. Each organization will have its unique collection of metrics, but there are also a few standard metrics that can be used, depending on the organization’s products, services, or mission, such as the mean time to recovery (MTTR), mean time to failure (MTTF), and recovery time objective (RTO), among others.

• Sharing—A basic premise in DevOps is that team members, and possibly nonparticipants, share ideas, share data, and share results. The requirement of continuous improvement requires the input of shared data and information. Teams are more effective and efficient when the team members share their ideas and solutions.

The DevOps philosophy and methodology originated in the philosophy of Agile, from which it retained its emphasis on shorter development periods, continuous improvement, and the continuous deployment of quality products. Many of its key principles, such as automation, sharing, and collaboration, also came from Agile.