» AN AGILE VIEW OF PROCESS
» AGILE PROCESS MODELS
» EXTREME PROGRAMMING(XP)
» ADAPTIVE SOFTWARE DEVELOPMENT(ASD)
» DYNAMIC SYSTEMS DEVELOPMENT METHOD(DSDM)
» SCRUM
» CRYSTAL
» AGILE MODELING(AM)

AN AGILE VIEW OF PROCESS

In 2001, Kent Beck and 16 other noted software developers, writers, and consultants (referred to as the “Agile Alliance”) signed the “Manifesto for Agile Software Development. “ It started:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contact negotiation

Responding to change over following a plan

That is, while there is value in the items in the right, we value the items on the left more.

A manifesto is normally associated with an emerging political movement—one that attacks the old guard and suggests revolutionary charge (hopefully for the better). In some ways, that’s exactly what agile development is all about.

Although the underlying ideas that guide agile development have with us for many years, it has only been during the past decade that ideas have crystallized into a movement.” In essence, agile methods were developed in an effort to overcome perceived and actual weakness in conventional software engineering. Agile development can provide important benefits, but it is not applicable to all projects, products, people, and situations. It is also not antithetical to solid software engineering practice and can be applied as an overriding philosophy for all software work.

In the modern economy, it is often difficult or impossible to predict how a computer- based system (e.g., a Web- based application) will evolve as time passes. Market conditions change rapidly, end- user needs evolve, and new competitive threats emerge without warming. In many situations, we no longer are able to define requirements fully before the project begins. Software engineers must be agile enough to respond to a fluid business environment.

Does this mean that a recognition of these modern realities causes us to discard valuable software engineering principles, concepts, methods, and tools? Absolutely not! Like all engineering disciplines, software engineering continuous to evolve. It can be adapted easily to meet the challenges posed by a demand for agility.

What is it? Agile software engineering combines a philosophy and a set of deployment guidelines. The philosophy encourages customer satisfaction and early incremental delivery of software: small, highly motivated project teams; informal methods; minimal software engineering work products; and overall development simplicity. The development guidelines stress delivery over analysis communication between developers and customers.

Who does it? Software engineers and other project stakeholders (managers, customers, end users) work together on an agile tam--- a team that is self- organizing and in control of its own destiny. An agile team fosters communication and collaboration among all who serve on it.

Why is it important? Agile development might best be termed “software engineering lite.” The basic framework activities--- customer communication, planning, modeling, construction, delivery and evaluation----- remain. But they morph into a minimal task set that pushes the project tam toward construction and delivery (some would argue that this is done at the expense of problem analysis and solution design).

What is the work product? Customers and software engineers who have adopted the agile philosophy have the same view---- the only really important work product is an operational “software increment” that is delivered to the customer on the appropriate commitment date.

How do I ensure that I’ve done it right? If the agile team agrees that the process works and the team produces deliverable software increments that satisfy the customer, you’ve done it right.

Tom DeMarco: “Agility; 1, everything else: 0.”

In a thought- provoking book on agile software development, Alistair Cockburn argues that the prescriptive process models introduced, have a major failing: they forget the frailties of the people who build computer software. Software engineers are not robots. They exhibit great variation in working style computer software. Software engineers are not robots. They exhibit great variation in working style and signification differences in skill level, creatively, orderliness, consistency, and spontaneity. Some communicate well in written form, others do not. Cockburn argues that process models can “deal with people’s common weakness with [either] discipline or tolerance” and that most prescriptive process models choose discipline. He states: because consistency in action is a human weakness, high discipline methodologies are fragile.”

If process models are to work, they must provide a realistic mechanism for encouraging the discipline that is necessary, or they must be characterized in a manner that shows “tolerance” for the people who do software engineering work. Invariably, tolerant practices are easier for software people to adopt and sustain, but (as Cockburn admits) they may be less productive. Like most things in life, trade- offs must be considered.

