Michael "Stix" Lee

Houston We have a Problem

Over the last two decades, Agile processes (Scrum, Kanban, Lean, etc.) have become the de facto standard for app development. Yet these processes have a fundamental weakness: they are highly inefficient in the delivery of large and complex projects. Epics are little more than abstract intentions; Backlogs are a flat collection of Stories; the Stories themselves are compartmentalized to individual teams; and dependencies across teams are handled on an ad hoc basis.

Yet the most glaring issue is Agile’s failure to address the economic and communication needs of primary stakeholders. The decision to build software is primarily an economic decision – with need only a secondary consideration. At some level, those purchasing software “on spec” (i.e. buying software before it is built) need to know beforehand what is being purchased and how much it will cost so an economic determination can be made – “is it worth it?”

Striking a Balance

Balancing economic considerations with the necessity to identify and communicate need requires tradeoffs on how we approach analysis and how requirements are identified, defined, and communicated. But what are these considerations?

Conflicting Needs

All projects share the same basic goals:

• Maximize value. Provide the most capabilities for the least cost.

• Reduce Risk. Reduce or eliminate the impact of project failures.

• Ensure Quality. Guarantee that the delivered system meets the expectations of all stakeholders.

Likewise, all requirements analysis efforts share, to a certain degree, a common set of perceived needs that must be addressed:

• Scope. What are the boundaries of the effort? Where are the boundaries flexible? Where are they fixed?

• Known Cost and Schedule. How much will it cost? How long will it take?

• Value. What are the benefits? Given the cost and schedule, are the resulting

  benefits worth the effort? As things change, how can value be maintained?

• Communication. Are needs and desires clearly, effectively, and unambiguously communicated? How are differing expectations handled (between business and developers; between purchasers and users; between customer and business)?

• Specification. Provide a blueprint that defines the expected behavior of the system. A blueprint used by developers to build the system and by testers to ensure the quality of the system.

• Planning. What needs to happen? When? What resources are required given the size and scope? What are the hard milestones that are driving the effort?

• Certainty. Is every important thing known? How are unknowns dealt with? How is chaos managed and its impact limited?

• Flexibility. How can the project adapt to changing business needs? New and evolving technology? How is the impact of change limited?

Unfortunately, these needs often conflict with each other and also with the overall goals of the project. Over time, analysis approaches have evolved to favor one or more items over others.

How Did We Get Here?

Before Agile became popular, analysis was a separate activity (or phase) in the development life cycle. This “traditional” approach approached analysis as a prerequisite for development. It favored known cost and schedule and the reduction of risk over all other objectives. Decision makers and stakeholders wanted to know before they committed to a project what the costs were and when the software would be delivered. This increased the importance of specification, known cost and schedule and certainty at the expense of communication, flexibility, and maximization of value (figure 1)

“Traditional” Analysis

The approach taken in traditional analysis, along with the artifacts of the process, is indicative of what is important. Significant analysis time is dedicated upfront to ensure all the relevant details have been addressed in the cost and schedule.
In an attempt to reduce risk, monolithic (and often massive) requirements specifications are produced and elaborate change management processes are put in place. The result is a process that is the antithesis of agile and one that often works at cross-purposes with its intended objectives.

The shortcomings of traditional analysis are glaring.

• Time dedicated to upfront analysis is time not spent developing solutions. Too much upfront analysis adds unnecessary cost and decreases the overall value of the delivered software [3] (figure 2).

• “Software requirements are a communication problem” not a specification problem, and monolithic requirement specifications inhibit rather than enhance communication. Effective communication requires collaboration between participants. Requirements specifications rarely, if ever, facilitate collaboration.

• Static requirements increase, not decrease risk.

• Change management processes don’t protect a project against change; they only make change more costly.

• No amount of planning can eliminate all of the unknowns. Fixed schedules and static requirements inhibit a projects flexibility to react to changing situations.

• “No plan survives contact with the enemy.” No matter how much time upfront is spent on planning, something always changes. And the further out the planning goes, the more likely the plan will change.

On the opposite side of the spectrum from Traditional Analysis are the analysis process of Agile delivery, grouped into what is referred to as. “Story-centric” analysis, Story-centric analysis tends to favor maximation of value, communication, and flexibility over all other objectives. A good example of the approach is found in Mike Cohn’s book, User Stories Applied.

Story-centric Analysis

With Story-centric Analysis, decision makers and stakeholders want to ensure the most capability is provided for the least cost in the quickest possible time and with the highest quality. This increases the importance of communication, value, quality, and flexibility at the expense of known cost and schedule, certainty, and scope (figure 3)

Overall, Story-centric Analysis is significantly better (if not overwhelmingly better) than Traditional Analysis and is a near-perfect approach for small-to-medium projects. However, when it comes to large-scale, (potentially) expensive, resource-intensive development efforts, Story-centric Analysis has its limitations.

• Scope tends to be fluid at best and ambiguous at worst. A great deal of attention is given to the parts – user stories and epics – and very little to the whole.

