AUP and Failure Modes

Agile Unified Process

• a simplified version of the Rational Unified Process (RUP).
• It describes a simple, easy to understand approach to developing
business application software using agile techniques and concepts yet
still remaining true to the RUP.
• The approach applies agile techniques include test driven
development (TDD), Agile Model Driven Development
(AMDD), agile change management, and database refactoring to
improve your productivity.
When Should You Adopt the AUP?
• If you want something in between XP and traditional RUP, a process
that is agile yet explicitly includes activities and artifacts which you're
accustomed to, then the AUP is likely for you
• The AUP is either the best of both worlds or the worst of both worlds
• Extreme Programmers will likely find the AUP fairly heavy, and
"traditional RUP" users may find that it's too streamlined
AUP
• Phases
• Disciplines
• Philosophies
• Releases
The Agile Unified Process (AUP) lifecycle
Serial in the Large
• The serial nature of Agile UP is captured in its four phases :
• Inception: The goal is to identify the initial scope of the project, a potential
architecture for your system, and to obtain initial project funding and
stakeholder acceptance.
• Elaboration: The goal is to prove the architecture of the system.
• Construction: The goal is to build working software on a regular, incremental
basis which meets the highest-priority needs of your project stakeholders.
• Transition: The goal is to validate and deploy your system into your
production environment
Phases
Iterative in the Small
• Disciplines are performed in an iterative manner, defining the
activities which development team members perform to build,
validate, and deliver working software which meets the needs of their
stakeholders.
• Model discipline encompasses the RUP's Business Modeling,
Requirements, and Analysis & Design disciplines.
• Configuration Management discipline includes the Configuration
and Change Management discipline
AUP disciplines
Discipline Goal
Model • To understand the business of the organization,
• The problem domain being addressed by the project, and
• To identify a viable solution to address the problem domain

Implementation • To transform your model(s) into executable code and

• To perform a basic level of testing, in particular unit testing.

Test • To perform an objective evaluation to ensure quality.

• Includes
• finding defects,
• validating that the system works as designed, and
• verifying that the requirements are met.

Deployment • To plan for the delivery of the system and to execute the plan to make the system
available to end users
AUP disciplines
Discipline Goal
Configuration • to manage access to your project artifacts.
Management • This includes not only tracking artifact versions over time but also controlling and
managing changes to them.
Project • To direct the activities that takes place on the project.
Management • Includes
• managing risks,
• directing people (assigning tasks, tracking progress, etc.), and
• coordinating with people and systems outside the scope of the project to be
sure that it is delivered on time and within budget.
Environment • to support the rest of the effort by ensuring that the proper process, guidance
(standards and guidelines), and tools (hardware, software, etc.) are available for the
team as needed.
Releases
Delivering Incremental Releases Over Time
• Instead of the "big bang" approach where you deliver software all at
once you instead release it into production in portions (e.g. version 1,
then version 2, and so on).
• AUP teams typically deliver development releases at the end of each
iteration into pre-production staging area(s)
• A development release of an application is something that could
potentially be released into production if it were to be put through
your pre-production quality assurance (QA), testing, and deployment
processes
Delivering Incremental Releases Over Time
• the first production release often takes longer to deliver than subsequent
releases
• The first production release may take you twelve months to deliver, the second
release nine months, and then other releases are delivered every six months.
• An early focus on deployment issues not only enables you to avoid problems it
also allows you to take advantage of your experiences during development.
• For example, when you are deploying software into your staging area you should take notes
of what works and what doesn’t, notes that can serve as the backbone of your installation
scripts.
Sandboxes within development environment
Sandboxes within development environment
• Development. This is the working environment of individual
developers, programming pairs, or individual feature teams.
• The purpose of this environment is for the developer/pair/team to work in
seclusion from the rest of their project team, enabling them to make and
validate changes without having to worry about adversely affecting the rest of
their project team.
• These environments are likely to have their own databases to
enable regression testing and more importantly agile testing strategies.
Sandboxes within development environment
• Project integration. Each project team should have its own
integration environment, often referred to as a build environment or
simply a build box.
• Developers will promote their changed code to this environment, test it, and
commit it to their teams configuration management system.
• The goal of this environment is to combine and validate the work of your
entire project team so it can be tested before being promoted into your
Test/QA sandbox.
• Demo sandbox. This sandbox is where you deploy working software
which you can use to demo software to your stakeholders and they
can use for acceptance testing purposes.
Sandboxes within development environment
• Pre-production test/QA. This sandbox is shared by several project teams and is often
controlled by a separate team, typically your testing/QA group.
• This environment is often referred to as a pre-production sandbox, a system testing area, or simply
a staging area.
• Its purpose is to provide an environment that simulates your actual production environment as
closely as possible so you can test your application in conjunction with other applications.
• This sandbox is crucial for complex environments where several applications access your database,
although even if your database is only accessed by a stand-alone application you will still be
required to test within this sandbox before deploying your application into production.
• Production. This is the actual environment in which your system will run once it is
deployed.
Philosophies of the AUP
• Your staff knows what they're doing. People aren't going to read
detailed process documentation, but they will want some high-level
guidance and/or training from time to time.
• The AUP product provides links to many of the details, if you're interested,
but doesn't force them upon you.
• Simplicity. Everything is described concisely using a handful of pages,
not thousands of them.
• Agility. The Agile UP conforms to the values and principles of
the Agile Alliance.
Philosophies of the AUP
• Focus on high-value activities. The focus is on the activities which
actually count, not every possible thing that could happen to you on a
project.
• Tool independence. You can use any toolset that you want with the
Agile UP.
• You use the tools which are best suited for the job, which are often simple
tools or even open source tools.

