SlideShare a Scribd company logo

Introducing Agile Development in Traditional Software Development Organizations

•Download as PPT, PDF•
•
J
juliannacole

Highlights of actions taken to during the 2006/2007 introduction of Agile development techniques to Tribune Interactive's software development and business stakeholders.

Related slideshows

Software Development Metrics-JPayne
Software Development Metrics-JPayneSoftware Development Metrics-JPayne
Software Development Metrics-JPayne
 
An Agile Overview @ ShoreTel Sky
An Agile Overview @ ShoreTel SkyAn Agile Overview @ ShoreTel Sky
An Agile Overview @ ShoreTel Sky
 
TDWI STL 20140613 Agile - Paul Holway
TDWI STL 20140613 Agile - Paul HolwayTDWI STL 20140613 Agile - Paul Holway
TDWI STL 20140613 Agile - Paul Holway
 
1 of 14
Agile @ TI Last Updated 1/22/07 J. Cole Intended Audience: Non-Technical
“We Need to Move Faster”  Agile Champions  Tribune Interactive CTO  Senior developers • High level of initiative • Constructive criticism of challenges to rapid development  Selling Agile to Senior Management  Accelerated availability of early iterations of product  Increased ability to evolve product  Ability to start projects sooner (but not necessarily completed sooner)  Reactions • Extremely positive, willing to invest in Agile training BUT • Difficult to overcome inertia of ingrained development practicies 2
3 Agile @ TI – Thoughts on Structure and Organization from October ‘05  Product Development  Small, empowered teams (3-5)  Minimal stakeholder documents and initial communication • Initiation document, use case inventory/story list, critical wire frames and page designs (those used to obtain approval from senior management)  Ongoing collaboration with technology to elaborate on prioritized storylist to support iterative cycles  Technology  Small, empowered teams (4+ depending on timelines,etc.)  Integration of tracking and behavioral mechanisms to support customer-feedback loop  Weekly or bi-weekly software releases (after initial 2-3 week development cycle)  Local Markets  Provision of “beta” area on web site  Feedback on initial stakeholder documents This assumes completion of earlier Strategic Marketing, Product Development, ISC conversations
4 Agile @ TI  What is Agile?  A conceptual framework for software development projects  Various implementations of the framework  Most often used in small organizations  Gaining acceptance in large organizations and enterprise software organizations  Not Web 2.0 software development  TI’s approach to Agile  Leverages many Agile concepts  Recognizes reality of where we are today vs. long-term goals  Provides an opportunity to address change in an evolutionary manner • “Walk before you can run”  Key Agile Concepts  Individuals and interactions over processes and tool  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan
5 Agile @ TI – Early Observations  Agile will remind you of traditional “waterfall” methodologies  Similar steps, but repeated weekly or bi-weekly  Recycled concepts w/a “twist” – e.g. use cases => stories  Optional efforts are now enforced with a high degree of discipline – e.g. unit testing  “Flipped” ExtroVert from waterfall to Agile in the middle of the project  Introduced issues, but overall still feels directionally correct  Highlights issues with introducing Agile at TI – will customize the methodology, like other organizations • Opportunity to adjust the process for future projects • Collaboration between Technology, Product Development and Marketing is critical due to “just in time” estimation and prioritization process  TI’s ability to successfully leverage Agile development rests largely on how the organization approaches Iteration 0 (or its variants) Iteration 0 is Critical!
6 Agile Development – The Ideal •TI processes do not currently allow for assignment of resources prior to project approval •This step is critical to estimating final release and production schedules
7 Agile @ TI – Current Proposal (revised from October ‘05)  Obtain approval from senior management Approval Date(AD) Product Development Initiation document – business case, storyist V1.0, wire frames, etc.  Iteration 0 (I0) 2-4 weeks post AD Product Development & Technology Storylist V2.0 – Success criteria, confirm prioritization ,pre-IPM effort estimation Environment – Create environments (Dev, QA, User Acceptance,etc.) Prepare initial iteration schedule and release plan **Review iteration schedule/release plan, revise if necessary  First iteration (I1) 5-7 days post I0 Technology, Product Development See next slide for detailed efforts  Second iteration (I2) 1 week post I1 Technology, Product Development  Nth iteration (IN) 1 week post IN-1 Technology, Product Development  Release N Determined by team Technology, Product Development
8 Agile @ TI – Storylist Artifacts • Story Cards • Fundamental building block of Agile/XP • Feature description • Small, measurable • Can be completed in 1-2 days by 1 developer • Includes any relevant assumption(s) • Used for preliminary estimation of effort • Assigned a “pre-ipm” value • Relative weighting – a scale of effort • No direct correlation to number of days for the effort • Later refined into “ideal days” estimates • Some teams use actual index cards • Aggregate cards and create a file with additional details to support next steps As a USER I want a home page for each neighborhood in my market that displays only content related to that neighborhood ASSUMPTION: Only content with a geocode 5 Pre-IPM Points Page 143 Story #151
9 Agile @ TI – Weekly Iteration Schedule (actual)  Each day begins with a 15 minute “stand-up” meeting of all team members Day Day of Week Event Owner 1 Thursday AM Iteration Planning Meeting Review of Past Iteration Review progress Demo of new functionality Planning for Current Iteration Story presentation Iteration planning/tasking Story selection/assignment PM (Manish) Developers Developers & QA BA (Sandra) IPM (Olivier), PM (Manish) Developers 1 Thursday PM Select Stories for the next iteration Determine needed design and send to Manifest Digital Publish and distribute list of selected story cards Update MS Project plan and send to Product Development project manager (Jim Marzullo) BA (Sandra), IPM (Olivier), PM (Manish) BA (Sandra), PM (Manish), IPM (Olivier) IPM (Olivier) PM (Manish) 2-3 Friday & Monday Create story analysis artifacts for next iteration BA (Sandra) 4 Tuesday AM Publish and distribute story analysis artifacts for next iteration to team (evstoryreview@tribuneinteractive.com) BA (Sandra) 5 Wednesday Noon Send feedback and request for clarification to EvStoryReview mailing list Stakeholders 5 Wednesday PM Update and publish story analysis artifacts for next iteration based on feedback BA (Sandra)
10 Agile @ TI – Sample Story Narrative
11 Agile @ TI – Project Management Tools Story List Project roadmap Issue management
12 Agile @ TI – Project Management Tools  “Burn Down” charts and capacity charts  Measures the team’s velocity vs. overall project goal  Reflects the development capacity of the team  Should increase over time
Agile @ TI Project post-mortem informed TI’s Agile approach  All story estimates are in ideal days w/contingency • Point abstraction increases the difficulty of managing business stakeholders  Use explicit contingency until project stability supports confidence in velocity metrics • Team velocity is sensitive WRT team dynamics, experience of business stakeholder, availability of business stakeholder, etc.  Technology should play a greater role in story selection for early iterations • Business stakeholders’ focus on consumer-facing features can compromise early infrastructure stories  Test coverage should improve by 5% each iteration until 85-90% • Team members will require additional time to master TDD  Next Efforts  Integrate distributed team members into project (in-progress, results are positive)  Integrate offshore team into projects(2nd attempt)  Permanent reconfiguration of team’s working environment  Investigate more sophisticated Agile project management tools  Finalize criteria for selection of Agile approach for other projects Stakeholder sensibilities and availability Aptitude and attitude of most likely team Project’s business climate 13
14 Agile @ TI – Next Steps  Resolve Iteration 0 disconnects  Develop estimates that allow us to answer typical senior management questions  Minimize amount time on detailed requirements in favor of actual product development  What is the minimum information that will satisfy business model justification and reasonably accurate estimates in support of approval by senior management?  Resolve “just in time” estimation disconnects  Pre-IPM estimations are used to communicate broad schedule and timing, and obtain buy-in from management  Subsequent story refinements may result in estimations that exceed pre-IPM estimates  Expand Training  Agile methodology, Story development fundamentals, etc.  Leverage a training organization • Mesh “classroom” theory with ongoing, real-world learnings from ExtroVert  Select first 100% Agile project • Incorporate the process from project inception to completion Q&A

