modern methodologies: agile, xp programming, and business collaboration 1 raj anantharaman,...

Modern Methodologies: Modern Methodologies: Agile, XP Agile, XP

Programming, Programming, and Business and Business CollaborationCollaboration

1

Raj Anantharaman, Engineering Manager,

Software and Services Group,Intel India Technology Private Limited

Silicon India Java Conference 2011

IntroductionIntroduction• 15 yrs of SW Development Experience• Lead a SW Development team at Intel India,

Bangalore• Agile Practitioner, Evangelizer for past 4 yrs - Won

the Intel Software Quality Award - 2009• Expertise in Web Solutions (Microsoft), CRM

Dynamics, Business Intelligence• B.Tech (EEE), MS (Computer Science), PMP

Certified

2Silicon India Java Conference 2011

TopicsTopics

• Why Agile? • My team’s Journey, Challenges• Results, Benefits of Agile Adoption• 10 Best Practices, Key Learning's• Summary


Why Agile?Why Agile?• Adaptability to Changing Requirements• Continuous and Early customer feedbacks• Better Product Quality• Self Directed Team – Higher Team Cohesiveness• Higher Team Productivity• Build Customer Confidence Early• Early and Improved Visibility of Status• Faster Course Correction


Our Reason for Adopting Our Reason for Adopting AgileAgile

5

Attribute Health Status

Performance Against Schedule

V. GoodOn-Time Releases, Average Length of Releases – 1 per quarter

Customer Satisfaction

GoodCustomers happy with on-time releases, but wanted more frequent releases (2 or more per quarter) – piling backlog

Quality PoorHigh Pre / Post Production Defects, One fix leads to secondary issues, Team in constant fire-fight mode

Team ProductivityPlateau

to Decline

Quality Issues, Heroics from some team members – most others were followers, Team Potential Not Fully Tapped

Team Morale AverageHigh Attrition, Morale was OK – could be better, Team Working Long Hours, Weekends

Cross Geo Team Working Model

AverageInter Team Communication was OK, Work-Life-Balance Sacrifices for some team members

Team Needed a New Way to Deliver More Releases

With Increased Quality and Productivity (hence Morale)


Our Approach – Embrace Agile Our Approach – Embrace Agile

PracticesPractices

6

Practices Benefits

2-week iterations

(Time-Boxed Duration to develop, test and show-case a small set of

requirements)

• Kept team very focused (2-week goals)

• Customers more involved, saw output once in 2 weeks, provided feedbacks early (show case meetings)

• Retrospective every 2 weeks – Easier to course correct

Gain Efficiencies Through Automation

(Test Automation, Continuous Integration, Automated

Localization Scripts)

• Issues caught early – product quality improved progressively

• Developer confidence Improved when making code changes (Safety Net of collection of automated tests)

• Team Productivity Improved

Pair Programming

(2 developers work on a story instead of individually)

• Improved Cross-Team Learning, Collective Ownership of team

• Increased Developer Skills

Open Office Space

(Removed Cubicle Structure)

• More F2F Communication between team members

• Faster resolution of issues


Agile Adoption StrategyAgile Adoption Strategy

• Top-Down – Management Driven Initiativeo Some Believers, Some Skeptics, but overall worked well

• Engage Experts to Coach us through Adoptiono We hired 3 Agile Coaches for 6 months (from an experienced vendor in India)o Worked out very well

• Pilot First and Swift Adoption to Other Projectso Transition Change Management at one timeo Agile Coaches are invaluable here

• Persistence, Commitment, Stick to the Plano Easy to go back to old ways, need persistence, commitmento Management Support is vital

• Make the work place conducive for Agile Development o Invest in a work-space that is conducive for Agile Developmento Closed Wall Cubicles vs. Simple Conf Room Arrangement


Resistance to Agile Resistance to Agile

AdoptionAdoption

8

• “Pair Programming is a Waste of Time”

• I can code this effectively myself

• Why are we paying him to watch how I code?

• “Management has a hidden agenda behind this. I am being Micro Managed”

• Agile Coaches are taking over. They’re calling the shots.

• Management is watching every move very closely (e.g. Daily Stand-Up’s, Retrospectives)

• “I am a skeptic. I don’t believe this.”

• I don’t see it working. We should have just done it using Waterfall. I told you before.

• Customers were happy even before, so what are we really trying to fix?

• “My cubicle is going away. “