• You'll want to tailor this product to meet your own needs. The AUP
product is easily tailorable via any common HTML editing tool.
• You don't need to purchase a special tool, or take a course, to tailor the AUP.
Product
• The AUP product is an HTML-based description of the Agile UP
process.
• Current version: v1.1 May 13, 2006 (510 K zip file)
Agile Failure Modes-Leader ship
Modes of Description Prevention
Failure
Lack of can come at you from two directions : Your leaders must accept that a
Executive • Under the radar small group of techies eager to successful transformation is a
Sponsorshi adopt agile With no executive sponsorship, they work journey. They need to:
p under the radar, hiding from management. • Seek guidance and input from
• Checkbook commitment an executive decrees a teams.
switch to agile delivery across the entire IT organization, • Make a personal commitment
but there’s no real follow through—it’s simply a to their teams.
checkbook commitment. • Recognize the personal
• Without changing the metrics for success, these commitment they’re asking of
proclamations for agile adoption will likely never their employees.
result in true business transformation. • Commit to measuring success
• Without the executive’s continued engagement, differently.
the organization will only have pockets of agile • Celebrate setbacks as
success at best, typically limited to the team level. opportunities for growth.
Agile Failure Modes-Leadership
Modes of Failure Description Prevention
Failure to • How your managers work with their teams can also A servant leader:
Transform make or break agile adoption. • one who serves by leading, and
Leader Behaviors • Too often, managers rely on a top-down approach, leads by serving.
driving projects forward with little regard for • Servant leadership is the key to
input from the team. successful agile transformation.
Agile Failure Modes-Leadership
Modes of Failure Description Prevention
No Change to What is your current organizational • True agile transformations push the
the structure? How many layers of management boundaries of these existing
Organizational exist around each agile team? How is organizational hierarchies
Infrastructure governance perceived, and who is ready to
break down walls to make sure that value • In an effective agile transformation, you
flows through your organization? know what the true value is and who
• Organizations set up to measure success needs to be involved in order for the
by departmental performance versus value to be delivered.
overall value delivery limit visibility of • They see the goal as successful delivery
their overall effectiveness. of value to the customer, and they
• They also zero-in on a specific team’s coordinate as a whole to deliver that
performance at the expense of success value.
for the organization.
• need to expand your idea of efficiency,
revisit the way your organization
appraises work and invite frequent
feedback to sharpen your focus on team
effectiveness
Agile Failure Modes-workflow
Modes of Failure Description Prevention
No Business • there’s no view across • First, recognize that you do indeed have a value stream—
View of the the value stream—that go find it.
Value Stream is, organizations aren’t • Map your system at whatever level of detail best
tracking the concept-to- articulates your sense of handoffs and bottlenecks.
cash flow of value • Start where you are in the value stream;
through a system. • Every system has one primary constraint; find yours,
crush it, and then look for the next primary constraint
that emerges. Rinse and repeat.
• Be ruthless in your vision to expand the boundaries of
your value stream: upstream from the neighbor
processes that feed your work, and downstream where
you feed your work into your neighbor process.
• Include everyone in identifying the value stream, its
bottlenecks and its potential flow
• Broaden commitment up and down the stream, not in
localized silos .
Agile Failure Modes-workflow
Modes of Description Prevention
Failure
Failure to • The manager’s sense of significance The scale principle: Centralize control for
Decentralize is somehow wrapped up in the problems that are infrequent, large, or
Control decision-making control. that have significant economies of scale.
• Due to this strict, centralized The perishability principle: Decentralize
control, decisions are not as control for problems and opportunities
informed as they could be. that age poorly.
• Waiting for a decision because of
centralized control wastes time and
human potential.
• This control style ultimately lowers
morale and fosters pessimism.
 Agile Failure Modes-workflow
