Blended Agile

CC Pace Proprietary www.ccpace.com
Blended Agile
July 15, 2009

What is Blended Agile?
• Blended Agile is a term we use to describe a combination
of agile practices/techniques integrated with more
traditional methods.
• This is generally a result of a scenario where an
organization can not flip a switch overnight and move to
a full set of agile practices.
• The company slowly initiates agile practices, increasing
them over time while integrating with traditional practices
that still have value to the organization but are not part of,
or sometime might even be in conflict with, agile
practices.

Blended Agile
• Blended Agile will utilize some of the Agile practices along
with other practices from methodologies such as spiral,
DSDM, etc.
• Blended Agile is not Agile in its purest form. Thus you will not
obtain all of the benefits of Agile.
• Blended Agile will allow your organization to improve its
current practices.

Examples of Blended Agile
• Iterative cycles with requirements established several
iterations before
• Mini waterfall iterations
• Reduction of team time together
– Scheduling of product owners time on specific days
– Working together for a short percentage of time during
the day , perhaps just for the daily standup and doing
work at your desk
– Use of IM
• Break project into modules
– Low criticality is done using agile
– Over the course of time higher criticality modules use
agile

What we will cover:
• High level overview of Agile
• Differences and Conflicts between Agile and Traditional
Methodologies
• The Journey to Agile and why using a Blended Approach
can be an Appropriate Approach for you Company
• Examples of Blended Agile
• Key Points to Take Away

What is Agile?
• A conceptual framework for software development that
promotes development iterations, open collaboration,
and adaptability throughout the life-cycle of the project.
• Simply stated, the ability to respond to change.

Agile Principles
• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.
Although there is value in the items on the right, we
value the items on the left more.

Agile Practices
• Breaks projects into ‘functional slices’ for incremental
delivery.
• Consists of short development cycles.
• Supports Empirical methods to monitor progress and
allow for rapid change.
– Inspect and Adapt mechanisms
• Anticipates that baseline requirements will change.
– Resulting in a product which more closely meets
customers needs
• Agile is not without its own structure and control
mechanisms.

Agile Process Framework
1-4 weeks
24 hours
Product Backlog
As prioritized by Product Owner
Iteration Backlog
Backlog
tasks
expanded
by team
Potentially Shippable
Product Increment
Daily
Meeting
PRODUCT
BACKOG
ITERATION
BACKLOG
BURNDOWN
CHART
ITERATION
DEMO
RETROSPECTIVE

Implications of Agile
• No traditional phase gates; functions are done in parallel in very
small batches.
• Not everything will get done; this is good! (45% of it is never used
anyway).
• The highest priority work will get done and will be done early.
• Requirements will not be highly defined in advance.
• Requirements will change; this implies that code will change and
test plans will change.
• There will be much better communication, coordination and
alignment.

Agile Myths
Agile Is NOT:
• A silver bullet solution
• New and unproven
• A methodology without any
planning/documentation/architecture requirements
• A license to hack
• Undisciplined; it actually has many controls
• A methodology that creates quality issues
• A final solution to all project resourcing issues

Agile and Traditional
Methods Compared

Traditional vs. Agile
• Most traditional methodologies consist of several phases to
develop/enhance applications.
– i.e. requirements phase, design phase, build phase and
implementation phase
• Agile development utilizes iterations which combine to equal
a release (an individual iteration can also be a release on a
very small project).
– Iterations consist of all of the above phases, except at
times implementation.
– Implementation may happen at the release level.

How Is Agile Thinking Different?
Topic Traditional Agile
Driver Plan-Driven Value-Driven
Resources Partial allocation Dedicated
Sponsor Involvement Ad Hoc Daily
Change Is a risk, minimize it Is a competitive advantage,
embrace it
Leadership Command and control; Telling,
Directive
Servant Leadership; Participatory,
Facilitative
Lifecycle Phased Approach; Serial,
Sequential
Short Iterative Development cycles,
Incremental Delivery

Traditional vs. Agile
Traditional Thinking Agile Thinking
Gathering all requirements weeks or months before
development begins
High-level requirements gathered and then supports
evolutionary requirements
Full up-front design and architecting “Just enough” design and architecting
Descriptive approach - plan what you expect to happen Empirical approach – inspect and adapt mechanisms with
early and continuous evaluation
Uses formal processes to control changes Anticipates change to baseline requirements
Command and control leadership style Leadership by influence
Heavily matrixed team members Dedicated, self-organizing, cross-functional teams
Phased approach Short development cycles delivering continuous functional
slices of incremental value
Process focused Value delivery focused
Heavy documentation requirements Consistent level of lightweight documentation maintained as
the project progresses
Information disbursed across many individuals with low
visibility
Highly visible information to business and IT in a collaborative
work environment

