Agile Analysis: Strategies for Agile Software Teams

Agile software developers, just like traditional software developers, perform analysis activities. Unlike traditional developers, agilists approach analysis in a highly collaborative manner and do so on a just-in-time (JIT) basis. Analysis is so important to us we do it every single day. In this article, I describe agile analysis and related topics:

1. What is Analysis?

The purpose of analysis is to understand what will be built, why it should be built, how much it will likely cost to build (estimation), and in what order it should be built (prioritization). This is similar to requirements elicitation, the purpose of which is to determine what your users want to have built. The main difference is that the focus of requirements gathering is on understanding your users and their potential usage of the system, whereas the focus of analysis shifts to understanding the system itself and exploring the details of the problem domain. Another way to look at analysis is that it represents the middle ground between requirements and design, the process by which your mindset shifts from what needs to be built to how it will be built.

2. What is Agile Analysis?

Let’s begin by describing what agile analysis isn’t a:

Phase in the lifecycle of your initiative
Task on your schedule
Means unto itself>

What is agile analysis? From the previous discussion of what an agile business system analyst does, your agile analysis efforts should exhibit the following traits:

Agile analysis should be communication rich. Agile developers prefer warm communication techniques such as face-to-face discussion and video conferencing over cold techniques such as documentation and email. This is described in the Communication article. Agile developers prefer to work as closely as possible to their stakeholders, following AM’s Active Stakeholder Participation practice wherever possible.
Agile analysis is highly iterative. As Martin (2002) points out analysis and design activities both rely on each other: estimating is part of analysis yet that relies on some design being performed to identify how something could be implemented and your design efforts rely on sufficient analysis being performed to define what needs to be built. Hence analysis is iterative.
Agile analysis is incremental. Martin (2002) also correctly points out that agile analysis is incremental, that you don’t need to build systems all in one go. This philosophy supports the incremental approach favored by common agile software processes where the work is broken done into small, achievable “chunks” of functionality. These chunks should be implementable within a short period of time, often as little as hours or days.
Agile analysis explores and illuminates the problem space. Your primary goal is to identify and understand what your stakeholders need of your system. Furthermore, this information needs to be communicated to everyone involved with the initiative, including both developers and stakeholders. This promotes understanding of, and agreement with, the overall vision.
Agile analysis includes estimation and prioritization of requirements. It is during estimationand prioritization of requirements where software development becomes real for stakeholders. It is very easy to say that you want something but much hard to agree to a price for it, let alone to trade it off for something that is immediately more important to you.
Agile analysis results in artifacts that are just good enough. If any artifacts are created at all as the result of your agile analysis (you’ll be following the AM practice Discard Temporary Models after all) they should be either agile models or agile documents. Such artifacts are typically far from perfect, they just barely fulfill their purpose and no more.

Here is my definition for agile analysis:

Agile analysis is highly evolutionary and collaborative process where developers and stakeholders actively work together on a just-in-time (JIT) basis to understand the domain, to identify what needs to be built, to estimate that functionality, to prioritize the functionality, and in the process optionally producing artifacts that are just barely good enough.

3. Agile Analysis Through the Lifecycle

Figure 1 depicts the lifecycle of Agile Model Driven Development (AMDD). During “sprint 0“, the first sprint/iteration of an agile initiative, you need to get your team organized and going in the right direction. Part of that effort is the initial envisioning of the requirements and the architecture so that you are able to answer critical questions about the scope, cost, schedule, and technical strategy. Details about the business domain are identified on a just-in-time (JIT) basis during iterations via initial iteration modeling at the beginning of each iteration or by modeling storming throughout the iteration. Analysis is so important to agilists that we do it every day.

Figure 1. The Agile Model Driven Development (AMDD) lifecycle (click to enlarge).

4. Some Potential Agile Analysis Models

Are the artifacts created taking an agile approach to analysis any different than the ones created as the result of traditional analysis? In a way they are. They are in fact the same types of artifacts, a use case diagram is a use case diagram after all, but the way in which they are created are different. The artifacts are created following the principles and practices of AM, they are just barely good enough and are often discarded so as to travel light.

Table 1 lists common artifacts used during analysis modeling and suggests a simple tool with which you could create such an artifact. It is interesting to note that this list is meant to be representative, a more thorough list is presented in the article Artifacts for Agile Modeling and in the book Agile Modeling.

Table 1. Candidate artifacts for analysis modeling.

