Methods & Tools Software Development Magazine

Software Development Magazine - Project Management, Programming, Software Testing

Scrum Expert - Articles, tools, videos, news and other resources on Agile, Scrum and Kanban

The Agile Unified Process (AUP)

Sinan Si Alhir

Introduction

All endeavors are bound by an elegant universe we call reality wherein the two dimensions of time and space establish the landscape for the intertwining dance between the two natural forces of change and complexity. It is within this arena that the key ingredients of people, contextual best practices, and automation converge to bridge the chasm between vision and reality. However, throughout our endeavors across domains (and independent of any particular domain), the more change and complexity one attempts to address, the more change and complexity one breeds: it is a vicious circle riddled with risks and opportunities.

Within business and the information systems/technology industry, there are various means for confronting these forces and ultimately seizing opportunities, including the Unified Process (UP) and agile approaches that can be mixed together in an hybrid Agile methodology. This article focuses on distilling the definition of agility, exploring the definition relative to the UP and agile approaches, and describing the Agile Unified Process (AUP).

The Unified Process (UP) and Rational Unified Process (RUP)

The Unified Process (UP) is a software product engineering process framework (a use-case driven, architecture-centric, iterative, incremental, parallel, risk-confronting, object-oriented, and component-based approach). It is also known as the Unified Software Development Process (USDP). It was developed by Grady Booch, James Rumbaugh, and Ivar Jacobson (the Three Amigos). The UP provides an infrastructure for executing software product engineering projects, a framework composed of major and minor milestones and disciplines.

The Rational Unified Process (RUP) is a process product developed and marketed by IBM Rational Software. The RUP provides the details required for executing projects using the UP, including guidelines, templates, and tool assistance.

The UP emerged as the unification of Rational Software Corporation's Rational Approach and Objectory AB's Objectory process when Rational Software Corporation acquired Objectory AB in 1995. Rational Software Corporation developed the Rational Approach as a result of various customer experiences. Ivar Jacobson created the Objectory process primarily as a result of his experience with Ericsson in Sweden. Rational Software Corporation was acquired by IBM in late 2002.

Please see Understanding the Unified Process (UP) (Methods & Tools, Spring 2002) for more information on the UP.

The Agile Alliance and Agile Project Management Community

The Agile Alliance is a non-profit organization dedicated to promoting the concepts of "agile software development" based on the "Manifesto for Agile Software Development" and the "Principles behind the Agile Manifesto". The organization emerged in early 2001 as an umbrella for various approaches to software development, including eXtreme Programming (XP), Adaptive Software Development (ASD), Scrum, Agile Modeling (AM), Feature Driven Development (FDD), Lean Software Development, etc. that gained popularity in the late 1990s.

The Agile Project Management community is an organizing group of individuals dedicated to prompting the concept of "agile project management" based on the "Declaration of Interdependence (DOI) for Agile-Adaptive Project Management". The group emerged in early 2005 as an umbrella for various approaches to project management that gained popularity in the early 2000s.

The Agile Unified Process (AUP)

With the proliferation of the UP and agile software development and project management (as expounded by the Agile Alliance and Agile Project Management community), there have been many misinterpretations and misapplications of the UP and agility. The UP has become erroneously classified as a non-agile approach and the definition of agility has become synonymous with the work of the Agile Alliance and Agile Project Management community.

However, the roots of agility predate the Agile Alliance and Agile Project Management community. The origins of agility can be found in the philosophy of war as well as complexity theory and business and manufacturing. Because the UP is a process framework, it must be tailored and then enacted. Some practitioners have been applying the UP in an agile manner for a very long time while other practitioners are beginning to realize that the UP may be applied in a less-agile or more-agile manner and that the agility of the UP is dependent on how it is applied rather than how it is defined. The agile application of the UP has become known as the Agile Unified Process (AUP) or Agile Unified Software Development Process (AUSDP).

The Art of Agility

Agility involves thriving on chaos [1] in an age of discontinuity [2]; generally, it involves strategy and execution (or tactics); and specifically, it is the ability of an entity to thrive in a chaotic and discontinuous context.