* Top 3 reasons from CompTIA survey, Mar 2007
** misc reasons from other sources
A Different Approach to the Same Problems
Some Reasons
Projects Fail
Traditional Solutions Agile Solutions
Poor Communication * Status Meetings; Communications Plan;
Stakeholder Meetings
Daily Meetings; Collaboration; In-
Room/table dialog; Retrospectives
Inadequate Resources * Request and justify additional resources Assign dedicated teams; whatever team
is available only commits to work they
can do
Unrealistic Deadlines * Identify risk; Compute additional
resources needed to make the date;
request; re-work the schedule/budget
Deliver in time-boxes; estimate
completion range based on team
velocity; negotiate scope
Requirements Changes ** Submit Change Requests; re-work
schedule
Add new stories to Backlog; prioritize;
pull into iterations
Lack of user involvement ** Request a project sponsor or SME rep Dedicated Product Owner involved with
the team on a daily basis
People Problems ** PM intervention/Coaching Connectivity; Ownership; Team Norms;
Values; Collaboration; Co-location;
Retrospectives; Team Self-Policing;
Coaching

Waterfall, Spiral, and Agile Development
• The waterfall life-cycle model has been closely associated
with heavyweight documentation.
• The spiral model has been misinterpreted as an incremental
waterfall model, rather than as a risk-based model. Spiral
also responds to change, thus is adaptable.
• Agile focuses on people (individuals, stakeholders), products
(working software, key artifacts), and change (responding to
change, adaptability).
– Notice that common to both the Agile Manifesto and
Spiral is adaptability.

Agile and Traditional
Methods Conflict

Conflicts Between Methodologies
• Working Software vs. Early Design Documentation
– The conflict between what is perceived the end-customer
wants and what is being asked.
• Single vs. Multiple-Increment Life Cycle
– Agile teams focus on achieving customer satisfaction
through frequent software deliveries based on clear
priorities.
– Agile teams are also usually small and often do not have
adequate resources to work multiple risks in parallel.
– The single iteration through the waterfall model with the
planned single milestone can be a project management
conflict for the agile team.

Conflicts Between Methodologies
• On-Site Customer Collaboration
– Agile requires the customer to become part of the
working team. This role is known as the product owner.
• Business members are not use to dedicating time to
the development of a project throughout the project’s
lifecycle. Previously the business person/product
owner provided input at different stages of the project.
• Formal Deliverable Documentation Weight
– Agile methods tend to promote lightweight
documentation. This is because agile values working
software more than documentation. In most companies
cultures, documents tend to be on the heavyweight side.

The Journey

1. It requires thinking and acting in new ways
2. Roles/Responsibilities will change
3. Interactions will change
4. Processes will change
5. People resist change
There are ‘just’ two problems left to solve in business
– People and Change.
-- Bob Eichenger, Co-Founder, Lominger International
Why Isn’t Moving to Agile Easy?

Un-responsive
To
Change
Responsive
To
Change
Co-located Teams
Daily Meetings
Regular Reflection,
Inspection, &
Adaption
Adaptive
Planning
Iterative &
Incremental
Delivery
TDD
Automated
Testing
Continuous
Integration
Everyone’s journey will be different, because starting points are
different, environments are different, and obstacles are different.
A Journey

Why even bother Blending?
• The success of Agile is clear and gaining some of those
benefits through small improvements is worthwhile
• Providing Business partners with earlier delivery of results
and early access to a working system
– Time-to-Value
– Time-to-Market
• Flexibility to requirements change
– Evolutionary Requirements
• Improved Business - IT collaboration and trust
• Increased Customer Satisfaction
• Increased Quality

Why even bother Blending?
• It takes time to move to a full Agile capability.
• Companies have real obstacles that do not allow them to
move as quickly.
• Companies must collaborate with internal areas and outside
organizations utilizing traditional development processes.
• Companies have standing processes that can not be
changed with a flip of a switch.
• Taking a blended approach reduces the perception of risk.
• Taking a blended approach gives the organization time to
learn and to adjust which practices are right for their
organization.

Key Components for Blending

General Blended Core Commonalities
• Plan Collaboratively and Use an Incremental Life Cycle
– the initial planning to be done collaboratively between
the team and the customer
– an incremental life-cycle model employed to align the
blended project within the overall project schedule
• Use Iterative development and Risk Check points
– provide working software early to address high-risk areas
– ensure all the risks are being addressed and prioritized