• I’ve lost all my privacy. Can I browse the internet? How do I get personal work done?

• My friends in other teams enjoy a full sized cubicle


Agile LifecycleAgile Lifecycle

9

Deployment(2 weeks)

CAT

PlanningIteration#0

Release Planning Meeting (High

Level Estimates, Story Points)

Architecture,High Level

Designs, Env. Setup

Deploy to Production

Approval

Iteration 1(2 weeks)

Code Stories, Unit Tests, Continuous

Integration

Iteration Planning(Task Level Breakdown, Estimates)

Retrospective, Show Case with

Key Stakeholders

Explore

CCB Approval

Project Vision,Business Case

Quick Start Analysis; Master List of Stories;

Approval

Development

Deploy to QA Box,Write Tests

Iteration 2(2 weeks)

Code Stories, Unit Tests, Continuous

Integration

Iteration Planning(Task Level Breakdown, Estimates)

Retrospective, Show Case with

Key Stakeholders

Deploy to QA Box,Write Tests

Day-One Testing


ResultsResults• 15 of 16 On-Time Releases

o Last 4 releases with zero over-time, high quality

• Improved Qualityo Technical Debt reduced from 2400 to 392 (76% improvement)o Lowered Defects Density 3.76 to 0.6 defects/SP

• Improved Team Morale, Stronger Teamo Reduced Attritiono Team Temperature increased from an avg. of 5 to 8o Team Cross-Trained on Code-Base, Less Heroics, More Leaders

• Lower Operational Cost, Higher Output, Innovationso Improved Team Velocity / Productivityo Time to work on Innovationso Improved Cross-Team Collaboration


MetricsMetrics


Best Practice#1: Invest in Best Practice#1: Invest in

Good ToolsGood Tools• Multiple Agile Life Cycle Management Tools in the Market

o Use a tool to manage user stories, defects, project plan, iterations, releaseso Choose a tool that best fits your team’s needso Improves Team Productivity

• Multiple Test Automation Tools (for Developer and QA)o Choose a tool that best fits your team’s needs and skillso Build Passes only when all Developer and QA tests pass


Best Practice #2: Create a Build Best Practice #2: Create a Build

DashboardDashboard

• Continuous Integration is KEY to Agile Successo Build Frequentlyo Integrate build with Unit Tests

(Dev and QA)o All tests MUST pass for Build

To Pass

• Provide a Build Dashboard Setup for team to monitor build statuso Drives Positive Behavior Shift

- Discipline in Developers to check in well tested code

o Place the Build Dashboard in a centrally visible place


Best Practice #3: Provide An Agile Best Practice #3: Provide An Agile

Workspace Workspace


Best Practice #4: For Geo-Distributed Best Practice #4: For Geo-Distributed

Teams, Teams,

best to have Local Business Analystsbest to have Local Business Analysts • Improves Agility of Team

o Quick Answers to Questionso Local BA’s function as Proxy Customers for the team

• Planning Games More Effectiveo Games can be scheduled during Day-Timeo BA’s can make decisions on priority, based on cost / effort

• Local BA’s work directly with customers / stakeholderso Downside: Local BA’s may need to work alternate shifts (e.g. increase

US-India Overlap)


Best Practice #5: Define a Best Practice #5: Define a

Story LifecycleStory Lifecycle• Define the criteria when a

story is considered “Ready to Play”, “done, Done, DONE” etc.o Team mutually agrees to this

criteriao Rigorously Follows It, Holds Each

Other Accountable

• Create a Centrally Visible Story Wall (and a Virtual Wall) o Makes it easy to track story

statuso “done, Done, DONE” is achieved

only when QA has tested a story and customer has signed off on it (acceptance criteria)

o Daily-Stand-Up’s can be conducted around the Story Wall

16

Iteration Backlog

In Development

In Testing

In Customer Review

done, Done, DONE


Best Practice #6: Light Weight Best Practice #6: Light Weight

Estimation TechniquesEstimation Techniques

• We’ve tried Function Points, PERT, Story Points, T-Shirt Sizes, Ideal Hours… We Recommend Story Points through Planning Pokero Accuracy is not important, being

close is good enough o The key value of estimation is in

the discussions that un-earth assumptions or risks, not in the value of the estimate itself

o Size the story first (e.g. Story Points), before estimating effort

o Effort can be calculated based on velocity of team (from previous iterations)

17

