Post on 04-Jan-2016
The Disease•Symptoms
•Release atrophy
•Constipation of QA canal
•Flabby requirements
•Overactive documentation
•Many more....
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
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
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
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
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
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
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
Common AdoptionFirst Steps
•Add a Daily Scrum Meeting
•Add a Continuous Integration Build
•Start Writing Automated Tests
AGILEDOTNETIMPROVING ENTERPRISES & MICROSOFT PRESENT
CONFERENCE - HOUSTON 2010
Friday, November 12, 2010Microsoft Offices - Houston
register for $49 - agiledotnet.comuse code ADN-H for 25% off