Artifact	Simple Tool	Description
Activity Diagram	Whiteboard	UML activity diagrams are used during analysis modeling to explore the logic of a usage scenario (see below), system use case, or the flow of logic of a business process. In many ways activity diagrams are the object-oriented equivalent of flow charts and data-flow diagrams (DFDs).
Class Diagram	Whiteboard	Class diagrams show the classes of the system, their inter-relationships (including inheritance, aggregation, and association), and the operations and attributes of the classes. During analysis you can use class diagrams to represent your conceptual model which depict your detailed understanding of the problem space for your system.
Constraint definition	Index card	A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements for your initiative.
CRC model	Index cards	A Class Responsibility Collaborator (CRC) model is a collection of standard index cards, each of which have been divided into three sections, indicating the name of the class, the responsibilities of the class, and the collaborators of the class. Like class diagrams, CRC models are used during analysis modeling for conceptual modeling.
Data flow diagram (DFD)	Whiteboard	A data-flow diagram (DFD) shows the movement of data within a system between processes, entities, and data stores. When analysis modeling a DFD can be used to model the existing and/or proposed business processes that your system will support.
Entity/Relationship (E/R) diagram (data diagram)	Whiteboard	E/R diagrams show the main entities, their data attributes, and the relationships between those entities. Like class diagrams E/R diagrams can be used for conceptual modeling, in many ways E/R diagrams can be thought of as a subset of class diagrams.
Flow chart	Whiteboard	Flow charts are used in a similar manner to activity diagrams.
Robustness diagrams	Whiteboard	Robustness diagrams can be used to analyze usage scenarios to identify candidate classes and major user interface elements (screens, reports, …).
Sequence diagram	Whiteboard	Sequence diagrams are used to model the logic of usage scenarios. Sequence diagrams model the flow of logic within your system in a visual manner, enabling you to both explore and validate your logic.
State chart diagram	Whiteboard	State chart diagrams depict the various states, and the transitions between those states, that an entity exhibits. During analysis modeling state chart diagrams are used to explore the lifecycle of an entity that exhibits complex behavior.
System use case	Paper	A use case is a sequence of actions that provide a measurable value to an actor. A system use case includes high-level implementation decisions in it. For example, a system use case will refer to specific user interface components – such as screens, HTML pages, or reports. System use cases will also reflect fundamental architectural decisions, such as the use of ATMs versus cell phones to access your bank account.
UI prototype	Whiteboard	A user interface (UI) prototype models the user interface of your system. As a part of analysis modeling it enables you to explore the problem space that your system addresses in a manner that your stakeholders understand. Remember, the user interface is the system to most people.
Usage scenario	Index card	A usage scenario is exactly what its name indicates – the description of a potential way that your system is used.
Use case diagram	Whiteboard	The use-case diagram depicts a collection of use cases, actors, their associations, and optionally a system boundary box. When analysis modeling a use case diagram can be used to depict the business functionality, at a high-level, that your system will support. It can also be used to depict the scope of the various releases of your system via the use of color or system boundary boxes.

5. Agile Analysis and the Role of Analysts

Analysis is a very important activity on any software development initiative, regardless of paradigm. It is an organizational design decision to define what roles you will have and what those roles will do. In traditional development there is often someone(s) in the role of analyst, and some organizations even choose to distinguish between analyst types and will have system analysts (SAs), business analysts (BAs), business system analysts (BSAs), data analysts, process analysts, and so on. In agile development we make different organizational design decisions. So, although we still perform analysis we haven’t made the decision to have someone in that specific role.

If you are an existing BA, here are a few strategies which you may want to consider when moving to agile software development:

Recognize that agile teams are made up of generalizing specialists instead of specialists (such as analysts). Your analysis skills are valuable, and are clearly a good start, but you need to be able to do more. Be prepared to work closely with other team members to help transfer your skills to them and to pick up new skills from them.
A business analyst, particularly one from the business side, may take on the role of stakeholder/customer/product owner on an agile team, representing the stakeholder community (see Figure 2). They may also lead an initial requirements envisioning effort during Sprint 0 .
For more details, see the article Rethinking the Role of Business Analysts.

Figure 2. BSA as Product Owner (click to enlarge).

Product owners

6. Conclusion

The nature of analysis has changed. Several decades ago analysis was seen as a transformational process within a serial lifecycle. With the rising popularity of object-orientation in the 1980s and 1990s analysis was soon seen as part of an iterative and incremental process, and in the new millennia the nature of analysis is transforming once again. Today analysis is better envisioned as a highly collaborative, iterative, and incremental endeavor involving both developers and stakeholders. The evolution of the analysis process necessitates an evolution in the way that business system analysts (BSAs) work, and in many situations this role arguably disappears in favor of developers who are generalizing specialists.

7. Acknowledgements

I’d like to acknowledge the input of the following people: James Bielak, Adam Geras, Ron Jeffries, Kent J. McDonald, Les Munday, Paul Oldfield, Stephen Palmer, Tom Pardee, Dave Rooney, Gabriel Tanase, and Paul Tiseo.