General Blended Core Commonalities
• Plan for Multiple Documentation Drops
– provide multiple drops of documentation before the
delivery date to obtain early feedback
– consider use of a team member each iteration to
capture documentation
• Make Customer Collaboration Work
– encourage and support as much customer collaboration
as you can between the blended team and the end-
customer to help manage your own risk
– provide documented list of agreed-to stories to be
completed in the upcoming iteration/release
– conflicts associated with vague requirements can often
be resolved quickly

Potential Consistent blended practices for the Teams
Metrics
• Hours
• Days
• Points
Planning sessions
• Two levels of planning
– Allows communication of the objectives to the
project team, the executive stakeholders and
customers:
» release level - preparation for deployment to
end users
» iteration level - time-boxed increment of new
functionality

• Lessons Learned/Retrospective
• Demo
• Daily Stand up
• Iteration 0
• Kick off
• Customer/team collaboration and communication
• Use an Incremental Life Cycle (2-4 weeks)
• Common vocabulary

• Test driven design and development
• Active Stakeholder/Champion Participation
• Core hours
• Established Team Norms
• Fun budget
• On boarding
• Establish Roles
• Change acceptance

Possible Blended Variables Per Team
• Co-location
• On boarding process
• Toolsets
• Time dedicated to the project
• Length of iteration
• Start of iteration
• Order of deliverables at end of iteration
• How status is covered in daily stand up
• How board is set up (User Story Card)
• Configuration of room
• Scope changing
• Presentation of backlog
• Documentation flexibility
– Multiple drops of documentation be provided
– Depth
• Estimation method
• Contingency story card
• Methods of Education
• Methods of Communication

Possible Blended Common Practices Overall
Organization Overall
• Informal user community
• Established success criteria for the teams
• Product backlog required
• Blended vocabulary
• Planning
• Environment foundation
• Core documentation
• Compliance/audit
• Budgets
• Collaboration
• Use of core Agile group
• Use metrics
• Communication Lines Open
• Education
• Test driven design and development
• Active Stakeholder participation
• On boarding
• Roles

Suggested How To Steps for General Blending
• Know the existing processes
– Identify the existing process/ methods being utilized
– Analyze what is working well and what can be improved
• Gain knowledge of best practices
– These are from multiple methodologies
– Review best practices and analyze which ones make
practical sense to begin with
• Obtain management support
• Obtain team buy in
• Select a pilot project
– Begin with just one project

Suggested How To Steps for General Blending
• Collaborate with the team
– Once the team is selected include the team in planning
and making decisions
• Advertise/communicate what you will do
– Kickoff
• Determine the strategy
– Organizationally
– Departmentally
– Team
• Constant retrospectives for lessons learned
– Employ changes based on lessons learned

Blended at your Organization
Document and Communicate Your Blended Process
• The PMO group or Core Agile group can become
involved at this point.
• Assign a team member to frequently document.
• Share documentation with other areas within the
company.
- A shared drive?
• Presentations to other areas in the company .
• Presentations to management.
• Frequent brown bags to share status and knowledge
gained.
• Production of a checklist and or variance document to
help the new Blended Agile PM and Blended Agile Team
adjust to differences.

Blended at your Organization
• Recognize that blended consists of feasible best practices
• Recognize that blended can be different among teams and
departments
– Different teams may employ different forms of blended
while maintaining organizational established core
principles

Conflicts in Setting up a Blended Process
• Many of the conflicts are rooted in the up-front
thinking/planning that comes with the one cycle waterfall
model.
• Several project management conflicts that companies face:
– Full Life Cycle vs. Multiple-Increment Life Cycle
– Documentation Weight
– Role confusion
– Working Software vs. Early Documentation
– Customer Collaboration on site
– Changes in Requirements and Testing higher level descriptions of
business flows, called "User Stories" or "Use Cases”
– Testing consistently
– Time commitment

Strategies to Avoid Conflicts
– Once an iteration is under way, requirements must remain
fixed to avoid chaos
• Add a contingency story card
– Multiple drops of documentation to be provided
• Reduces risk, obtains early feedback
– Use of core Agile group
– Use metrics
– Use iterative cycles
– Communication Lines Open
• Documentation
• Presentation
• Education
• Establish common vocabulary
• Project
– verbal status
– examples of the outcomes
– visual boards
– virtual boards
– retrospectives

Examples of Blended Agile