Planning Poker Overview• A story is read by the BA• Each developer picks a card (Fibonacci Series – 1, 3, 5 , 7, 8…) and puts it face down• Everyone is asked to reveal the cards at the same time• Discussion ensues on story complexity (esp. if one developer picked 3, another picks 8)• Team repeats the estimation rounds, till all developers agree to an estimate.


Best Practice #7: Set Goals for every Best Practice #7: Set Goals for every

iteration, releaseiteration, release • Set goals to keep team motivated

o Examples: Unit Test Coverage, Quality (e.g. defects per story-point), Velocity (e.g. Story Points Per Person-Day), Technical Debt

o Challenges team, Encourages “Swarming” behaviors (e.g. pick up more stories to work on, unit test thoroughly)

• Use Retrospective meetings to “analyze” metricso Understand what caused a metric to go up or downo Team defines / implements corrective actions as appropriate


Best Practice #8: Measure and Best Practice #8: Measure and

Frequently Repay Technical DebtFrequently Repay Technical Debt• Technical Debt is the sum of Bug Debt (weighted open Post-

Production Defects) and Code Debto Bug Debt Example: A Show Stopper Defect accumulates 20 points for each day its

openo Code Debt Example: Poorly Written Module – Probability / Likelihood of impact;

Amount of Code Duplication, Total Unit Test Coverage, Un-Used Code

• Technical Debt needs to be repaid every iteration / releaseo Set goals, write tech stories (e.g. refactor initiatives module), prioritize as part of

the iteration / release planning gameso Fix post-production defects through separate sustaining releaseso Measuring it enables you to negotiate with your customers


Best Practice #9: Conduct a Practices Maturity Best Practice #9: Conduct a Practices Maturity

Survey to drive continuous improvementsSurvey to drive continuous improvements

• Internal Survey of Practice Level Maturity with the teamo Each team member evaluates adherence to the practiceso Some Sample Questions

• Developers Volunteer for Tasks• We always work on the highest priority story or bug• All stories have success criteria

• Team identifies corrective actions based on survey resultso Sample Corrective Actions Taken

• Publishing Automated Test Results in a dashboard• Conducting Tech Talks / Brown-Bag sessions to share technical BKM’s• No overtime worked in the last 4 releases (due to better planning)


Best Practice#10: Idea’s to Improve Best Practice#10: Idea’s to Improve

Collective OwnershipCollective Ownership

• Conduct Frequent Technology Brown Bag Sessionso Developers Conduct Walk-Through of Code w/ Team

• Very useful, esp. when working with legacy code

o Conduct Code Reviews – to reinforce good developer practices• Can be discontinued once team is up to speed

• Rotate Pairs Every Iterationo No one module is fully developed by a single pair

• If you have a dedicated QA Teamo Pair a QA with a Developero QA’s have very good system level knowledge, can

act as catalyst in improving comfort level

• Having a good set of automated testso Difficult to build, esp. in Legacy Code, but invaluable


SummarySummaryAgile Practices Adoption has resulted in:

• Positive Changes in Our Deliverables High Quality, Low Technical Debt - 76% improvement Defects Density reduced from 3.76 to just 0.6 defects/SP More Time for Innovative Solutions

• Positive Changes in Our Team Team more self-managed, mature, more skills Improved Productivity Levels - 0.1 to 0.65 SP’s/person-day Morale is highest ever Zero over time worked in last 4 consecutive releases

• Positive Changes for our Customers Key Program Metrics Improving Rapidly Faster Releases (2-3 per quarter) – reduced backlog


BackupBackup

23

Key Agile PracticesKey Agile PracticesPractice What Is It? Expected Benefits?

2-week iterations

Time-Boxed Duration to develop, test and show-case a small set of requirements.

Multiple Iterations make up a release

• Customer tests features early (every 2 weeks) vs. waiting till CAT

• Keeps team very focused (2-week goals)

• Course Corrections Easier

Automated Unit Tests

Scripts that unit tests developer code (classes and methods)

• Improves Code Quality

• Increases developer confidence when making changes (Safety Net)

Automated QA Tests

Scripts that tests the functional user scenarios (e.g. user enrolment)

• Improves Outgoing Product Quality

• Reduces Manual Time spent on Quality Testing

Pair Programming2 developers pair to work on a requirement instead of individually

• Improves Cross-Team Learning

• Increases Developer Skills

Daily Stand-Up Meetings

15 min meeting each day where team members provide a status update

• Improves Transparency

