1
Modern Methodologies:
Agile, XP Programming,
and Business Collaboration
Raj Anantharaman,
Engineering Manager,
Software and Services Group,
Intel India Technology Private Limited
Silicon India Java Conference 2011
Introduction
• 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
Silicon India Java Conference 2011
2
Topics
•
•
•
•
•
Why Agile?
My team’s Journey, Challenges
Results, Benefits of Agile Adoption
10 Best Practices, Key Learning's
Summary
Silicon India Java Conference 2011
3
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
Silicon India Java Conference 2011
4
Our Reason for Adopting Agile
Attribute
Health
Performance Against
Schedule
V. Good
Status
On-Time Releases, Average Length of Releases – 1 per quarter
Customer
Satisfaction
Good
Customers happy with on-time releases, but wanted more frequent
releases (2 or more per quarter) – piling backlog
Quality
Poor
High Pre / Post Production Defects, One fix leads to secondary
issues, Team in constant fire-fight mode
Plateau to
Decline
Quality Issues, Heroics from some team members – most others
were followers, Team Potential Not Fully Tapped
Team Morale
Average
High Attrition, Morale was OK – could be better, Team Working
Long Hours, Weekends
Cross Geo Team
Working Model
Average
Inter Team Communication was OK, Work-Life-Balance Sacrifices
for some team members
Team Productivity
Team Needed a New Way to Deliver More Releases
With Increased Quality and Productivity (hence Morale)
Silicon India Java Conference 2011
5
Our Approach – Embrace Agile
Practices
Practices
2-week iterations
(Time-Boxed Duration to develop, test
and show-case a small set of
requirements)
Gain Efficiencies Through
Automation
(Test Automation, Continuous
Integration, Automated Localization
Scripts)
Pair Programming
(2 developers work on a story instead of
individually)
Open Office Space
(Removed Cubicle Structure)
Silicon India Java Conference 2011
Benefits
• 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
• Issues caught early – product quality improved
progressively
• Developer confidence Improved when making code
changes (Safety Net of collection of automated tests)
• Team Productivity Improved
• Improved Cross-Team Learning, Collective Ownership
of team
• Increased Developer Skills
• More F2F Communication between team members
• Faster resolution of issues
6
Agile Adoption Strategy
Top-Down – Management Driven Initiative
•
o
Engage Experts to Coach us through Adoption
•
o
o
o
o
Transition Change Management at one time
Agile Coaches are invaluable here
Persistence, Commitment, Stick to the Plan
o
o
•
We hired 3 Agile Coaches for 6 months (from an experienced vendor in India)
Worked out very well
Pilot First and Swift Adoption to Other Projects
•
•
Some Believers, Some Skeptics, but overall worked well
Easy to go back to old ways, need persistence, commitment
Management Support is vital
Make the work place conducive for Agile Development
o
o
Invest in a work-space that is conducive for Agile Development
Closed Wall Cubicles vs. Simple Conf Room Arrangement
Silicon India Java Conference 2011
7
Resistance to Agile
Adoption
•
•
•
•
“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
Silicon India Java Conference 2011
8
Development
Explore
Planning
Iteration#0
Project Vision,
Business Case
Architecture,
High Level
Designs, Env.
Setup
Iteration 1
(2 weeks)
Iteration 2
(2 weeks)
Deployment
(2 weeks)
Iteration Planning
(Task Level
Breakdown,
Estimates)
CAT
Agile Lifecycle
Iteration Planning
(Task Level
Breakdown,
Estimates)
CCB Approval
Approval
Release Planning
Meeting (High
Level Estimates,
Story Points)
Quick Start
Analysis; Master
List of Stories;
Code Stories, Unit
Tests, Continuous
Integration
Code Stories, Unit
Tests, Continuous
Integration
Retrospective,
Show Case with
Key Stakeholders
Retrospective,
Show Case with
Key Stakeholders
Deploy to QA Box,
Write Tests
Deploy to QA Box,
Write Tests
Deploy to
Production
Approval
Silicon India Java Conference 2011
Day-One Testing
9
Results
•
15 of 16 On-Time Releases
o
•
Improved Quality
o
o
•
Technical Debt reduced from 2400 to 392 (76% improvement)
Lowered Defects Density 3.76 to 0.6 defects/SP
Improved Team Morale, Stronger Team
o
o
o
•
Last 4 releases with zero over-time, high quality
Reduced Attrition
Team Temperature increased from an avg. of 5 to 8
Team Cross-Trained on Code-Base, Less Heroics, More Leaders
Lower Operational Cost, Higher Output, Innovations
o
o
o
Improved Team Velocity / Productivity
Time to work on Innovations
Improved Cross-Team Collaboration
Silicon India Java Conference 2011
10
Metrics
Silicon India Java Conference 2011
11
Best Practice#1: Invest in Good
Tools
•
Multiple Agile Life Cycle Management Tools in the Market
o
o
o
•
Use a tool to manage user stories, defects, project plan, iterations, releases
Choose a tool that best fits your team’s needs
Improves Team Productivity
Multiple Test Automation Tools (for Developer and QA)
o
o
Choose a tool that best fits your team’s needs and skills
Build Passes only when all Developer and QA tests pass
Silicon India Java Conference 2011
12
Best Practice #2: Create a Build Dashboard
Silicon India Java Conference 2011
•
Continuous Integration is KEY to
Agile Success
o Build Frequently
o 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 status
o Drives Positive Behavior Shift Discipline in Developers to
check in well tested code
o Place the Build Dashboard in a
centrally visible place
13
Best Practice #3: Provide An Agile Workspace
Silicon India Java Conference 2011
14
Best Practice #4: For Geo-Distributed Teams,
best to have Local Business Analysts
•
Improves Agility of Team
o
o
•
Planning Games More Effective
o
o
•
Quick Answers to Questions
Local BA’s function as Proxy Customers for the team
Games can be scheduled during Day-Time
BA’s can make decisions on priority, based on cost / effort
Local BA’s work directly with customers / stakeholders
o
Downside: Local BA’s may need to work alternate shifts (e.g. increase USIndia Overlap)
Silicon India Java Conference 2011
15
Best Practice #5: Define a Story
Lifecycle
•
Define the criteria when a story is
considered “Ready to Play”, “done,
Done, DONE” etc.
o
o
•
Iteration
Backlog
In Development
In Testing
In
Customer
Review
done,
Done,
DONE
Create a Centrally Visible Story
Wall (and a Virtual Wall)
o
o
o
Silicon India Java Conference 2011
Team mutually agrees to this
criteria
Rigorously Follows It, Holds Each
Other Accountable
Makes it easy to track story status
“done, Done, DONE” is achieved
only when QA has tested a story
and customer has signed off on it
(acceptance criteria)
Daily-Stand-Up’s can be
conducted around the Story Wall
16
Best Practice #6: Light Weight Estimation
Techniques
•
We’ve tried Function Points, PERT,
Story Points, T-Shirt Sizes, Ideal
Hours… We Recommend Story
Points through Planning Poker
o
o
o
o
Accuracy is not important, being
close is good enough
The key value of estimation is in the
discussions that un-earth
assumptions or risks, not in the value
of the estimate itself
Size the story first (e.g. Story Points),
before estimating effort
Effort can be calculated based on
velocity of team (from previous
iterations)
Silicon India Java Conference 2011
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.
17
Best Practice #7: Set Goals for every
iteration, release
•
Set goals to keep team motivated
o
o
•
Examples: Unit Test Coverage, Quality (e.g. defects per story-point), Velocity (e.g.
Story Points Per Person-Day), Technical Debt
Challenges team, Encourages “Swarming” behaviors (e.g. pick up more stories to
work on, unit test thoroughly)
Use Retrospective meetings to “analyze” metrics
o
o
Understand what caused a metric to go up or down
Team defines / implements corrective actions as appropriate
Silicon India Java Conference 2011
18
Best Practice #8: Measure and
Frequently Repay Technical Debt
•
Technical Debt is the sum of Bug Debt (weighted open Post-Production Defects)
and Code Debt
o
o
•
Bug Debt Example: A Show Stopper Defect accumulates 20 points for each day its
open
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 / release
o
o
o
Set goals, write tech stories (e.g. refactor initiatives module), prioritize as part of the
iteration / release planning games
Fix post-production defects through separate sustaining releases
Measuring it enables you to negotiate with your customers
Silicon India Java Conference 2011
19
Best Practice #9: Conduct a Practices Maturity
Survey to drive continuous improvements
•
Internal Survey of Practice Level Maturity with the team
o
o
Each team member evaluates adherence to the practices
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 results
o
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)
Silicon India Java Conference 2011
20
Best Practice#10: Idea’s to Improve Collective
Ownership
•
Conduct Frequent Technology Brown Bag Sessions
o
Developers Conduct Walk-Through of Code w/ Team
•
o
Conduct Code Reviews – to reinforce good developer
practices
•
•
No one module is fully developed by a single pair
If you have a dedicated QA Team
o
o
•
Can be discontinued once team is up to speed
Rotate Pairs Every Iteration
o
•
Very useful, esp. when working with legacy code
Pair a QA with a Developer
QA’s have very good system level knowledge, can act
as catalyst in improving comfort level
Having a good set of automated tests
o
Difficult to build, esp. in Legacy Code, but invaluable
Silicon India Java Conference 2011
21
Summary
Agile 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
Silicon India Java Conference 2011
22
Backup
23
Key Agile Practices
Practice
2-week iterations
What Is It?
Expected Benefits?
Time-Boxed Duration to
develop, test and show-case
a small set of requirements.
• Customer tests features early (every
2 weeks) vs. waiting till CAT
Multiple Iterations make up
a release
• 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
Automated QA
Tests
Scripts that tests the
functional user scenarios
(e.g. user enrolment)
• Improves Outgoing Product Quality
2 developers pair to work
on a requirement instead of
individually
• Improves Cross-Team Learning
15 min meeting each day
where team members
provide a status update
• Improves Transparency
Pair Programming
Daily Stand-Up
Meetings 24
• Increases developer confidence when
making changes (Safety Net)
• Reduces Manual Time spent on
Quality Testing
• Increases Developer Skills
• Increases Communication Between
Team Members
Legal 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.
25
Risk Factors
The above statements and any others in this document that refer to plans and expectations for the second quarter, the year and the future are forwardlooking 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.
26