An entity is a system that resides in a context called its environment, exhibits various characteristics or features called properties, and is composed of elements called parts. For example, an organization resides in an industry and is composed of teams (or departments), a team resides in an organization and is composed of individual people (or sub-teams), and an individual person resides in a team. An organization may be recursively decomposed, and when it is fully decomposed, it consists of people. For any entity, chaos and discontinuity by virtue of its environment involve incoherence and inconsistency regarding its past, ambiguity regarding its current situation, and unpredictability and uncertainty regarding its future.

Origins

The origins of agility can be found in the philosophy of war. Figure 1 shows a conceptual view of the essential static elements of agility. The solid-line ellipse represents an entity. Key concepts are interconnected using explicit relationships shown as solid-line paths and using implicit relationships shown as dashed-line paths.

Figure 1: Philosophy of war (overview).

The philosophy of war [3-6] involves the key concepts of strategy, execution (tactics), value, vision, goals, objectives, community, culture, observation, orientation, decision, and action. Strategy involves establishing a vision and goals. A vision is any mechanism (often called an "instrument" or "device") that provides focus, and a goal is any mechanism that provides direction. Execution involves establishing objectives within a community. An objective is any mechanism that provides a mission or commitment and agreement among community members, and a practice is any mechanism used to achieve an objective. The community forms a society with goals and objectives directed toward the vision, and the community's ability to achieve its purpose and provide value is ultimately related to leveraging its cultural values and the intuitiveness, trust, unity, and cohesion among its members.

A software development team uses the customer's vision of the software to focus its efforts. The vision is used to establish goals that provide direction for what pieces of the software to develop. Goals are used to establish objectives that provide commitments and agreements among team members for developing the software using various software development practices. The strategy of delivering the valued software to the customer ultimately depends on the team's intuitiveness, trust, unity, and cohesion to execute against the strategy.

Figure 2 shows a conceptual view of the essential dynamic elements of agility.

Figure 2: Philosophy of war (detail).

An entity will observe its environment, orient itself toward its vision given its observations, decide how to achieve its vision given its orientation, and act on its decisions. This cycle of activities is known as the OODA (Observe-Orient-Decide-Act) loop. Each activity feeds forward explicit guidance to its successor activity, and because orientation focuses and provides direction for all activities, it feeds implicit guidance to all activities.

Orientation (or setup) speed is the time required for the whole loop to initially execute and the entity to establish an initial orientation. It impacts the responsiveness of an entity thereafter because it establishes the entity's initial focus and direction. A software development team uses the customer's vision of the software to focus its efforts and deliver the initial version of the software.

As change occurs in an environment, an entity must observe the change, reorient itself toward its vision given the change, decide how to achieve its vision given its reorientation, and act on its decisions in response to the change.

Cycle speed is the time required for the whole loop to execute. If this cycle is too slow, by the time the entity responds, there may be other changes and the response may no longer be viable relative to the original change; and over time, the entity becomes disoriented. A software development team must be able to accommodate the customer's changes to the software in a minimal amount of time to ensure that the software and those changes remain relevant in addressing the customer's needs and vision. This ensures that the software and software development effort are relevant to the customer.

Reorientation (or changeover) speed is the time required for the entity to change orientation. If re-orientation is too slow or miss-focused or misdirected, all other activities are negatively impacted. Intuitiveness, trust, unity, and cohesion are essential for quickly transforming focus and direction into missions. A software development team must be able to reorient itself due to the customer's changes in a minimal amount of time to ensure that the team is aligned with the customer's needs and vision. This ensures that the software development team remains properly oriented.

A fast entity is one that merely requires minimal cycle time, but an agile entity is one that further requires minimal orientation and reorientation time and whose parts are said to be interdependent, aligned, and synergetic. A software development team must be able to focus on the customer's vision of the software, accommodate customer changes, and reorient itself due to the changes.

Complexity theory [7] relates to agility and emphasizes the key concepts of self-organization/discipline, non-linearity, order and chaos dynamics, and emergent properties. This involves a system changing its internal structure and behavior to increase effectiveness and efficiency based on feedback as its environment changes. The system's internal changes are not necessarily proportional or predictable relative to changes in its environment, and the system's properties are not necessarily reducible.