More Related Content

Introducing Agile Development in Traditional Software Development Organizations

  • 1. Agile @ TI Last Updated 1/22/07 J. Cole Intended Audience: Non-Technical
  • 2. “We Need to Move Faster”  Agile Champions  Tribune Interactive CTO  Senior developers • High level of initiative • Constructive criticism of challenges to rapid development  Selling Agile to Senior Management  Accelerated availability of early iterations of product  Increased ability to evolve product  Ability to start projects sooner (but not necessarily completed sooner)  Reactions • Extremely positive, willing to invest in Agile training BUT • Difficult to overcome inertia of ingrained development practicies 2
  • 3. 3 Agile @ TI – Thoughts on Structure and Organization from October ‘05  Product Development  Small, empowered teams (3-5)  Minimal stakeholder documents and initial communication • Initiation document, use case inventory/story list, critical wire frames and page designs (those used to obtain approval from senior management)  Ongoing collaboration with technology to elaborate on prioritized storylist to support iterative cycles  Technology  Small, empowered teams (4+ depending on timelines,etc.)  Integration of tracking and behavioral mechanisms to support customer-feedback loop  Weekly or bi-weekly software releases (after initial 2-3 week development cycle)  Local Markets  Provision of “beta” area on web site  Feedback on initial stakeholder documents This assumes completion of earlier Strategic Marketing, Product Development, ISC conversations
  • 4. 4 Agile @ TI  What is Agile?  A conceptual framework for software development projects  Various implementations of the framework  Most often used in small organizations  Gaining acceptance in large organizations and enterprise software organizations  Not Web 2.0 software development  TI’s approach to Agile  Leverages many Agile concepts  Recognizes reality of where we are today vs. long-term goals  Provides an opportunity to address change in an evolutionary manner • “Walk before you can run”  Key Agile Concepts  Individuals and interactions over processes and tool  Working software over comprehensive documentation  Customer collaboration over contract negotiation  Responding to change over following a plan
  • 5. 5 Agile @ TI – Early Observations  Agile will remind you of traditional “waterfall” methodologies  Similar steps, but repeated weekly or bi-weekly  Recycled concepts w/a “twist” – e.g. use cases => stories  Optional efforts are now enforced with a high degree of discipline – e.g. unit testing  “Flipped” ExtroVert from waterfall to Agile in the middle of the project  Introduced issues, but overall still feels directionally correct  Highlights issues with introducing Agile at TI – will customize the methodology, like other organizations • Opportunity to adjust the process for future projects • Collaboration between Technology, Product Development and Marketing is critical due to “just in time” estimation and prioritization process  TI’s ability to successfully leverage Agile development rests largely on how the organization approaches Iteration 0 (or its variants) Iteration 0 is Critical!
  • 6. 6 Agile Development – The Ideal •TI processes do not currently allow for assignment of resources prior to project approval •This step is critical to estimating final release and production schedules
  • 7. 7 Agile @ TI – Current Proposal (revised from October ‘05)  Obtain approval from senior management Approval Date(AD) Product Development Initiation document – business case, storyist V1.0, wire frames, etc.  Iteration 0 (I0) 2-4 weeks post AD Product Development & Technology Storylist V2.0 – Success criteria, confirm prioritization ,pre-IPM effort estimation Environment – Create environments (Dev, QA, User Acceptance,etc.) Prepare initial iteration schedule and release plan **Review iteration schedule/release plan, revise if necessary  First iteration (I1) 5-7 days post I0 Technology, Product Development See next slide for detailed efforts  Second iteration (I2) 1 week post I1 Technology, Product Development  Nth iteration (IN) 1 week post IN-1 Technology, Product Development  Release N Determined by team Technology, Product Development
  • 8. 8 Agile @ TI – Storylist Artifacts • Story Cards • Fundamental building block of Agile/XP • Feature description • Small, measurable • Can be completed in 1-2 days by 1 developer • Includes any relevant assumption(s) • Used for preliminary estimation of effort • Assigned a “pre-ipm” value • Relative weighting – a scale of effort • No direct correlation to number of days for the effort • Later refined into “ideal days” estimates • Some teams use actual index cards • Aggregate cards and create a file with additional details to support next steps As a USER I want a home page for each neighborhood in my market that displays only content related to that neighborhood ASSUMPTION: Only content with a geocode 5 Pre-IPM Points Page 143 Story #151
  • 9. 9 Agile @ TI – Weekly Iteration Schedule (actual)  Each day begins with a 15 minute “stand-up” meeting of all team members Day Day of Week Event Owner 1 Thursday AM Iteration Planning Meeting Review of Past Iteration Review progress Demo of new functionality Planning for Current Iteration Story presentation Iteration planning/tasking Story selection/assignment PM (Manish) Developers Developers & QA BA (Sandra) IPM (Olivier), PM (Manish) Developers 1 Thursday PM Select Stories for the next iteration Determine needed design and send to Manifest Digital Publish and distribute list of selected story cards Update MS Project plan and send to Product Development project manager (Jim Marzullo) BA (Sandra), IPM (Olivier), PM (Manish) BA (Sandra), PM (Manish), IPM (Olivier) IPM (Olivier) PM (Manish) 2-3 Friday & Monday Create story analysis artifacts for next iteration BA (Sandra) 4 Tuesday AM Publish and distribute story analysis artifacts for next iteration to team (evstoryreview@tribuneinteractive.com) BA (Sandra) 5 Wednesday Noon Send feedback and request for clarification to EvStoryReview mailing list Stakeholders 5 Wednesday PM Update and publish story analysis artifacts for next iteration based on feedback BA (Sandra)
  • 10. 10 Agile @ TI – Sample Story Narrative
  • 11. 11 Agile @ TI – Project Management Tools Story List Project roadmap Issue management
  • 12. 12 Agile @ TI – Project Management Tools  “Burn Down” charts and capacity charts  Measures the team’s velocity vs. overall project goal  Reflects the development capacity of the team  Should increase over time
  • 13. Agile @ TI Project post-mortem informed TI’s Agile approach  All story estimates are in ideal days w/contingency • Point abstraction increases the difficulty of managing business stakeholders  Use explicit contingency until project stability supports confidence in velocity metrics • Team velocity is sensitive WRT team dynamics, experience of business stakeholder, availability of business stakeholder, etc.  Technology should play a greater role in story selection for early iterations • Business stakeholders’ focus on consumer-facing features can compromise early infrastructure stories  Test coverage should improve by 5% each iteration until 85-90% • Team members will require additional time to master TDD  Next Efforts  Integrate distributed team members into project (in-progress, results are positive)  Integrate offshore team into projects(2nd attempt)  Permanent reconfiguration of team’s working environment  Investigate more sophisticated Agile project management tools  Finalize criteria for selection of Agile approach for other projects Stakeholder sensibilities and availability Aptitude and attitude of most likely team Project’s business climate 13
  • 14. 14 Agile @ TI – Next Steps  Resolve Iteration 0 disconnects  Develop estimates that allow us to answer typical senior management questions  Minimize amount time on detailed requirements in favor of actual product development  What is the minimum information that will satisfy business model justification and reasonably accurate estimates in support of approval by senior management?  Resolve “just in time” estimation disconnects  Pre-IPM estimations are used to communicate broad schedule and timing, and obtain buy-in from management  Subsequent story refinements may result in estimations that exceed pre-IPM estimates  Expand Training  Agile methodology, Story development fundamentals, etc.  Leverage a training organization • Mesh “classroom” theory with ongoing, real-world learnings from ExtroVert  Select first 100% Agile project • Incorporate the process from project inception to completion Q&A