Definition:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements even late in development. Agile processes harness change for the customer’s competitive advantages.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with the preference to the shorter timescale.

4. Business people and developers must work together daily throughout the projects.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face to face conversion.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity- the art of maximizing the amount of work not done- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then turns and adjusts its behavior accordingly.

AGILE PROCESS MODELS

In the sections we present an overview of a number of different agile process models.

What is An Agile Process?

Any agile software process is characterized in a manner that addresses three key assumptions about the majority of software projects:

1. It is difficult to predict in advance which software requirements will persist and which will change. It is equally difficult to predict how customer priorities will change as a project proceeds.

2. For many types of software design and construction are interleaved. That is both activities should be performed in tandem so that design models construction is used to prove the design.

3. Analysis, design, construction, and testing are not as predictable (from a planning point of view) as we might like.

Given these three assumptions, an important question arises: How do we create a process that can manage unpredictability? The answer, as we have already noted, lies in process adaptability (to rapidly changing project and technical conditions). An agile process, must be adaptable.

But continual adaption without forward progress accomplishes little. Therefore, an agile software process must adapt incrementally. To accomplish incremental adaption, an agile team requires customer feedback (so that the appropriate adaptations can be made). An effective catalyst for customer feedback is an operational prototype or a portion of an operational system. Hence, an incremental development strategy should be instituted. Software increments (executable prototypes or a portion of an operational system) must be delivered in short time periods so that adaptation keeps pace with change (unpredictability). This iterative approach enables the customer to evaluate the software increment regularly, provide necessary feedback to the software team, and influence the process adaptations that are made to accommodate the feedback.

Martin Fowler: “There is no substitute for rapid feedback, both on the development process and on the product itself.”

The Politics of Agile Development
There is considerable debate (sometimes strident) about the benefits and applicability of agile software development as opposed to more conventional software engineering processes. Jim Highsmith (facetiously) states the extremes when he characterizes the feeling of the pro-agility camp (“agilists”). “Traditional methodologists are a bunch of stick- in –the- muds who’d rather produce flawless documentation than a working system that meets business needs.” As a counterpoint, he states ( again, facetiously) the position of the traditional software engineering camp; “Lightweight, er, ‘agile’ methodologists are a bunch of glorified hackers who are going to be in for a heck of a surprise when they try to scale up their toys into enterprise- wide software.”

Like all software technology arguments, this methodology debate risks degenerating into a religious war. If warfare breaks out, rational thought disappears and beliefs rather than facts guide decision-making.

No one is against agility. The real question is: What is best way to achieve it? As important, how do we build software that meets customers’ needs today and exhibits the quality characteristics that will enable it to be extended and scaled to meet customers’ needs over the long term?

There are no absolute answers to either of these questions. Even within the agile school itself, there are many proposed process models, each with a subtly different approach to the agility problem. Within each model there is a set of “ideas” (agilists are loathe to call them “work tasks”) that represent a significant departure from conventional software engineering. And yet, many agile concepts are simply adaptations of good software engineering concepts. Bottom line: there is much that can be gained by considering that best of both schools and virtually nothing to be gained by denigrating either approach.

Human Factors: Proponents of agile software development take great pains to emphasize the importance of “people factors” in successful agile development. As Cockburn and Highsmith state, “Agile development focuses on the talents and skill of individuals, molding the process to specific and teams.” The key point in this statement is that the process moulds to the needs of the people and team, not the other way around.

Alistair Cockburn: "what counts as barely sufficient for one team is either overly sufficient/ insufficient for another.”

If members of the software team are to derive the characteristics of the process that is applied to build software, a number of key traits must exist among the people on an agile team and the team itself:

Competence: It an agile development (as well as conventional software engineering) context, “competence” encompasses innate talent, specific software related skills, and overall knowledge of the process that the team has chosen to apply. Skill and knowledge of process can and should be taught to all people who serve as agile team members.

