Blended Agile

CC Pace Proprietary www.ccpace.com

Blended AgileJuly 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 BacklogAs prioritized by Product Owner

Iteration Backlog

Backlog tasks

expandedby team

Potentially ShippableProduct 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 ThinkingGathering 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.

Fewell, Phil

Hey Rose - I'm not sure I understand these two points???


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 ways2. Roles/Responsibilities will change3. Interactions will change4. Processes will change5. 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-responsiveTo

Change

ResponsiveTo

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?

Technology

Blended Agile