Agile Adoption Strategies

Curing the Disease

Allen HurstHouston Tech Fest - October 9, 2010

Me

The Disease•Symptoms

•Release atrophy

•Constipation of QA canal

•Flabby requirements

•Overactive documentation

•Many more....

“Playing Scrum”

Adoption is Hard

Agile 12 Steps1. Admitted that our organization is not delivering software to its full effectiveness

2. Realized that we are a small part of a large system and change is not easy or instantaneous

3. Embraced that we have responsibility over that system

4. Took pride in the fact that we have the power to affect change

5. Understood that working software is the primary measure of success

6. Became acutely aware that our job is to deliver software according to our customer’s needs

7. Embraced our customer’s values as our values

8. Valued transparency over pride, believe our customer has the right to know the whole truth, and have faith that this approach will build trust.

9. Value feedback from all sources, realize that feedback is how our software improves, and that the opinions of users and customers have a higher priority than our own

10.Provide visibility and predictability as much as possible for our customer

11.We strive for our software to be released with high quality as quickly as possible -- and are willing to consider it done according to our customer’s standards

12.We consider ourselves a partner in guiding our customer toward optimal value

We Have A Cure!Agile Adoption Cure Discovered at AgileDotNet 2010!

Friday, April 30, 2010

Step 1: Get buy-in from senior management

Step 2: Hire a agile coaches (we can help you with that )

Step 3: Stack the deck by prioritizing the projects with the best chance of success

Step 4: Build pilot teams that adopt agile wholesale

Step 5: Stack the deck by concentrating groups of agilists in your other teams

Agile Adoption Surgery

Can’t afford surgery?

AGILISTSDESK

REFERENCE

Trust• Essential component of change

• Identify customer values

• Make changes that meet customer values to build trust

• Trust =

• Visibility

• Transparency

• Successful delivery

• Shared values and trust are the foundation of effective change

Strategy FactsName AffectsCreate a Product Backlog .............................................................. Project Mgmt, Requirements

Uses relieves symptoms due to overactive or deficient requirements documentation,

alleviates prioritization disfunctionBusiness value added Increase flexibility increase visibility reduce cost increase utility to marketAgile values/principles endorsed Individuals and Interactions Working Software Customer Collaboration Responding to Change Simplicity

WarningsDo not use ifEnvironmental politics will add excessive waste due to requirements visibilityBefore use make sure you have a product owner with the authority to make priority decisionsWhen using this strategyProduct backlog must be held as the exclusive source of features change to the backlog is encouraged between iterations all outstanding work items for the product should be in one prioritized listIf your organization starts to show the following symptoms, discontinue use immediately useless waste discharge develops requirements require excessive specification before adding to the backlog backlog cannot be changed and revised due to organizational pressures

DirectionsRecord an initial set of the most valuable work itemsKeep work item documentation very sparse except for the highest priority work itemsEstimate the backlog in terms of development effort (preferably using relative estimates)Estimate the backlog in terms of business valuePrioritize the backlog considering value and costIteratively develop work items, selecting the top priority items from the backlog firstContinually add work items to the backlog as they’re discovered, prioritizing continuously

Other InformationYou may find during use that you choose work items to develop based on value rather than other factors such as last discovered are able to communicate priorities more effectively and with more visibility

Strategy FactsName AffectsCreate a Product Backlog .............................................................. Project Mgmt, RequirementsUses relieves symptoms due to overactive or deficient requirements

documentation, alleviates prioritization disfunctionBusiness value added Increase flexibility increase visibility reduce cost increase utility to marketAgile values/principles endorsed Individuals and Interactions Working Software Customer Collaboration Responding to Change Simplicity

WarningsDo not use ifEnvironmental politics will add excessive waste due to requirements visibility

Before use make sure you have a product owner with the authority to make priority decisions

When using this strategyProduct backlog must be held as the exclusive source of features change to the backlog is encouraged between iterations all outstanding work items for the product should be in one prioritized list

If your organization starts to show the following symptoms, discontinue use immediately useless waste discharge develops requirements require excessive specification before adding to the backlog backlog cannot be changed and revised due to organizational pressures

DirectionsRecord an initial set of the most valuable work itemsKeep work item documentation very sparse except for the highest priority work items

Estimate the backlog in terms of development effort (preferably using relative estimates)

Estimate the backlog in terms of business value

Prioritize the backlog considering value and cost

Iteratively develop work items, selecting the top priority items from the backlog first

Continually add work items to the backlog as they’re discovered, prioritizing continuously

Other InformationYou may find during use that you choose work items to develop based on value rather than other factors such as last discovered are able to communicate priorities more effectively and with more visibility

Invert Your QA

Test Case

Test Case: Schedule an appointmentDescription: This test case simulates one of the actions a patient can perform in the system. The patient will browse available appointments, select a time, and receive a confirmation email.Data Requirements: {username} - patient must log in and already have a completed profile.{password} - must be valid for {username}{selectedtime} - user must select an available timeStep Number

Step Description Expected Result Transaction Name

1 Navigate to application, log in with {username} and {password}

Patient dashboard screen is displayed

user_login

2 Select ‘schedule appointment’ from menu

Doctor schedule is displayed

select_scheduleappointment

3 Select {selectedtime} from doctor schedule

Appointment confirmation screen appears

select_appointmenttime

4 Confirm appointment

Doctor schedule is updated to remove {selectedtime} from available times. Patient receives confirmation email.

confirm_appointmenttime

As a Patient

I want to make an

appointment

So that I can see a

doctor to diagnose

my illness

I can see available appointment

times

I can choose a time and confirm