Common Focus: Although members of the agile team may perform different tasks and bring different skills to the project, all should be focused on one goal—to deliver a working software increment to the customer within the time promised. To achieve this goal, the team will also focus on continual adaptations (small and large) that will make the process fit the needs of the team.

Collaboration: Software engineering (regardless of process) is about assessing, analyzing, and using information that is communicated to the software team: crating information that will help the customer and others understand the work of the team; and building information (computer software and relevant databases) that provides business value for the customer. To accomplish these tasks, team members must collaborate--- with one another, with the customer, and with business managers.

Decision-making ability: Any good software team (including agile teams) must be allowed the freedom to control its own destiny. This implies that the tam is given autonomy--- decision making authority for both technical and project issues.

Fuzzy problem-solving ability: Software managers should recognize that the agile team will continually have to deal with ambiguity and will continually be buffeted by change. In some cases, the team must accept the fact that the problem they are solving today may not be the problem that needs to be solved tomorrow, lessons learned from any problem solving activity (including those that solve the wrong problem) may be benefit to the team later in the project.

Mutual trust and respect: The agile team must become what DeMarco and Lister call a “jelled” team. A jelled team exhibits the trust and respect that are necessary to make them “so strongly knit that the whole is greater than the sum of the parts”.

Self–organization: In the context of agile development, self- organization implies three things: (1) the agile team organizes itself for the work to be done (2) the team organizes the process to best accommodate its local environment; (3) the team organizes the work schedule to best achieve delivery of the software increment. Self – organization has a number of technical benefit, but more importantly it serves to improve collaboration and boost tam morale. In essence, the team serves as its own management. Ken Schewaber addresses these issues when he writes: “The team selects how much work it believes it can perform within the iteration, and th team commits to the work. Nothing motivates a team as much as someone else making commitments for it. Nothing motivates a team as much as accepting the responsibility for fulfilling commitments that it made itself.

The history of software engineering is littered with dozens of obsolete process descriptions and methodologies, modeling methods and notations, tools, and technology. Each flared in notoriety and was then eclipsed by something new and (purportedly) better. With the introduction of a wide array of agile process models--- each contending for acceptance within the software development community--- the agile movement is following the same historical path.

Stephen Hawrysh and Jim Ruprecht: “Our profession goes through methodologies like a 14-year-old goes through clothing.”

In the sections that follow we present an overview of a number of different agile process models. There are many similarities (in philosophy and practice) among these approaches. Our intent will be to emphasize those characteristics of each method that make it unique. It is important to note that all agile models confirm (to a greater or lesser degree) to the Manifesto for Agile Software Development and the Principles noted.

EXTREME PROGRAMMING(XP)

XP uses an object- oriented approach as its preferred development paradigm. XP encompasses a set of rules and practice that occur within the context of four framework activities: planning, design, coding, and testing.

Planning

The planning activity begins with the creation of a set of stories that describes required feature and functionality for software to be built. Each story is written by the customer and is placed on an index card. The customer assigns a value (i.e., a priority) to the story based on the overall business value of the feature or function. Members of the CXP team assess each story and assign a cost- measured in development weeks to it. If the story will require more than three development weeks, the customer is asked to split the story into smaller stories and the assignment of value and cost occurs again. It is important to note that new stories can be written at any time.

Customers and the XP team work together to decide how to group stories into the next release to be developed XP team. Once a basic commitment is made for a release, the XP team orders the stories that will be developed in one of three ways: (1) all stories will be implemented immediately (within a few weeks); (2) the stories with highest value will be moved up in the schedule and implemented first; or (3) the riskiest stories will be moved up in the scheduled and implemented first.

After the first project release has been delivered, the XP team computers project velocity, Stated simply, project velocity is the number of customer stories implemented during the first release. Project velocity can then be used to help estimate delivery dates and the schedule for subsequent releases, and determine whether an over- commitment occurs, the content of releases is modified or end- delivery dates are changed.