Modes of Description Prevention
Failure
Unwillingness • Set up a complex geographic maze • Hire a coach who’s well-steeped in
to Address based on the economics of resource distributed team success.
Illusions utilization. • Ensure all team members receive the
Around • Ensure a time zone difference same agile training; for maximum
Distributed between 7–11 hours. effectiveness, get everyone in the
Teams • Rely heavily on emails and large same room for the training.
documents (especially detailed test • Invest in high-definition, large-screen
plans) for your communication. video technologies.
• Definitely don’t invest in bringing • Accompany these with a top-notch
people together to collaborate or train sound system that figuratively brings all
the voices into the room.

• Organizations with distributed teams have become the norm.

• Teams are dispersed across many time zones, and even 80/20 rules are guiding projects—where 80 percent are
offshore teams and only 20 percent of teams are located in the same building (or the same city).
Agile Failure Modes-Congruency
Modes of Description Prevention
Failure

Lack of a The organization • You need to identify a transformation product manager to

Transformation doesn’t dedicate be your scout leader in delivering a high-quality
Product a transformation transformation.
Manager product • Have this person work in a tight relationship with the
manager. executive owner of the transformation  Together, they
define the disciplined exploration and execution to deliver a
world-class transformation, and they serve as the models of
congruency among all players in the transformation.
 Agile Failure Modes-Congruency
Modes of Description Prevention
Failure
Failure to Create • Clinging to a strict sense
Fast Feedback of predictability for • Fast feedback is the unsung hero of congruency
when feature work will • Seek feedback on guesses, value, behavior, risk, culture
be completed and agile practices.
• One centralized • Healthy agile transformations crave fast feedback on
organization deciding all every aspect of how the transformation is progressing.
standards and rules for • For this to occur, ensure you deliver feedback both ad
every team at the start hoc and on a cadence, the latter being more formal
of the transformation and facilitated.
• Relying on large-batch • The ad-hoc feedback reduces the waste of waiting for
delivery of feature sets direction on very transactional decisions;
• the cadenced retrospectives ensure regular inspect-
and-adapt sessions across the organization.
Agile Failure Modes-Congruency
Modes of Description Prevention
Failure

Short-Changing Lack of proper understanding • You must seek a core team belief that collaboration
Collaboration about collaboration makes you greater.
and Facilitation • Good facilitators devote themselves to bringing out
the best in the team.
• Collaboration does not mean groupthink, despite
what people may infer.
Agile Failure Modes-Transition
Modes of Description Prevention
Failure

Ineffective • Executives are looking at how to • Imagine your transformation being guided by
Planning for build products faster: getting to these qualities:
Transforming market faster with more innovation • Visionary leadership
Beyond IT by making their engineering teams • Lean principles of value flow
more efficient. • Reduced organizational friction
• They bring this “work order” to their • Employee respect
product or IT group and declare that • Transparency and collaboration
an agile transformation is in play
Agile Failure Modes-Transition
Modes of Description Prevention
Failure

Viewing • To be clear, process and • It’s important to consider how people’s

Transformation structure are important, but personal values will align with the
Solely As Process alone, they are insufficient— aspirational values of your agile
and Structure and worse, can lead to a false transformation
sense of success in the • A great agile transformation feeds off of
transformation. people’s positive perspective of the
• Checklists, quarterly reports change.
and other measures will only
yield limited success.
Agile Failure Modes-Transition
Modes of Description Prevention
Failure
Ignoring the Path of • This failure mode is last because it’s the • To succeed, you need to first
Individual, Team least understood, and the least addressed. recognize the underlying
and Organizational • In any large transformation effort, even organizational unease the agile
Transitions when you just know it’s good and for the transformation can set in motion.
right reasons, there’s always someone who • Then, acknowledge these three
has something to lose—whether true or stages of transition, in this order:
imagined.
• This can happen at the individual, team or
director level.
Reference
• http://www.ambysoft.com/