• Increases Communication Between Team Members24

25

Legal DisclaimerLegal Disclaimer• INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL® PRODUCTS. NO LICENSE,

EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPETY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL’S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL® PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT.

• Intel may make changes to specifications and product descriptions at any time, without notice.• All products, dates, and figures specified are preliminary based on current expectations, and are subject to change

without notice.• Intel, processors, chipsets, and desktop boards may contain design defects or errors known as errata, which may cause

the product to deviate from published specifications. Current characterized errata are available on request.• Intel AppUp Center, Intel AppUp developer program and other code names featured are used internally within Intel to

identify products that are in development and not yet publicly announced for release. Customers, licensees and other third parties are not authorized by Intel to use code names in advertising, promotion or marketing of any product or

services and any such use of Intel's internal code names is at the sole risk of the user • Performance tests and ratings are measured using specific computer systems and/or components and reflect the

approximate performance of Intel products as measured by those tests. Any difference in system hardware or software design or configuration may affect actual performance.

• Intel, and the Intel logo are trademarks of Intel Corporation in the United States and other countries. • *Other names and brands may be claimed as the property of others.• Copyright ©2011 Intel Corporation.

26

Risk FactorsRisk FactorsThe above statements and any others in this document that refer to plans and expectations for the second quarter, the year and the future are forward-looking statements that involve a number of risks and uncertainties. Many factors could affect Intel’s actual results, and variances from Intel’s current expectations regarding such factors could cause actual results to differ materially from those expressed in these forward-looking statements. Intel presently considers the following to be the important factors that could cause actual results to differ materially from the corporation’s expectations. Demand could be different from Intel's expectations due to factors including changes in business and economic conditions; customer acceptance of Intel’s and competitors’ products; changes in customer order patterns including order cancellations; and changes in the level of inventory at customers. Intel operates in intensely competitive industries that are characterized by a high percentage of costs that are fixed or difficult to reduce in the short term and product demand that is highly variable and difficult to forecast. Additionally, Intel is in the process of transitioning to its next generation of products on 32nm process technology, and there could be execution issues associated with these changes, including product defects and errata along with lower than anticipated manufacturing yields. Revenue and the gross margin percentage are affected by the timing of new Intel product introductions and the demand for and market acceptance of Intel's products; actions taken by Intel's competitors, including product offerings and introductions, marketing programs and pricing pressures and Intel’s response to such actions; defects or disruptions in the supply of materials or resources; and Intel’s ability to respond quickly to technological developments and to incorporate new features into its products. The gross margin percentage could vary significantly from expectations based on changes in revenue levels; product mix and pricing; start-up costs, including costs associated with the new 32nm process technology; variations in inventory valuation, including variations related to the timing of qualifying products for sale; excess or obsolete inventory; manufacturing yields; changes in unit costs; impairments of long-lived assets, including manufacturing, assembly/test and intangible assets; the timing and execution of the manufacturing ramp and associated costs; and capacity utilization. Expenses, particularly certain marketing and compensation expenses, as well as restructuring and asset impairment charges, vary depending on the level of demand for Intel's products and the level of revenue and profits. The majority of our non-marketable equity investment portfolio balance is concentrated in the flash memory market segment, and declines in this market segment or changes in management’s plans with respect to our investment in this market segment could result in significant impairment charges, impacting restructuring charges as well as gains/losses on equity investments and interest and other. Intel's results could be impacted by adverse economic, social, political and physical/infrastructure conditions in countries where Intel, its customers or its suppliers operate, including military conflict and other security risks, natural disasters, infrastructure disruptions, health concerns and fluctuations in currency exchange rates. Intel’s results could be affected by the timing of closing of acquisitions and divestitures. Intel's results could be affected by adverse effects associated with product defects and errata (deviations from published specifications), and by litigation or regulatory matters involving intellectual property, stockholder, consumer, antitrust and other issues, such as the litigation and regulatory matters described in Intel's SEC reports. An unfavorable ruling could include monetary damages or an injunction prohibiting us from manufacturing or selling one or more products, precluding particular business practices, impacting our ability to design our products, or requiring other remedies such as compulsory licensing of intellectual property. A detailed discussion of these and other factors that could affect Intel’s results is included in Intel’s SEC filings, including the report on Form 10-Q for the quarter ended March 27, 2010.

modern methodologies: agile, xp programming, and business collaboration 1 raj anantharaman,...

Documents