Business and manufacturing [8-12] relate to agility and emphasize the key concepts of enriching the customer, mastering change and uncertainty, leveraging the impact of people and information, and cooperating to enhance competitiveness. This involves a business providing value-adding solutions to its customers by configuring its products and services while reactively adapting to changes in its environment due to its competitors, proactively innovating to cause changes in its environment for its competitors, and opportunistically cooperating internally and externally with its partners to enhance its competitiveness.

The Wolf Credo

Agility is closely related to the Wolf Credo. The wolf pack is nature's most effective hunting machine, it operates under the governance of the Wolf Credo (Anonymous):

Respect the Elders

Play when you can

Share your Affection

Leave your Mark

Teach the Young

Hunt when you must

Voice your Feelings

 

Cooperate with the Pack

Rest in between

  

The first three items focus on the past, future, and present, respectively. The next three items focus on the activities of pack members and the priority of the activities. The next two items focus on communication between pack members, and the final item focuses on the results pack member activities and of the pack.

Agility

Multidimensional concepts, such as agility, are often best approached using a theme-pattern paradigm where a concept is described as a theme around which patterns provide a framework for thinking about the concept. The concept of agility is composed of three patterns shown in Figure 3.

Figure 3: Agility.

First is the Context pattern, which is expressed as Leadership-Collaboration-Contribution-&-Confirmation. It establishes the context for an agile entity. Leadership focuses on a vision. Collaboration, contribution, and confirmation focus on goals and objectives. This pattern relates directly to establishing intuitiveness among the entity's parts. The Wolf Credo's sharing, voicing, and leaving of mark generally establish the context of a pack.

Next is the Core pattern, which is expressed as Focus-Balance-Iterate/Feedback. It establishes the inner workings of an agile entity. Focus, balance, and feedback focus on goals and objectives. Within this pattern, feedback relates directly to observation, focus relates directly to orientation, balance relates directly to decision, and iterate relate directly to action. The Wolf Credo's playing, hunting, and resting generally establish the inner workings of a pack.

Finally is the Context-Core pattern, which is expressed as Support-Enable-Empower. It establishes the relationship between the context for and inner workings of an agile entity. Empowerment focuses on goals and objectives. Empowerment, support, and enablement focus on a community. This pattern relates directly to establishing trust, unity, and cohesion among the entity's parts. The Wolf Credo's respecting, teaching, and cooperating generally establish the relationship between the context for and inner workings of a pack.

Leadership in the Context pattern and focus in the Core pattern are interdependent, and empowerment in the Core-Context pattern and balance in the Core pattern are interdependent. Within these relationships, if one element of a pattern suffers, the other element in the other pattern suffers and ultimately the degradation of one pattern impacts the other pattern. These patterns are interdependent and form a system or paradigm for understanding agility.

A software development team requires leadership where its members collaborate to contribute and confirm their added value in developing the software. The team must focus via leadership where its members can balance how they add value in developing the software based on feedback. The team members must be supported, enabled, and empowered to balance how they add value in developing the software.

Agility is not an all or nothing concept, but an entity can have different degrees of agility. An entity may be dormant or inactive, in which case it does not necessarily respond to its environment. An entity may be reactive, in which case it reactively adapts to known changes in its environment using previously known (not newly invented) responses. A software development team that has "change management" capabilities and can address changes to the software is reactive. An entity may be proactive (often said to be responsive), in which case it evolves its capabilities to respond. A software development team that has "process improvement" capabilities and can improve itself and the software is proactive. An entity may be completely agile (often said to be proactive), in which case it proactively innovates to unknown changes in its environment using previously unknown (newly invented) responses. A software development team that has "innovation" capabilities and can re-invent itself and innovate its software is completely agile.

Understanding Agility in Software Development

Even though the definition of agility in software development has become synonymous with the work of the Agile Alliance and Agile Project Management community, the origins of agility can be found in the philosophy of war as well as complexity theory and business and manufacturing, and universally expressed using three essential patterns.

Manifesto for Agile Software Development