As development work proceeds, the customer can add stories, change the value of an existing story, split stories, or eliminate them. The XP team then reconsider all remaining releases and modifies its plans accordingly.

Design

XP design rigorously follows the KIS) Keep it simple) principle. A simple design is always preferred over a more complex representation. In addition, the design provides implementation guidance for a story as it is written- nothing less, nothing more. The design of extra functionality (because the developer assumes it will be required later) is discouraged.

XP encourages the use of CCRC cards as an effective mechanism for thinking about the software in an object- oriented context. CRC (class- responsibility collaborator) cards identify and organize the object-oriented classes that are relevant to the current software increment. The CRC cards are the only design work product produced as part of the XP process.

If a difficult design problem is encountered as part of the design of a story, XP recommends the immediate creation of an operational prototype of that portion of the design, called a spike solution. This design prototype is implemented and evaluated. The intent is to lower the risk with the implementation and to validate the original estimates for the story containing the design problem.

Coding

XP recommends that after stories are developed and preliminary design work is done, the team should not move to code, but rather develop a series of unit tests that will exercise each of the stories that is to be included in the current release. Once the unit test has been created, the developer is better able to focus on what must be implemented to pass the unit test. Once the code is complete, it can be unit tested immediately, thereby providing instantaneous feedback to thee developers.

Testing

The unit tests that are created should be implemented using a framework that enables them to be automated.

As the individual unit tests are organized into a “universal testing suite” integration and validation testing of the system can occur on daily basis. This provides the XP team with a continual indication of progress and also can raise warming flags early if things are going awry.

XP acceptance tests, also called customer tests, are specified by the customers and focus on overall system features and functionality that are visible and reviewable by the customer. Acceptance tests are derived from user stories that have been implemented as part of a software release.

ADAPTIVE SOFTWARE DEVELOPMENT(ASD)

Adaptive Software development (ASD) is a technique for building complex software and systems. An ASD life cycle incorporates three phases: speculation, collaboration, and learning.

Speculation
During speculation, the project is initiated and adaptive cycle planning is conducted. Adaptive cycle planning uses project initiation information- the customer’s mission statement, project constraints and basic requirements.

Collaboration
Motivated people work together in a way that multiplies their talent and creative output beyond their absolute numbers. This collaborative approach is a recurring theme in all agile methods. People working together must trust one another to (1) criticize without animosity; (2) assist without resentment; (3) work as hard or harder as they do; (4) have the skill set to contribute to the work at hand: and (5) communicate problems or concern in a way that leads to effective actions.

Learning
As members of an ASD team begin to develop the components that are part of an adaptive cycle, the emphasis is on learning as much as it is on progress toward a completed cycle. The learning will help them to improve their level of real understanding. ASD teams learn in three ways:

1. Focus Groups. The customer and/or end-users provide feedback on software increments that are being delivered. This provides a direct indication of whether or not the product is satisfying business needs. 2. Formal technical Reviews. ASD team members review the software components that are developed, improving quality and learning as they proceed. 3. Postmortems. The ASD team becomes introspective, addressing its own performance and process.

DYNAMIC SYSTEMS DEVELOPMENT METHOD(DSDM)

The dynamic system development method is an agile software development approach that “provides a framework for building and maintaining systems which meet tight time constraints to the use of incremental prototyping in a control to project environment.”

The DSDM lifecycle defines different iterative cycles, preceded by two additional life cycle activities:

Business study---- establishes the functional and information requirement that will allow the application to provide the business value.

Functional model iteration--- produces a set of incremental prototypes that demonstrates functionality for the customers.

Design and build iterations--- revisits prototypes built during the functional model iteration to ensure that each has been engineered in a manner that will enable it to provide operational business value for end-users. In some cases, the functional model iterations and the design and build iterations occur concurrently.

Implementation—places the latest software increment into the operational environment.

SCRUM

Scrum is an agile process model. Its principles are consistent with the agile manifesto:

• Small working tams are organized to “maximize communication, minimize overhead, and maximize sharing of tacit, informal knowledge.”

• The process must be adaptable to both technical and business changes “to ensure the best possible product is produced.”

• The process yields frequent software increments “that can be inspected, adjusted, tested, documented, and built on.”

• Development work and the people who perform it are partitioned “into clean, low coupling partitions, and packets.”

• Constant testing and documentation is performed as the product is built.

• The scrum process provides the “ability to declare a product ‘done’ whenever required.”

Scrum principles are used to guide development activities within a process that incorporates the following framework activities: requirement, analysis, design, and delivery. Within each framework activity, work tasks occur within a process pattern called a sprint. The work conducted within a sprint is adapted to the problem at hand and it is defined and often modified in real- time by the scrum team.

Scrum emphasizes the use of a set of” Software process patterns” that have proven effective for projects with tight timelines, changing requirement, and business criticality. Each of this process patterns defines a set of development activities;

Backlog--- a prioritized list of projects requirement or features that provides business value for the customers. Items can be added to the backlog at any time. The product manager assesses the backlog and updates priorities as required.

Sprints---- consists of work units that are necessary to achieve a requirement defined in the back log that must be fit into a predefined time-box (typically 30 days). During the sprint, the backlog items that the sprint work units address are frozen. Hence, the sprint allows team members to work in a short-term, but stable environment.

Scrum meeting--- are short (typically 15 minutes) meetings held daily by the scrum teams. Three key questions are asked and answered all team members.

• What did you do since last team meeting?
• What obstacles are you encountering?
• What do you plan to accomplish by the next team meeting?

A team leader, called a “scrum master”, leads the meeting and asses the responses from each person. The scrum meeting helps the team to uncover potential problems as early as possible. Also, these daily meeting lead to “knowledge socialization” and thereby promote self—organizing team structure.

Demos--- deliver the software increment to the customer so that functionality that has been implemented can be demonstrated and evaluated by the customer. It is important to note that the demo may not contain all planned functionality, but rather those functions that can be delivered within the time-box that was established.

CRYSTAL

The crystal family of agile methods is to achieve a software development approach that puts a premium on “maneuverability” during what Cockburn characterizes as “a resource- limited, cooperative game of invention and communication, with a primary goal of delivering useful, working software and a secondary goal of setting up for the next game.”

To achieve maneuverability, a set of methodologies, each with core elements that are common to all, and roles, process patterns, work products, and practice that is unique to each are followed. The crystal family is actually a set of agile processes that have been proven effective for different types of projects. The intent is to allow agile teams to select the member of the crystal family that is most appropriate for their project and environment.

Feature Driven Development (FDD):

Feature driven development (FDD) was originally conceived by peter Coad and his colleagues as a practical process model for object- oriented software engineering. Stephen Palmer and John Felsing have extended and enhanced Coad’s work, describing an adaptive, agile process that can be applied to moderately sized and larger software projects.

In the context of FDD, a feature “is a client- valued function that can be implemented in two weeks or less.” The emphasis on the definition of features provides the following benefits:

• Because features are small blocks of deliverable functionally, users can describe them more easily, understand how they relate to one another more readily, and better review them for ambiguity, error, or omissions.

• Features can be organized into a hierarchical business- related grouping.

• Since a features are small. Their design and code representations are easier to inspect effectively.

• Project planning, scheduling, and tracking and driven by the feature hierarchy, rather than an arbitrarily adopted software engineering task set.

The FDD approach defines five “collaborating” framework activities (in FDD these are called” Processes”).

FDD provides greater emphasis on project management guidelines and techniques than many other agile methods. As projects grow in size and complexity, ad hoc project management is often in adequate. It is essential for developers, their managers, and the customer to understand project status--- what accomplishments have been made and problems have been encountered. If deadline pressure is significant, it is critical to determine if software increments (features) are properly scheduled. To accomplish this, FDD defines six milestones during the design and implementation of a feature: “design walkthrough, design, design inspection. Code, code inspection, promote to build.”