my choice

No one else can choose the

time I reserved

I receive a confirmation email

Invert Your QA

Strategy FactsName Affect

sInvert your QA............................................................................................. Qualtiy/Requirements

Uses Relieves pain caused by unclear requirements andconstant back and forth movement of deliverables between development and QA. Is most effective in organizations with structured, waterfall practices. Can be helpful to relieve developer/QA tensions.Business value added Increase quality to market Reduce time to marketAgile values/principles endorsed Simplicity is essential Working software over comprehensive documentation

WarningsDo not use ifYour QA professionals cannot be involved in the requirements analysis processBefore use make sure you have a QA group producing quality, comprehensive test cases have sufficient QA resources for creating test cases and executing them against deliverables after implementationWhen using this strategyQA will need to be creating test cases for the next iteration during the current iterationIf your organization starts to show the following symptoms, discontinue use immediately test cases are not able to be defined before development begins deliverables cannot be made because of lack of QA resources

DirectionsCreate test cases for deliverables before implementation occursProvide test cases to developers as instructions for acceptancePerform acceptance testing against test cases after development

Other InformationYou may find during use that you can replace QA resources with BA resources or vice versa in order to meet resource demands

Strategy FactsName Affect

sInvert your QA............................................................................................. Qualtiy/Requirements

Release Software

Practicing Scrum?

Releasing Software After Each Sprint?

see a pattern...?

Release Software

Strategy FactsName Affect

sRelease Software .............................................................................. Infrastructure/Development

Uses Relieves chronic release atrophy and working software attention deficit disorder. Is

effective at enforcing attention to quality throughout development and increases likelihood of incremental release. Is effective at reducing distractions from producing software and eliminating wasteBusiness value added Increase quality to market Reduce time to market Increases visibilityAgile values/principles endorsed Frequent delivery of working software Working software is the primary measure of success Working software over comprehensive documentation

WarningsDo not use ifYour product is in a state where it cannot be used by (at least) test usersBefore use make sure you have a repeatable and automated deployment strategy have an environment that can be used for incremental releasesWhen using this strategyQuality software will need to be produced so that significant release preparation is not necessary

DirectionsCreate a fast, repeatable deployment approachCreate a timeboxed amount of work to be releasedDevelop the features with attention to quality to reduce possibility of defectsTest the features according to the requirementsRelease the application to (at least) an environment where it can be tested by users other than the development team

Other InformationYou may find during use that you have difficulty completing the specified features in a releasable level of quality, adjust your commitment accordingly, this will improve over time tend to focus more on delivering software each iteration rather than creating waste

Add a Demo

Add a Demo

Strategy FactsName AffectsAdd a demo .................................................................................... Project Mgmt, Development, QA

Uses Fights software delivery atrophy by forcing deliverables toward items with demonstrable

business value. Provides visibility and input into the execution of a software project. Relieves chronic quality deficiency through pressure on responding to change and fear of defects. Places a high priority on the delivery of software for the demo.Business value added Increase value to market increases visibility increases flexibilityAgile values/principles endorsed Develop trust Working software is the primary measure of success focus on quality responding to change

WarningsDo not use ifBusiness value truly cannot be demonstrated incrementally.Before use make sure you have quality integrated into the team are capable of accepting midstream feedback and adjusting appropriately (requirements are not fixed)When using this strategy it is important to get attendance from stakeholders use in combination with releasing software is recommended features for a demo can potentially changeIf your organization starts to show the following symptoms, discontinue use immediately demos create unnecessary waste

DirectionsSelect a set of features to developSchedule a demoDevelop the features for the demo (including QA)Perform the demonstration of those featuresCollect and prioritize feedback from the demo

Other InformationYou may find during use that you must develop with higher quality in order to respond to feedback from the demo begin to focus more on demonstrable business value when choosing and executing work

Add a Retrospective

Add a Retrospective

Strategy FactsName Affect

sAdd a Retrospective ..................................................................................................... The Team

Uses relieves persistent forest-for-the-trees syndrome relieve discomfort due to bubble development increases levels of accountability between teammates

Business value added decrease time to market increase value to marketAgile values/principles endorsed individuals and interactions over processes and tools continuous improvement

WarningsDo not use if Candid conversation is not possibleBefore use make sure you have accepted responsibility for the situation you’re in and can effect change assume everyone makes decisions based upon the best information available at the timeWhen using this strategy the goal should be to come to a consensus as a team about tactical changes you can make to solve the problems only a few problems at a time can be effectively addressed be candid, yet respectful include praises as well as criticismsIf your organization starts to show the following symptoms, discontinue use immediately Retrospectives cannot be distinguished from gripe sessions

DirectionsChoose a frequency with which to hold retrospectivesDecide on a format for the retrospectiveCandidly air concerns as well as criticisms within the context of the retrospective format you’ve chosenSelect action items and changes from the set of feedback expressedExecute on those action items between the current retrospective and the next retrospective

Other InformationYou may find during use that you come up with better solutions through interactions with the team than individuals will on their own

Track (Valuable) Metrics

Track the Team an Atomic Unit

Common AdoptionFirst Steps

•Add a Daily Scrum Meeting

•Add a Continuous Integration Build

•Start Writing Automated Tests

Discussion?

AGILEDOTNETIMPROVING ENTERPRISES & MICROSOFT PRESENT

CONFERENCE - HOUSTON 2010

Friday, November 12, 2010Microsoft Offices - Houston

register for $49 - agiledotnet.comuse code ADN-H for 25% off

Thanks!

http://ahurst.com

@allenhurst

http://improvingenterprises.com