The Agile Alliance expresses a set of core values via the "Manifesto for Agile Software Development" [13, 14]:

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 interactionsover processes and tools

  • Working software over comprehensive documentation

  • Customer collaboration over contract negotiation

  • Responding to change over following a plan

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

These core values readily relate to the three essential patterns used to describe agility. The first value statement ("Individuals and interactions") generally relates to the Context pattern with emphasis on collaboration. The second value statement ("Working software") generally relates to the Core pattern with emphasis on focus. The third value statement ("Customer collaboration") generally relates to the Context pattern with emphasis on collaboration (and leadership) and the Context-Core pattern. The fourth value statement ("Responding to change") generally relates to the Core pattern with emphasis on balance and feedback.

There may be other interpretations of how the "Manifesto for Agile Software Development" relates to agility, but that is beyond the scope of this discussion.

Declaration of Interdependence (DOI) for Agile-Adaptive Project Management

The Agile Project Management community expresses a set of core values via the "Declaration of Interdependence (DOI) for Agile-Adaptive Project Management" [15]:

  • We increase return on investment by making continuous flow of value our focus.
  • We deliver reliable results by engaging customers in frequent interactions and shared ownership.
  • We manage uncertainty through iterations, anticipation and adaptation.
  • We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
  • We boost performance through group accountability for results and shared responsibility for team effectiveness.
  • We improve effectiveness and reliability through situationally specific strategies, processes and practices.

These core values readily relate to the three essential patterns used to describe agility. The first value statement ("Value") generally relates to the Core pattern with emphasis on focus. The second value statement ("Customer") generally relates to the Context pattern with emphasis on collaboration. The third value statement ("Uncertainty") generally relates to the Core pattern with emphasis on balance and feedback. The fourth value statement ("Individual") generally relates to the Core-Context pattern. The fifth value statement ("Team") generally relates to the Core-Context pattern. The sixth value statement ("Context") generally relates to the Context pattern with emphasis on leadership.

There may be other interpretations of how the "Declaration of Interdependence (DOI) for Agile-Adaptive Project Management" relates to agility, but that is beyond the scope of this discussion.

The Agile Unified Process (AUP )

The UP is a software product engineering process framework which may be approached using three perspectives, including collaborations, context, and interactions which focus on a lifecycle composed of phases, disciplines, and iterations.

Figure 4 shows a conceptual view of the essential elements that constitute the UP and AUP.

Figure 4: The UP and AUP.

A collaboration involves an interaction within a context. In the UP, a collaboration captures who does what activities (how) on what work products. Thus, it establishes the elements of a project. Collaborations involve workers (roles), activities, and work products (artifacts). In the AUP, collaborations focus on collaborators (contributors and confirmers), goals and objectives, and results.

A context emphasizes the structural or static aspect of a collaboration, the elements that collaborate and their conglomeration or spatial relationships. In the UP, a context captures when and where such activities should be done and work products (artifacts) produced and consumed. Thus, it establishes the context for a project. Contexts involve development cycles and phases, iterations, and disciplines. The UP's phases include Inception, Elaboration, Construction, and Transition. The UP's disciplines include Business Modeling, Requirements, Analysis & Design, Implementation, Test, Deployment, Configuration & Change Management, Project Management, and Environment. In the AUP, contexts focus on goals.

An interaction emphasizes the behavioral or dynamic aspect of a collaboration, the elements that collaborate and their cooperation or temporal communication. In the UP, an interaction captures when and why such activities should be done and work products (artifacts) produced and consumed. Thus, it establishes the execution of a project. Interactions involve requirements or use-cases, a system and its architecture, iterations, and risk. In the AUP, interactions focus on objectives.

Figure 5 shows a conceptual view of the AUP.

Figure 5: The AUP lifecycle.

The AUP defines goals and objectives where collaborations are used to achieve results. A collaboration may be work performed by a single individual who may interact with others. A collaboration may be a workshop involving multiple individuals who interact with each other and may interact with others outside the workshop. Goals are similar to UP phases where they are used as gates that involve stakeholders and users. Objectives are similar to UP time-boxed iterations that involve users and result in a product release.