AGILE MODELING(AM)

There are many situations in which software engineers must build large, business critical systems. The scope and complexity of such systems must be modeled so that (1) all constituents can better understand what needs to be accomplished; (2) the problem can be partitioned effectively among the people who must solve it; and (3) quality can be accessed at every step as the system is being engineered and built.

A variety of software engineering methods and notation have been proposed for analysis and design. These methods have significant merit, but they have proven difficult to apply and challenging to sustain. Part of the problem is the “weight” of these modeling methods. By this we mean the volume of notation required the degree of formation suggested, the size of the models for the models for large projects, and the difficulty in maintaining the model as changes occur.

In addition to the values that are consistent with the agile manifesto, an agile team must have the courage to make decisions that may cause it to reject and Refactor. It must have the humility to recognize that technologists do not have all the answers, that business experts and other stakeholders should be respected and embraced.

Although AM suggests a wide array of “core” and supplementary” modeling principles, those that make AM unique are:

1. Model with a purpose: A developer who uses AM should have a specific goal in mind before creating the model.

2. Use multiple models.

3. Travel light: as software engineering work proceeds, keep only those models that will provide long- term value.

4. Content is more important than representation: modeling should impart information to its intended audience.

5. Know the models and the tools you use to create them: understand the strengths and weaknesses of each model and the tools that are used to create it.

Adapt locally: the modeling approach should be adapted to the needs of the agile team.

Agile Development:

Objective: The objective of agile development tools is to assist in one or more aspects of agile development with an emphasis on facilitating the rapid generation of operational software. These tools can also be used when prescriptive process models are applied.

Mechanics: Tools mechanics vary. In general, agile tool sets encompass automated support for project planning, use- case development and requirements gathering, rapid design, code generation, and testing.

Representative Tools:
Note: Because agile development is a hot topic, most software tools vendors purport to sell tools that support the agile approach. The tools noted below have characteristics that make them particularly useful for agile projects.

Actif Extreme, developed by Microtool (www.microtoll.com), provides agile process management support for various technical activities within the process.

Ideogramic UML developed by Ideogramic (www.ideogramic.com), is a UML toolset specifically developed for use within an agile process.

Together Tool Set, distributed by Borland (www.borland.com or www.togethersoft.com), provides a tools suite that supports many technical activities within XP and other agile processes.

Summary

• An agile philosophy for software engineering stress four key issues: the importance of self-organizing teams that have control over the work they perform: communication and collaboration between team members and between practitioners and their customers; a recognition that change represents an opportunity; and an emphasis on rapid delivery of software that satisfies the customer.

• Extreme programming (XP) is the most widely used agile process. Organized as four framework activities- planning, design, coding, and testing- XP suggests a number of innovative and powerful techniques that allow an agile team to crate frequent software releases delivering features and functionality that allow an agile team to create frequent software releases delivering features and functionality that have been described and then prioritized by the customer.

• Adaptive Software Development (ASD) stresses human collaboration and tam self-organization. Organized as three framework activities- speculation collaboration, and learning- ASD uses an interactive process that incorporates adaptive cycle planning, relatively rigorous requirements gathering methods, and an iterative development cycle that incorporates customer focus groups and formal technical reviews as real-time feedback mechanisms.

• Dynamic Systems Development Method (DSDM) defines three different iterative cycles-functional model iteration, design and build iteration, and implementation- preceded by two additional life cycle activities- feasibility study and business study.

• Crystal adopts an interactive strategy but adjusts the rigor of the process to accommodate projects of different sizes and complexities.

• Agile Modeling (AM) suggests that modeling is essential for all systems, but that the complexity, type, and size of the model must be tuned to the software to be built. By proposing a set of core and supplementary modeling principles, AM provides useful guidance for the practitioner during analysis and design tasks.