Real Life Blended Case
Background/Problem Description
• This Fortune 500 company was looking to become more
effective by improving on the integration points of multiple
systems and improving the functionality of a trading system.
The current process required multiple manual processes which
were time consuming.
• Time to market was imperative and budget was limited. Since
there were so many tentacles and integration points from
other departments and third party companies, this project also
was restricted by several regulations. Management buy in and
support for the project was needed from all of the integration
groups.
• The company was ingrained with older methods of project
management and software development. However, due to
the size and complexity of this project, they knew they would
need to employ a different methodology to be successful.

Method
– The client chose to employ a Blended Agile methodology
that would improve delivery time, provide working
software that satisfied the need of the customers, and
conserve budget dollars.
Approach
– Held discovery sessions to determine readiness to use a
Blended Agile methodology.
– Formed a Blended Agile team.
– Created the setup/iteration zero for the blended agile
team.
– Analyzed which agile practices would be feasible to
utilize within their blended methodology now and in the
future, while continuing to introduce new practices.
– Determined which existing processes and best practices
to utilize.

• Agile Competency Development
- Training – overviews, lunch and learns, team meetings
- Agile techniques training – stories, backlog, planning,
vision box, etc.
- Extensive training/coaching of the slated agile coaches
- Mentoring – Coaches, Team, Managers
• Program Development
- Governance approach
• IS Senior Management Updates weekly
• IS Steering Committee Update

• Co-location was sporadic and only occurred during the
core hours
• Resources were part time, not dedicated
• Instituted Core Hours
- 9 hours a week
• Obtained executive buy in and support for the project
and a blended agile methodology
• Established acceptance criteria for project success
• Physical Environment
- Room which was shared with other projects
• Team
- 2 Developers/analysts, 2 extended team developers, 2
Product Owners/QA, Agile Coach apprentice, Agile
Coach

Key Results
– The organization began to view blended agile as just a different
technique for project development
– Future team coaches were developed through the process
– Teams became true teams and morale increased
– Earlier releases into production were enabled giving the customer
faster workable software
• Although only 9 hours a week, when the first release was
implemented the management/team calculated the actual
time form start to finish to be about two weeks.
– Delivering in two weeks workable software was phenomenal
for this company.
– Knowledge of Agile and forming blended practices occurred
simultaneously
– Determining which practices to use occurred simultaneously
– Cross functional knowledge was shared and then utilized for future
projects
– 2 Teams Begun
– Slated two more teams

Lessons Learned
• Establishing the set up of a blended agile project is crucial
to the success of the project; the set up differs per
project.
• No two blended agile projects are exactly alike from a
practice perspective.
• Determine up front the right team members.
• Establish an on boarding process including team
introductions and a project boot camp and implement.
• Consider how to use team members time wisely.
• Research should be done up front.

General Blended Lessons Learned
Lessons Learned
• Each organization is different.
• Any combination of best practices is good.
• Consistently evaluate and adapt.
• Learn your existing process first.
• The amount of time dedicated is ok.
• Co-location is helpful but not necessary.
• Communicate the same message.
• Make sure all organizational levels are on the same page.
• Learn agile principles first, then begin to blend.
• Consider academic but be practical.

Key Takeaways

How to Recommendations
• Agile Core Group/Agile Steering Committee
• Foundation of Knowledge
• Develop community
• Communication
• Collaboration
• Obtain coaching or help from a practical experienced
person in the beginning
• Re-evaluate consistently (inspect and adapt)

Bottom Line
• Agile methods bring many benefits.
• Plan-driven methods bring benefits as well.
• Most companies can not change their processes overnight.
• Utilize practical best practices over academic best practices.
• Collaboration of the best practices feasible within your
company will increase progress.

Core Thoughts to Remember in Blending
• Keep it simple
• Being Agile is the ability to move quickly and respond to
change
– This is a core principle in blended as well
• Build the internal and external capabilities
• Academic vs. Practical
– Training is not enough you actually need experienced
coaching ongoing journey
– Always refer back to the principles for alignment
– Employ changes based on lessons learned, inspect and
adapt
• Collaborate and communicate
– Advertise/communicate what you will do
– Insure and support core believers

Core Thoughts to Remember in Blending
• Adjust the organization’s mindset to be fully
committed by all “no longer a pilot”
• Will not happen with a flip of a switch
• Realize that this is an evolving process

Questions?

Blended Agile

More Related Content

Similar to Blended Agile (20)

More from VersionOne (20)

Recently uploaded (20)

Blended Agile

Editor's Notes