The focus of Initiate (Conception) is to establish the product vision, project roadmap, business and technology justification, and identify risks and opportunities. There may be one or more objectives which must be achieved in reaching this goal.

  • Stakeholders focus on the problem, solution, and constraints (visioning workshops).
  • Users focus on their needs and product features at a high level (requirements workshops).
  • The stakeholders and users focus on establishing the business justification for the product and project.
  • The users and software development team focus on establishing the technology justification for the product and project.
  • The team (software development team, stakeholders, and users) focus on prioritizing risks and opportunities (road-mapping workshops).
  • The team focuses on relating product features to Execute (Innovation) goals and objectives in the project roadmap (road-mapping workshops).
  • The team establishes the development infrastructure.

The focus of Execute (Innovation) is to evolve the product vision, project roadmap, and business and technology justification; identify and confront risks; and identify and seize opportunities while architecting, developing (implementing and testing), and deploying (integrating, building, and releasing) the product. There are commonly many objectives and goals, each resulting in deploying the product.

  • Strategize (Define)
  • The team considers potential changes to the product and project and their ramifications, decides to accept or reject the potential changes, and incorporates the accepted changes into the product and project (change-consideration workshops).
  • Stakeholders and users focus on evolving the vision (visioning and requirements workshops).
  • The team focuses on evolving the business and technology justification for the product and project.
  • The team focuses on evolving the risks and opportunities and project roadmap (road-mapping workshops).
  • The team focuses on taking a pulse of the product and project at goals and objectives (pulse workshops).
  • Execute (Architect, Develop (Implement & Test), Deploy)
  • The team focuses on seizing opportunities while confronting risks in architecting, developing (implementing and testing), and deploying (integrating, building, and releasing) the product (product-development workshops).
  • The team addresses issues (issue-resolution workshops).
  • The team identifies potential changes to the product and project.

The focus of Close (Cessation) is to retire the product and close the project (closure workshops). There may be one or more objectives which must be achieved in reaching this goal.

The vision provides focus and general direction, the roadmap provides specific direction through goals and missions through objectives, and collaborations establish intuitiveness, trust, unity, and cohesion.

Conclusion

Unequivocally, people are and will remain the "original ingredient" necessary for success. However, with a better understanding of agility, individuals, teams, and organizations are further empowered not only to simply address change and complexity, but leverage change and complexity for a competitive advantage. Furthermore, it is experience, experimentation, and application of agility that will enable us to realize its benefits.

References

[1] Tom Peters' "Thriving on Chaos"

[2] Peter F. Drucker's "The Age of Discontinuity"

[3] Sun Tzu's "The Art of War" (The Denma Translation, https://www.rulesofvictory.com/)

[4] John Boyd's "A Discourse on Winning and Losing" (which includes "Patterns of Conflict" and most of Boyd's major works on strategy)

[5] Chet Richards' "A Swift, Elusive Sword" and "Certain to Win"

[6] Kaihan Krippendorff's "The Art of the Advantage"

[7] Santa Fe Institute (http://www.santafe.edu)

[8] Iacocca Institute's "21st Century Manufacturing Enterprise Strategy"

[9] Paul T. Kidd's "Agile Manufacturing: Forging New Frontiers" (http://www.cheshirehenbury.com)

[10] H. Ted Goranson's "The Agile Virtual Enterprise: Cases, Metrics, Tools"

[11] Steven L. Goldman, Roger N. Nagel, Kenneth Preiss's "Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer"

[12] Rick Dove's "Response Ability: The Language, Structure, and Culture of the Agile Enterprise" (http://www.parshift.com)

[13] Agile Alliance's (http://www.agilealliance.org)"Manifesto for Agile Software Development" (http://www.agilemanifesto.org)

[14] Agile Alliance's (http://www.agilealliance.org) "Principles behind the Agile Manifesto" (http://www.agilemanifesto.org/principles.html)

[15] Agile Project Management "Declaration of Interdependence for Agile-Adaptive Management"


Related Methods & Tools articles

More Agile and Unified Modeling Language (UML) Knowledge


Click here to view the complete list of archived articles

This article was originally published in the Spring 2005 issue of Methods & Tools

Methods & Tools
is supported by


Testmatick.com

Software Testing
Magazine


The Scrum Expert