Where are the JAD Sessions (Requirements Gathering Workshops)?
According to a recent Gartner Group paper, “expertise in requirements gathering has declined as the use of JAD sessions (Requirements Gathering Workshops) fell out of favor in the late 1990s”1. For those not familiar with the concept, JAD stands for “Joint Application Development” (originally “Joint Application Design”, but over time it morphed).
The general idea of JAD (Requirements Gathering Workshop) was to assemble a cross-functional team consisting of subject matter experts and systems analysts/developers. Put this group off-site under the direction of a skilled and motivated facilitation team, this group could define high-quality business and stakeholder requirements in a week. What caused this decline in the use of this phenomenally effective tool? Let us examine the possible causes of its decline and suggest why the time is right to bring the JAD approach back into common use – albeit under a new name to account for the evolution in how IT solutions are developed today.
Getting and Writing IT Requirements in a Lean/Agile World
Upon completion of this course, you can:
- Define the capabilities and challenges of Lean and Agile software development philosophies
- Adapt 10 different requirements gathering (elicitation) techniques to Lean, Agile, and Continuous Delivery software development environments
- Support Lean or Agile teams by expressing business needs and wants in formats that optimally support all modern Software Development Methodologies (SDM)
- Drill-down into requirements, features, user stories, and functions to identify and express test scenarios in Given-When-Then statements to facilitate automated testing
- Identify 17 types of Non-Functional Requirements (NFR) and develop Given-When-Then (GWT) test scenarios for them
Why the Decline?
The decline was caused by a combination of factors. One of the main causes was the Y2K event that sidelined software development for four to six years. JAD sessions (Requirements Gathering Workshops) were not really applicable to the Y2K process because most of the requirements were defined by IT personnel and the need for interaction with the business community declined. Ergo, the exercise of JAD skills atrophied. The second was the “trimming” of the business community. Downsized business units no longer had the resources to devote the time needed for JAD sessions (Requirements Gathering Workshops). The third factor was the pent-up demand for software development. The backlog that has existed since IT’s infancy was exacerbated by the necessity for focus on Y2K fixes.
Where are we today?
OK, Y2K is just a distant memory and yet the surge in JAD (Requirements Gathering Workshops) usage is lacking. Outsourcing evolved as a potential solution. A seemingly unlimited pool of external resources can be tasked with development work while the IT department keeps things running on the home front. Unfortunately, for outsourcing to be successful, the requirements have to be much more clearly and rigorously defined then ever before. The increase in clarity and rigor is necessary to ensure the quality and the timeliness of the deliverable. To solve this dilemma, some organizations decided to eliminate their IT department’s involvement and have the outsourcing company determine the requirements themselves. This capitulation of responsibility is the IT industry’s version of the “fox in the henhouse” fable.
Along came Agile, an iterative and incremental development approach. Although very powerful, one of its weaknesses is that future, incremental releases can require a considerable amount of “refactoring” or rewriting of production code. This can only be avoided if the business requirements are clearly defined in the beginning of the project. If not, you are solving today’s problems by spending tomorrow’s resources.
Lean Business Use Cases in an Agile World – Simply Put!
Upon completion of this course, you can:
- Document user interaction in Lean Use Cases descriptions and diagrams
- Define and defend the need for Lean Use Cases
- Describe the major components of a Lean Use Case
- Determine how to handle alternate and exception situations
- Extract Use Cases from a Vision Statement
- Apply Business Event Analysis to discover Lean Use Cases based on business activities
- Analyze business scenarios to discover Lean Use Cases
The Now and Future JAD (Requirements Gathering Workshops)
To get the SME’s involved at the right time in our projects, we need to rebuild our requirements discovery expertise and we need to make the most efficient use of the SMEs’ limited availability. JRP (Joint Requirements Planning) is a JAD-like approach that focuses on business requirements. The key success factors in a JRP are the facilitation team’s command of a complete set of requirements determination methods combined with the ability to plan and facilitate short, directed, time-boxed sessions. This is what we need to meet the conflicting demands placed on the business community and the IT resource.
Many organizations are realizing better business satisfaction with delivered information technology by recapturing the art and science of requirements discovery. JRP sessions deliver the right requirements. Better business requirements early in the project create a richer, more comprehensive base to draw upon for the iterative process that is at the core of the Agile movement. Outsourcing can also be a very lucrative alternative if the right business system requirements are defined up front.
1 Gartner # G00126310
