Software Agile (Development)

Agile software development, as a method, subscribes to the Agile Manifesto. The focus of these methods is on producing a working code (or its equivalent). Individuals have substantial freedom in following these methods and, yet, they are considered an integral part of the team. Contemporary Agile, understood as a method, provides key guidance at the software project level. For example, through Agile principles, the users are made part of the development team. Such collaboration bridges the gap between specifications and the end product. Agile, through its short and sharp iterations, also ensures that the product reaches the users as soon as practicable. Since the methods are themselves Agile, the only Agile touch points of interest to these methods are the nonsoftware areas of work in the organization. For example, Agile principles such as simplicity, transparency, and courage become extremely interesting when they are applied in business functions such as accounting and HR. CAMS is interested in elevating and using the Agile values and principles across an entire organization and not just software projects. Thus, in CAMS, Agility also gets used in business analysis, testing, modeling, and architecture.


Business Analysis
Business analysis deals with elicitation of requirements, planning, and managing the requirements documentation, analyzing requirements, understanding and communicating business needs to all stakeholders continuously, and providing input into the solution. The practice of business analysis uses a wide array of techniques. For example, high-level business needs are explored using mind mapping, root cause analysis, and SWOT analysis. Detailed requirements modeling is undertaken with use case modeling, activity graphs, and Business Process Modeling Notation (BPMN) diagrams.

Understanding and modeling of the problem enables balancing the various factors (and risks) associated with a problem. This, in turn, enables a business analyst to arrive at an appropriate recommendation for the solution. Business analysis recommendations consider the fact that IT-based solutions may not be the only way to solve business problems. Business analysis processes aid decision making at the organizational level. For example, business analysis considers business needs and weighs it against the risks (e.g., through a SWOT analysis). The output of this analysis can assist business in taking the correct decisions. Agile values of collaboration and trust can be brought into this decision making. Business analysis is also undertaken in software projects at a requirements modeling level. Thus, business analysts model functional, nonfunctional, and interface requirements. Features can also be written as user stories written on story cards. The Agile touch points with business analysis are explored further in CAMS.


Testing
Testing represents a wide array of activities that occur in both software and business processes as well as in projects, and across the organization. For example, testing can occur in an Agile project almost on a daily basis (continuously) whereas, in the same project, the user acceptance test may occur right at the end of a release. Testing may occur for the process of recording a customer complaint in a call center environment, or it may test the carbon emission of a process during business as usual (BAU). Testing needs its processes and frameworks that will help and guide the testing process. Depending on the project demographics as well as organizational situations, testing frameworks have to change to reflect those specific needs. Testing also has to relate to the QA activities being undertaken in a project as the QA activities are aimed at preventing errors (as against testing, which is focused on detecting errors). While standards such as the ISO9001 have been popular in the overall QA area, there are specific testing standards and frameworks for testing that are of interest to composite Agile. For example, the testing framework as assessed by the ISTQB has a positive role to play in providing formal testing activities and tasks that can be carried out in composite Agile. The ISTQB is working on a Testing Body of Knowledge (TBOK) 2 that provides a suite of principles for testing that can be embedded with the Agile principles and practices. For example, the formal activity of "test planning" can make use of the Agile principle of collaboration; and the "testing" activity itself can use the Agile practice of continuous testing as the code is being developed.


Modeling and Architecture
Modeling and architecture are primarily derived from the planned approaches to software development. They can also be applied in other nonsoftware projects where modeling is a mechanism of creating a blueprint of a problem or solution without actually developing the full solution. Therefore, modeling can significantly enhance the quality of a product—as it enables discussions, clarifications, and management of expectations. Architecture, which is also based on the creation of models, is aimed at specifying the constraints applicable in understanding a problem and putting together a solution. Thus, both modeling and architecture rely heavily on visual diagramming techniques aimed at enhancing problem solving. These techniques are discussed next with a view to understanding their standards and frameworks so that they can operate together with Agile principles and practices.


Modeling
Within the software domain, the earliest modeling effort was through flowcharts and programming sheets. This effort was quickly followed by entity-relationship (ER) and data-flow diagram (DFD) techniques, made popular during the relational database (RDB) era. Later, in the mid-1990s, the Unified Modeling Language (UML, current version 2.0) of the OMG (www.omg.org) became the de facto modeling standard for analysis and design. Modeling, through the UML, can be carried out in understanding the problem, casting the solution, and understanding the background constraints and limitations. Thus, the modeling effort in UML occurs in problem, solution, and background spaces (Unhelkar). The UML came about as a combination of the three most popular methodologies of that time: Booch (1994), Object Modeling Technique (OMT) (Rumbaugh et al.), and Objectory (Jacobson et al., 1993). Later several other methodologies merged into it, resulting in the current, formal UML version 2.0. This has resulted in 13 official diagrams in the UML—some of which offer excellent opportunity to boost Agility in practice. The rigors of the UML metamodel and the opportunities through model-driven architecture (MDA) can provide the robustness, and the Agile principles and practices provide the flexibility in a composite Agile project. Combining the collaborative and customer-centric principles of Agility with the formality of UML diagrams provides excellent value and quality in practice.