• It doesn’t scale well. Story-centric analysis requires close collaboration within a tight-knit team. The larger the project – in terms of functionality and the number of people involved – the more likely it is that communication will breakdown at organizational boundaries.

• Cost and schedule are ambiguous. When a development effort is tasked with providing the most capability for a fixed price, this is not a problem. But in those situations where one has to deliver a fixed set of features for a specified cost, Story-centric Analysis is ineffective.

• Depth, but little breadth, of detail. One of the purposes of analysis is to gain an understanding of the problem to increase the level of certainty that all relevant areas have been (or will be) addressed. The focus on epics and user stories tends to narrow the focus of analysis and may result in important things being left out.

A Path Forward

As mentioned previously, story-centric analysis doesn’t adequately address the needs of large complex development projects. It often neglects the economic considerations of those footing the bill and is stressed to the point of failure on communicating and managing scope.

So what’s the answer?

Just-in-Time Analysis

Just-in-Time Analysis is an agile approach to the discovery and communication of requirements specifically tailored for large, (potentially) expensive, resource-intensive, enterprise-class development efforts. It combines the best features of Story-centric analysis with the familiarity of Traditional Analysis. Its primary focus is on maximization of value, communication, and flexibility while at the same time recognizing and addressing the needs of decisions makers on large projects - known cost and schedule, certainty, and scope. (figure 4)

Just-in-Time Analysis is a flexible, agile approach for the discovery and communication of scope and stories. It is based on a handful of guiding principles:

• Last Responsible Moment. This is the fundamental principle of JITRA (the “Just-In-Time” part of Just-In-Time Requirements Analysis). Detailed analysis is deferred until the last responsible moment before requirements are needed.

• First-Things-First. Analysis is always focused on the most important things (as defined by the business, not developers). This requires the business to constantly assess and prioritize their needs.

• Understand the Problem. Analysis is not just about identifying and communicating requirements (i.e. need). It is an activity that allows organizations to gain a better understanding of the problem. This understanding can then be used to drive economic decisions.

• Collaborative Communication. Constant and effective communication between all participants in the analysis process is critical. Use all means available to communicate clearly and effectively and adapt the means of communication to fit the participants.

• Equality of Value. Once a project cost has been fixed, Equality of Value allows decision makers to adapt or change functionality while managing to the same fixed price. This is a key principle of JITRA and meets the critical need of decision makers to predict and manage costs - while at the same time preserving flexibility and agility.

• Concurrent Engineering. With the possible exception of some initial analysis, all analysis activities for follow-on development should be occurring in parallel with current development. This compacts the life cycle and increases value at delivery (although it may introduce added risk).

• Maximization of Value. Analyze value as well as functionality. Always examine the trade-off between need and benefit while focusing on the maximization of value.

• Focus on (Early) Delivery. The goal of analysis is delivery of software, not requirements specifications. In the history of software development there has never been a single requirements specification that has generated revenue for the organization purchasing the software*.

• Learn By Doing. Analysis needs to be an active process. One of the objectives of analysis is to learn more about a problem (“discovery”), and often the best way to learn is by doing. (Of course, requirements specifications produce significant revenue for those consulting firms tasked with producing them. But that’s another story....)

• Continuous Analysis. JITRA is a continuous process of feedback and refinement. What we know tomorrow will always be more than what we know today. New knowledge needs to be continuously fed back into the analysis process and requirements need to be continuously analyzed and refined based on the new knowledge.

• Continuous Planning. Prioritized requirements drive planning. Since requirements and businesses priorities are constantly changing, planning must be continuous.

• Embrace Change. The JITRA process facilitates and embraces change. Instead of relying on elaborate change management procedures, JITRA allows (and in some cases encourages) changes to occur at anytime. Changes are simply treated as requirements that must be analyzed and prioritized as part of a continuous analysis process.

• Isolation of Complexity. Complexity adds cost, decreases value and makes things harder to change. Don’t make the problem more complex that it needs to be. But where complexity is required, isolate it.

• Constant and Continuous Improvement (Kaizen). As new knowledge is fed back into continuous analysis, always look to improve on existing requirements. Refactoring applies to requirements just as much as it does to code.

Want to Learn More?

Just-in-Time analysis significantly reduces project risk and shortens development time. First developed in the early 2000s, It ensures the most important parts of a system – as defined by the business stakeholders - are being worked on at any given point in time and only defines requirements when they are needed. It supports the evolution of requirements and provides mechanisms for easily incorporating changes into the analysis process. It shortens development time by continuously performing analysis concurrent with development rather than in sequence prior to development. In short, Just-in-Time Analysis matches the vision and promise of agile development and perfectly compliments agile development approaches.

To learn more, download these articles: Just-in-Time Analysis, the Engine Driving the Planning Game and Just-in-Time Analysis, an Agile Approach to an Age-Old Problem. Or better yet, feel to reach out directly at michael.lee.1983@icloud.com