Consider, for example, the four different ways in which UML is meant to add value in software projects. These four ways of UML usage can benefit the use of Agile principles and practices as briefly discussed.

1. Visualizing: This is the primary purpose of the UML; its notations and diagrams provide an excellent industry standard mechanism to represent pictorially the requirements or business processes, solution, and architecture. Placing UML models on large, visible charts within software projects can be a useful way of applying Agile practice. Use case diagrams and activity diagrams also provide excellent means to present the requirements of a user. Combining these formal visual techniques with the story cards of Agile provides both control (traceability) and flexibility of a project.

2. Specifying: Together with visual representations, UML also facilitates specification of some of the artifacts. This includes specifications for actors, use cases, classes, attributes, operations, and so on. Specifications can provide the details of a model and thereby open up opportunities for applying quality techniques. Although pure Agile approaches are not too keen on in-depth specifications, Agile principles such as simplicity in design and acceptance of changes can be carried out in a much easier manner through detailed and formal specifications. For example, specifications of a feature on a user story can be inserted in the specifications of a use case and, thereby, formalized and controlled in a project.

3. Constructing: UML can also be used for software construction as it is possible to generate the basic code (C++, Java, VB, Smalltalk) from UML visual representations, depending on the CASE tool being used. The current literature on Executable UML also suggests that UML can and will be increasingly used in construction of software. This "construction" usage of UML comes closest to what the Agile methods talk about. Agility can play an important role in promoting the construction of software using UML—as it is much easier and faster to use Executable UML as against an executable code.

4. Documenting: With the help of UML, additional and detailed documentation such as requirements, architecture, design, project plans, tests, and prototypes can be provided to enhance specifications and visual representations. Agile, as understood in software domain, is not focused on creating substantial documentation. However, the composite Agile approach pays' significant attention to documentation. 


Architecture
The architecture provides the basis for structural stability that can apply to both BAU operations of an organization and the new initiatives and projects. Architecture can be understood as an abstraction of the systems and processes in an organization. Specific architectural frameworks, such as TOGAF and the Zachmann framework, also include people, in addition to processes and mechanism, to change/transform an organization.

Agile methods recommend just enough architecture and design. There is no detailed and long-drawn art architectural exercise in Agile projects. This may well work for straightforward development projects. However, creation and adherence to architecture is important in any kind of project. Typically, an EA provides a bird's-eye view of all of the IT assets of the organization. An EA can be an all-encompassing model of an organization's technical (IT) architecture, systems, contents (databases), interfaces, applications, networks, and solutions. Such a view enables understanding and balancing of risks in taking technical and business decisions. EA can also enable alignment of these aforementioned elements with the business strategic objectives and vision (McGovern et al., 2004). Thus, architectures enable consideration of the enterprise-wide effect of technical decision making. Architectures are made up of a suite of guidelines, patterns, and corresponding frameworks. These frameworks standardize the application of architectures within an organization and also help their understanding across an industry.Here is a brief mention of TOGAF primarily from its Agile touch points. TOGAF is based on the following four layers of architecture.

1. Business architecture defines business strategy, governance, organization, and key business processes; Agile principles can be used in order to collaborate with key business stakeholders to arrive at the business architecture. The governance and organizational structure of the business can also benefit by the application of Agile principles and practices that enable change.

2. Data architecture defines the structure of an organization's logical and physical data assets and associated data management resources; prototypes and UML's class models can be used together to create models (schema) of data architecture.

3. Application architecture specifies individual application systems and their deployment—which can be supported by Agile's iterative and incremental releases and flexible requirements capturing; UML's package and component diagrams can be used to create a distributed application architecture.

4. Technology architecture specifies the software infrastructure intended to support the deployment of core, mission-critical applications. UML's state diagrams can be used for real-time modeling and deployment diagrams for modeling the overall technology architecture.

Creating and using visual models of the above architectures provides the basis for discussions of constraints and limitations on how the user stories or features are developed. These architectural considerations enable an understanding of the dependencies that stories have on each other. Furthermore, EAs are not created specifically for an Agile project; instead, they are organizational-level models that provide the basis and input for Agile projects.

Taken from : The Art of Agile Practice: A Composite Approach for Projects and Organizations