Marc Crudgington, MBA, profile picture
Uploaded byMarc Crudgington, MBA
PPTX, PDF1,203 views

Agile Development Product Delivery For Successful Organizations

This document provides an overview of agile development and product delivery methods for successful organizations. It includes an interactive agenda covering topics such as agile frameworks versus processes, common agile methodologies like Scrum, planning and estimating, principles of agile development, adopting agile practices, and potential impediments to agile adoption.

Embed presentation

Downloaded 53 times
Agile Development: Product Delivery for Successful Organizations Marc Crudgington © Copyright Pacific Technology Consulting Group, LLC
Interactive Agenda: Pick a Topic Framework vs. Process Agile Types Scrum Estimating/Planning Buzzwords Resources Agile Iterative or Principles Predictive Adopting Agile Build Delivery Impediments Agile Success Evolution Tools 2
3
Bio / Info • Career – US Air Force, 3Com, ONI/Ciena, Mortgage/Countrywide, KPMG, Jefferson Wells, Autobytel, ASM • Entrepreneurship – Adventure Travel, Consulting, Mortgage, Consulting • Education – MBA, BBA, ACS, AEE • Certifications – PMP, CSM, TOGAF, ITIL, ISS, CISM, CISA • Personal – Married to Maricris 01/2004, Two boys: Jake 5 / Luke 2 4
Framework vs. Process Framework Process • Set of principles with no parent- • Prescriptive and linear series of child relationship which within steps taken to repeatedly activities are performed. generate the same output. • Not all components required to • All components used be used • It is a sequence / same order • Not always used in the same • Structured order • PMBOK (Project Management • Less structured Body of Knowledge), Waterfall • Agile 5
Iterative or Predictive Predictive • Characteristics – Plan driven, heavy load upfront, structured – Sequential, bureaucratic, change resistant – Design: intensive, 10%; Construction manual, 90% – End result pre-determined • Steps – Idea, Requirement, Design, Construct, Integrate, Test, Implement, Maintain 6
Iterative or Predictive Predictive • Use when – Project familiar – Inexperienced developers – Project team is large and project is complex – Thoroughly documented, demands order – Predictability versus change, requirements stable • IMO – Civil engineering, Construction – Maybe government, government contractors, pharma? 7
Iterative or Predictive Iterative • Characteristics – Ambiguity okay, code oriented, adaptable – Welcome change, feedback, people vs. process – Design: creative, 80%; Construction automate, 20% – End result evolving • Steps – Brainstorm/plan, Development, Deliver, Feedback 8
Iterative or Predictive Iterative • Use when – Project evolves or a little unknown – Accept change – Team small; strategies for large/split – Rapid change can occur • IMO – Information Technology 9
Iterative or Predictive Comparison Agile Waterfall Informal/Incremental Documented/Steps Teamwork/Collaboration Individual Continuous Integration End or Milestones Light process Heavy process Open door Limited Cross trained Segmented Active developers Developers sit and wait No surprises at end Validate requirements QA helps produce QA certifies Empowerment Controlling Best app for customer Satisfy requirements, contracts 10
Agile Principles Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 11
Agile Principles Principles behind the Agile Manifesto We follow these principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 12
Agile Principles Principles behind the Agile Manifesto (cont.) 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 13
Agile Principles Authors of the Agile Manifesto Kent Beck Ron Jeffries Mike Beedle Jon Kern Arie van Bennekum Brian Marick Alistair Cockburn Robert C. Martin Ward Cunningham Steve Mellor Martin Fowler Ken Schwaber James Grenning Jeff Sutherland Jim Highsmith Dave Thomas Andrew Hunt 14
Adopting Agile 15
Adopting Agile Success Factors • Business problem to solve − Goal to achieve; visible • Freedom to change − No micromanaging; right people in, wrong people moved • Engergized team − Familiar with; team spirit; about product/goal • Customer communication − Dedicated; gets ‟it‟; respected in organization • Collaboration − must work together; fight the ”PC glare” • Quality focused − up front; clean; embodied in the product; automate • Incrementalism − JIT features; small chunks; task-by-task 16
Adopting Agile Adoption Patterns • Start Small − Pilot team; >$ for mistakes, success optimized, experts − False hope, takes longer, sign of non-commitment, two types • All In − All teams; management commitment, quicker, one type − Risk, cost, reorg (?), stress • Technical Practices First − Concentrate on how to develop; quicker transition − More difficult, costly, less user-centric thinking • Iterative First − Concentrate on the repetitive cycles; less resistence, easier − May not adopt necessary engineering processes 17
Adopting Agile Adoption Patterns (cont.) • Stealth Mode − Kept to the Agile team; focus on success, less distractions − No org support, skeptics • Times Square Approach − Communicated; success incentive, support, out skeptics − Announce then fail, skeptic disruption, ‟vendor wolves‟ Organizational Effects • Developers; micromanage/freedom/talent | no forethought • Management; new features, progress, impact, project end • HR; receive complaints, corrective action, • Marketing; feature announcement, release date, left out 18
Adopting Agile Top-Down Bottom-Up Organization sponsored Department/Project sponsored Visibility Fewer Monday Morning QB‟s Executive strength Focused pressure Central change team Freedom to define change Execution consistency Time to learn, refine process More measurable Still measurable Business problem solution Appropriate business problem • Communication • Best practice / learn from Agile Coach • Tools to assist • Raise the bar • Plan for management and governance 19
Impediments Organization Team • Management control • Agile knowledge • Department resistance • Work in silos • Trust in team/process • Individual resistance • Investment required • Proper tools • Unrealistic expectations • Documentation requirements • Customer commitments • Management support 20
Agile Types Agile Survey 2006 21
Agile Types Agile Survey 2009 22
Agile Types Am I Agile? Adaptive, empowered, self-organizing Absence of phases Individuals and Interactions Use of minimal planning Scalable Continuous process refinement Iterative and incremental Working Working software measured in progress software Artifacts are minimized Customer Customer involvement throughout Collaboration Adaptive, empirical customer relationship Responding to Emergent requirements Change Frequent inspection 23
Agile Types FDD (Feature-Driven Development) • Characteristics − UML modeling focused, iterative, testing absent, small teams • Processes − Develop an overall model − Build a Features List Done Sequentially − Plan by Feature − Design by Feature Done Iteratively − Build by Feature • Best Practices − Domain Object Modeling, Feature Teams, Visible Progress, Developing By Feature, Inspections, Individual Class Ownership, Regular Builds, Configuration Management − Requires all 8 to be FDD 24
Agile Types FDD (Feature-Driven Development) • Features − Primary unit of coding − Similar to XP User Stories or Scrum Product Backlog − Completed within two weeks • Feature Set − Collection of features − Assigned to a Chief Programmer and team • Major Feature Set − A domain area, one or more feature sets 25
Agile Types Am I Agile? Adaptive, empowered, self-organizing Not so much Absence of phases No Individuals and Interactions Use of minimal planning No Scalable Yes Continuous process refinement Not so much Iterative and incremental Somewhat Working Working software measured in progress No software Artifacts are minimized Somewhat Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements No Change Frequent inspection Yes 26
Agile Types Agile Modeling • Characteristics − Collection of values, principles, and practices − Meant to be tailored into other methodologies • Values − Communication, Simplicity, Feedback, Courage, Humility • Principles − Assuming simplicity (modeling), embracing change (working), incremental change (agility), rapid feedback (reflects needs), model with a purpose (know) − multiple models (for intellect), travel light (discard), content (many ways), communication (open/honest), quality (focus) 27
Agile Types Agile Modeling Best Practices 28
Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases Yes Individuals and Interactions Use of minimal planning Yes Scalable Yes Continuous process refinement Somewhat Iterative and incremental Somewhat Working Working software measured in progress Yes software Artifacts are minimized Yes Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements Yes Change Frequent inspection Yes 29
Agile Types XP (Extreme Programming) • Characteristics − Collection of values and practices − 1 – 4 week iterations, all dials set to “10” − Stories (functionality), on-site customers − UNIT TESTING, simplest thing − YAGNI (You Aren‟t Gonna Need It) • Values − Simplicity: what is needed and asked for, no more − Communication: face to face, daily; work together on everything − Feedback: every iteration seriously delivering working software; listen change as needed; adapt process to project − Respect: everyone contributes; developers respect customers vice versa; management respects authority over work − Courage: truth about project/estimates; no fear no one works alone; adapt to changes 30
Agile Types XP (Extreme Programming) Workflow 31
Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases Yes Individuals and Interactions Use of minimal planning Yes Scalable Yes Continuous process refinement Mostly Iterative and incremental Yes Working Working software measured in progress Yes software Artifacts are minimized Yes Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements Yes Change Frequent inspection Yes 32
Agile Types Scrum • Characteristics − Framework or Method NOT a Process or Technique − Self organizing teams − Progress in month-long or less “Sprints” (iterations) − Requirements are “Product Backlog” − Engineering “Free for Team” − Rules to maintain / be Agile on project • Scrum Team − 7 to 11 members optimal (PO, SM, Team) − Full-time i.e. devoted to Scrum Team; exc. Sys Admin − Change only between Sprints • Etc. − Sprint/Stabilization Sprint: Design, code, test − NO CHANGES during Sprints…take your scope creep and… − Few artifacts, Burndown charts 33
Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases Yes Individuals and Interactions Use of minimal planning Yes Scalable Yes Continuous process refinement Yes Iterative and incremental Yes Working Working software measured in progress Yes software Artifacts are minimized Yes Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements Yes Change Frequent inspection Yes 34
Scrum Overview • Scrum History – Presented 1995, Jeff Sutherland/Ken Schwaber – Not a process or technique, framework (within you can employ processes/techniques • Scrum Theory – Empirical process control: continuous cycle of inspection for correct operation, adapt as needed – Three pillars for implementation • Transparency: affect the outcome is visible to those managing; what is being seen must be known • Inspection: to detect unacceptable variances; skill/diligence • Adaption: adjustment of unacceptable variances; quickly; Daily Scrum, Sprint Review & Planning meetings; Sprint Retrospective 35
Scrum Overview • Scrum Content – Scrum Team • ScrumMaster, Product Owner, the Team – Time-Boxes • Release Planning Meeting, Sprint Planning Meeting, Sprint, Daily Scrum, Sprint Review, Sprint Retrospective – Artifacts • Product Backlog, Sprint Backlog, Release Burndown, Sprint Burndown – Rules • Connect/unite each: Scrum time-boxes, roles, and artifacts • Rule: Daily Scrums last only 15 minutes • Rule: Only the Team talks during Daily Scrums 36
Scrum Overview • Scrum Team – Product Owner • One person only • Manages Product Backlog, ensures value of work • Tip: product manager or business function manager – ScrumMaster • Coaches Scrum Team / organization, removes impediments • Upholds Scrum values, practices, rules • Tip: works to identify and instantiate Product Owner – Team • Developers • Tip: 7 optimal, + or – 2 is okay 37
Scrum Overview • Scrum Time-Boxes – Release Planning Meeting • Establishes: plan and goals, high priority Product Backlog, major risks, features/functionality • Sets probable delivery date and budget – Sprint • A time-boxed iteration, max is 1 month • Consist of Sprint Planning Meeting, development work, Sprint Review, Sprint Retrospective • One after other, no time in between Sprints – Sprint Planning Meeting • Iteration is planned, 8 hours for 1 month Sprint • What/How: top priority Product Backlog/Team decides work • Sprint Goal: objective through Product Backlog implementation 38
Scrum Overview • Scrum Time-Boxes (cont) – Sprint Review • 4 hours per 1 month Sprint, Scrum Team/stakeholders • What was done, what remains; what went well, problems, resolution; demo of work, Q&A • Input for next Sprint Planning Meeting – Sprint Retrospective • 3 hours per 1 month Sprint, Scrum Team • Inspect Sprint (people, relationships, process, tools) • Actionable improvements to implement in next Sprint – Daily Scrum • 15 minutes, inspect/adapt, same place and time • What: Accomplished, Going to do, Obstacles • Improve communication/knowledge, remove impediments 39
Scrum Overview • Scrum Artifacts – Product Backlog & Release Burndown • Requirements for product, evolves and changes • List of all features, functions, technologies, enhancements, bug fixes • Product Owner: contents, availability, prioritization • Graph for sum of Product Backlog effort in time – Sprint Backlog & Sprint Burndown • Product Backlog tasks Team turns into “done” increment • Tasks decomposed/developed during Sprint Planning Meeting • One day or less per task (Sprint Backlog item) • Sprint Backlog only change by the Team • Burndown is a graph of daily estimates of remain sprint work 40
Scrum Overview Sprint Burndown Chart 41
Scrum Overview Scrum Sprint 42
Planning/Estimating General George S. Patton - "A good plan, violently executed now, is better than a perfect plan next week.” The Planning Onion 43
Planning/Estimating Pre-planning points • Organizations culture • IT infrastructure investment • Sponsor / Management commitment • Project selection • Agile team selection • Training needed • Expert access • Project only assignment • Mandatory documentation 44
Planning/Estimating Release Planning • All stakeholders • Release goal • Risks • Conditions of Satisfaction (Features / Functionality, Delivery, Budget) • Priority of Feature Set (confirm project idea first) • Estimating the Product Backlog or Feature Set • Change Management strategy • Define ‟Done‟ 45
Planning/Estimating Iteration Planning • Daily Stand-up (Time/Place) • Technical process • Tools discussion (code migration, QA, project management, Backlog) • Iteration timebox • Capacity of team • Backlog priority (client: ”more of this, less of that”) • Tasks to complete Product Backlog item • Size of Product Backlog item • Velocity (previous iterations/sprints) 46
Planning/Estimating Daily Planning • Inspect and Adapt meeting • Accomplishments • Going to accomplish • Impediments in the way • Coordinate individual activities • Wrap-up 47
Planning/Estimating Estimating • Product Backlog, Iteration Backlog, Tasks • Size not Time • Estimation types − Story points: Size and complexity, numerically relevant (10 = 5*2), relative estimating, focus on size vs. duration, units added together − Planning poker: Iterative approach 1) Estimators get deck of cards with valid estimates 2) Product owner reads story, briefly discussed 3) Estimators selects card as estimate 4) All estimators turn cards over 5) Discuss differences (outliers) 6) Re-estimate until they come together Good results: do the work estimate the work, justify estimates, group discussion, relative vs. absolute, involves all − Fibonacci number: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ... 48
Build Delivery Coding Practices • Pair Programming – Typing, Reading, Both Thinking; discuss often, instant review, helps inexperienced developers, accountability, collaboration • No Code Ownership – Anyone can review and fix code; inexperienced limitations • Code/Test – Automate tests; „smoke tests‟, integration testing; raise visibility • Test First Design – Writing code against test for requirements; think through design • Refactoring – Improve readability and maintainability; reduce complexity 49
Build Delivery Integrate Often • Automate the Build – Repeatable, build anytime • Build is Self-Testing – Build includes automated testing, covers large part of code base • Daily Commits – Quicker failure, bugs/defects founds sooner • Commits create Builds – Integration is tested daily • Keep Builds Fast – Developers have status quickly; queue of builds, email status 50
Tools • Consulting firm – Agile transformation – All parts of organization • Agile Coaches – Understanding of Agile processes; ease transition for team – Directory at: Agile Alliance and Scrum Alliance • Project Management – Built for Agile (hosted/on-premise; high cost/low cost) – Agile templates, dashboards • Build/Test – Integration, comparison; code evaluation, modeling, bug isolation • Vendors/Products – Rally Software, CollabNet, IBM, Microsoft, JUnit/XUnit, ScrumWorks, Electric Cloud, OpenMake Software 51
Tools 52
Agile Success Impact • Organization − For holistic success devote attention downstream − Manifesto implies organization (customer, business people, feedback) − Greater role in decision making, product outcome − Better collaboration with other departments • Organization Tips − Pick one problem to solve − Don‟t forget governance and regulatory requirements − Incentives and Rewards − Customer interaction with departments 53
Agile Success Impact • Agile Team − Development ownership in process (estimate, quality, delivery) − New techniques for meeting deliverables − Retrospectives/Feedback to immediate improvement − Defects caught early − PM‟s/ScrumMaster becomes the snowplow − PM‟s/ScrumMaster provide vs. need, coach vs. enforcer • Agile Team Tips − Adopt the right mix (maybe more than one) − Initial focus on team principles and build practices − Team consistency/accountable to one another − Empowerment is not a noun, it is a verb − Do not under estimate the challenge of transforming − Utilize tools to fullest extent 54
Agile Success Full Potential • Needs − Assessment plan − Support plan (training, coaches, management) − Balance business needs with technical − Realize change effects all moving parts − Smaller teams, self managed, reduced silos − New skills, automate the routine • Results − More transparent organization − Realistic product horizons − Better moral − Reduced time to market − Quality improvement − Less surprises − Higher customer satisfaction 55
Buzzwords • Done – Shippable increment of product containing all Product Backlog for the increment – Must be additive to all prior increments – Defined by Team, Product Owner informed • Continuous Integration – Integrating of code by team members at a frequent pace (daily) – Can produce numerous builds daily (10 team members = 10 builds) • Kanban – A Lean Manufacturing “Pull” process developed by Toyota – Software development used the same process with a physical task board (To Do, In Progress, Done, etc.) 56
Resources • People − Kent Beck, Jeff Sutherland, Tobias Mayer, Mike Beedle, Ken Schwaber, Peter Hundermark, Jim Highsmith • Books − Succeeding with Agile, Agile Estimating Planning, Scrum and XP from the Trenches, Continuous Delivery, Agile Software Development with Scrum, Agile Coaching • Organizations − Agile Alliance, Scrum Alliance, Scrum.org, PMI • Websites − (See Organizations), Google, Amazon, Forrester, AgileJournal, MountainGoatSoftware, AgileManifesto.org, ExtremeProgramming.org, LinkedIn(groups), tech related 57
Sources • Certified ScrumMaster Training, Conscires Agile Practices • http://agilemanifesto.org/ • Scrum, Jeff Sutherland/Ken Schwaber, http://www.scrum.org, Feb. 2010 • Do Better Scrum, Peter Hundermark, ScrumSense, Nov. 2009 • The Truth About Agile Process, Carey Schwaber, Forrester, Aug. 2007 • The Forrester Wave: Agile Development Management Tools Q2 2010, Dave West/Jeffrey Hammond, Forrester, May 2010 • From Agile Development To Agile Engagement, Tom Grant, Forrester, May 2009 • Agile Development: Mainstream Adoption Has Changed Agility, Dave West/Tom Grant, Forrester, Jan. 2010 58
Sources • Agile Estimating and Planning, Mike Cohn, Prentice Hall, Nov. 2005 • Planning and Tracking Agile Projects, Mike Cohn, Mountain Goat Software, March 2007 • Agile Project Management: Estimating the Unknown, Rick Freedman, TechRepublic, June 2009 • Agile Success Factors, Jeff Langr/Tim Ottinger, agileinaflash.blogspot.com, July 2010 • New Patterns of Agile Adoption, Mike Cohn, Agile Journal, Jan. 2008 • Introduction an Agile Process to an Organization, Mike Cohn/Doris Ford, IEEE, June 2003 • Scaling Up: An Approach to Organizational Agile Adoption, Ross Pettit, Agile Journal, Nov. 2006 59
Sources • Key Success Factors in Top-Down Agile Adoption, Ross Pettit, Agile Journal, March 2007 • The Agile Heartbeat, John Graham-Cumming, Electric Cloud, 2009 • Best Practices for Implementing Agile Methods: A Guide for Department of Defense Software Developers, Ann Fruhling/Alvin Tarrell, University of Nebraska at Omaha, 2008 • Selecting an Agile Process: Choosing Among the Leading Alternatives, Mike Cohn, Mountain Goat Software, Sept. 2004 • An Introduction to Agile Modeling, Scott Ambler, Ambysoft, 2006 • Feature-Driven Development, Peter Coad/Eric Lefebvre/Jeff De Luca, Java Modeling in Color with UML, Prentice Hall, June 1999 • http://www.microtool.de/instep/en/prod_scrum_edition.asp 60
THANK YOU!

More Related Content

PPTX
Standardization and strategy in agile
byNaveen Gupta
 
PPTX
Introduction to Recipes for Agile Governance in the Enterprise (RAGE)
byCprime
 
PDF
Journey toagile published
byProductCamp Minnesota
 
PPTX
Agile Governance Workshop @Agile India 2012
byAsheesh Mehdiratta
 
PPTX
Agile Webinar: Managing Distributed Teams
bycPrime | Project Management | Agile | Consulting | Staffing | Training
 
PPTX
Business Case for Agile - Time for ROI Check
byDr. Tathagat Varma
 
PDF
Overview of Agile for Business Analysts
bySally Elatta
 
PPTX
Continuous Deployment - Case Study at WIX
byAgileSparks
 
Standardization and strategy in agile
byNaveen Gupta
 
Introduction to Recipes for Agile Governance in the Enterprise (RAGE)
byCprime
 
Journey toagile published
byProductCamp Minnesota
 
Agile Governance Workshop @Agile India 2012
byAsheesh Mehdiratta
 
Agile Webinar: Managing Distributed Teams
bycPrime | Project Management | Agile | Consulting | Staffing | Training
 
Business Case for Agile - Time for ROI Check
byDr. Tathagat Varma
 
Overview of Agile for Business Analysts
bySally Elatta
 
Continuous Deployment - Case Study at WIX
byAgileSparks
 

What's hot

PDF
Selecting consultants - the process
byJohn Cachat
 
PDF
Introduction to Agile Values & Principles
byAndreea Visanoiu
 
PPT
Executive Presentation on Agile Project Management by Boardroom Metrics Inc.
byBoardroom Metrics
 
PPTX
Is Agile Project Management Right for your Nonprofit
byNorman Reiss
 
PPTX
Becoming Agile - Challenge the Traditional Thinking
byAgileSparks
 
PDF
Agile Methods Overview ]
byPrasad Prabhakaran
 
PDF
Agile Project Management at The Washington Post
byDave Burke
 
PPTX
Agile thinking
byEdwin Dando
 
PPT
Project Management For Nonprofits
byNorman Reiss
 
PPTX
Agile governance The New Disinfectant
byRenee Troughton
 
PPTX
Holistic Product Development
byGary Pedretti
 
PPTX
Scaling Agile - Multiple Team Dynamics
byVersionOne
 
PPT
Agile software development for startups
byHemant Elhence
 
PPTX
Agile
byJeff Bollinger
 
PDF
SharePoint and Lean Development: Critical Factors for Accelerating Time to Va...
byDave Healey
 
PPTX
Agile Auckland agile 101 back to basics
byEdwin Dando
 
PDF
Lean Startup: It's Not Just Technology, Lives are at Stake
byKen Power
 
PDF
Identifying and Managing Waste in Complex Product Development Environments
byKen Power
 
PDF
Agile presentation ONA12
byvpowers
 
PDF
Research on Impediments to Product Development Flow
byKen Power
 
Selecting consultants - the process
byJohn Cachat
 
Introduction to Agile Values & Principles
byAndreea Visanoiu
 
Executive Presentation on Agile Project Management by Boardroom Metrics Inc.
byBoardroom Metrics
 
Is Agile Project Management Right for your Nonprofit
byNorman Reiss
 
Becoming Agile - Challenge the Traditional Thinking
byAgileSparks
 
Agile Methods Overview ]
byPrasad Prabhakaran
 
Agile Project Management at The Washington Post
byDave Burke
 
Agile thinking
byEdwin Dando
 
Project Management For Nonprofits
byNorman Reiss
 
Agile governance The New Disinfectant
byRenee Troughton
 
Holistic Product Development
byGary Pedretti
 
Scaling Agile - Multiple Team Dynamics
byVersionOne
 
Agile software development for startups
byHemant Elhence
 
Agile
byJeff Bollinger
 
SharePoint and Lean Development: Critical Factors for Accelerating Time to Va...
byDave Healey
 
Agile Auckland agile 101 back to basics
byEdwin Dando
 
Lean Startup: It's Not Just Technology, Lives are at Stake
byKen Power
 
Identifying and Managing Waste in Complex Product Development Environments
byKen Power
 
Agile presentation ONA12
byvpowers
 
Research on Impediments to Product Development Flow
byKen Power
 

Similar to Agile Development Product Delivery For Successful Organizations

PDF
Agile values
byDUONG Trong Tan
 
PDF
Are you Agile enough?
byOrange and Bronze Software Labs
 
PDF
Agile Fundamentals for Project Managers.pdf
byBorja ARRIZABALAGA URIARTE
 
PDF
Surfing the Agile Wave
byAgileOnTheBeach
 
PDF
The BA role in Agile Development
byAgileee
 
PDF
Introduction to agility
byAlexandre Cuva
 
PDF
Agile Project Management Part 1 Final
byMia Horrigan
 
PPT
Agile adoption julen c. mohanty
byJulen Mohanty
 
PPT
Agile Development Overview
byguestb4c770
 
PDF
Intro Of Agile
bySam Hwang
 
PDF
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
byIIBA UK Chapter
 
PPTX
Agile - Brief Concepts.pptx
byZaheerTariq5
 
PPTX
Agile marries itil
byMats Janemalm
 
PPTX
Introduction to Agile
byRichard Cheng
 
PPTX
Agile is as Agile Does
byClint Edmonson
 
PPT
Agile Development Overview
byMark Kovacevich
 
PPT
Intro to Agile Practices and Values
byOpenSource Connections
 
PPTX
An Introduction to Agile - Prashant Pund, AgileSoft.
byPune OpenCoffee Club
 
PDF
Basics of agile
bySwapnilPrabhavalkar
 
PPTX
Agile Estimation And Planning Part I
byKevin Zamora
 
Agile values
byDUONG Trong Tan
 
Are you Agile enough?
byOrange and Bronze Software Labs
 
Agile Fundamentals for Project Managers.pdf
byBorja ARRIZABALAGA URIARTE
 
Surfing the Agile Wave
byAgileOnTheBeach
 
The BA role in Agile Development
byAgileee
 
Introduction to agility
byAlexandre Cuva
 
Agile Project Management Part 1 Final
byMia Horrigan
 
Agile adoption julen c. mohanty
byJulen Mohanty
 
Agile Development Overview
byguestb4c770
 
Intro Of Agile
bySam Hwang
 
Common challenges in adopting Agile: IIBA Northampton event 23rd August 2011
byIIBA UK Chapter
 
Agile - Brief Concepts.pptx
byZaheerTariq5
 
Agile marries itil
byMats Janemalm
 
Introduction to Agile
byRichard Cheng
 
Agile is as Agile Does
byClint Edmonson
 
Agile Development Overview
byMark Kovacevich
 
Intro to Agile Practices and Values
byOpenSource Connections
 
An Introduction to Agile - Prashant Pund, AgileSoft.
byPune OpenCoffee Club
 
Basics of agile
bySwapnilPrabhavalkar
 
Agile Estimation And Planning Part I
byKevin Zamora
 

Agile Development Product Delivery For Successful Organizations

  • 1.
    Agile Development: Product Delivery for Successful Organizations Marc Crudgington © Copyright Pacific Technology Consulting Group, LLC
  • 2.
    Interactive Agenda: Pick aTopic Framework vs. Process Agile Types Scrum Estimating/Planning Buzzwords Resources Agile Iterative or Principles Predictive Adopting Agile Build Delivery Impediments Agile Success Evolution Tools 2
  • 3.
  • 4.
    Bio / Info • Career – US Air Force, 3Com, ONI/Ciena, Mortgage/Countrywide, KPMG, Jefferson Wells, Autobytel, ASM • Entrepreneurship – Adventure Travel, Consulting, Mortgage, Consulting • Education – MBA, BBA, ACS, AEE • Certifications – PMP, CSM, TOGAF, ITIL, ISS, CISM, CISA • Personal – Married to Maricris 01/2004, Two boys: Jake 5 / Luke 2 4
  • 5.
    Framework vs. Process Framework Process • Set of principles with no parent- • Prescriptive and linear series of child relationship which within steps taken to repeatedly activities are performed. generate the same output. • Not all components required to • All components used be used • It is a sequence / same order • Not always used in the same • Structured order • PMBOK (Project Management • Less structured Body of Knowledge), Waterfall • Agile 5
  • 6.
    Iterative or Predictive Predictive • Characteristics – Plan driven, heavy load upfront, structured – Sequential, bureaucratic, change resistant – Design: intensive, 10%; Construction manual, 90% – End result pre-determined • Steps – Idea, Requirement, Design, Construct, Integrate, Test, Implement, Maintain 6
  • 7.
    Iterative or Predictive Predictive • Use when – Project familiar – Inexperienced developers – Project team is large and project is complex – Thoroughly documented, demands order – Predictability versus change, requirements stable • IMO – Civil engineering, Construction – Maybe government, government contractors, pharma? 7
  • 8.
    Iterative or Predictive Iterative • Characteristics – Ambiguity okay, code oriented, adaptable – Welcome change, feedback, people vs. process – Design: creative, 80%; Construction automate, 20% – End result evolving • Steps – Brainstorm/plan, Development, Deliver, Feedback 8
  • 9.
    Iterative or Predictive Iterative • Use when – Project evolves or a little unknown – Accept change – Team small; strategies for large/split – Rapid change can occur • IMO – Information Technology 9
  • 10.
    Iterative or Predictive Comparison Agile Waterfall Informal/Incremental Documented/Steps Teamwork/Collaboration Individual Continuous Integration End or Milestones Light process Heavy process Open door Limited Cross trained Segmented Active developers Developers sit and wait No surprises at end Validate requirements QA helps produce QA certifies Empowerment Controlling Best app for customer Satisfy requirements, contracts 10
  • 11.
    Agile Principles Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 11
  • 12.
    Agile Principles Principles behind the Agile Manifesto We follow these principles: 1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and developers must work together daily throughout the project. 5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. 6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. 12
  • 13.
    Agile Principles Principles behind the Agile Manifesto (cont.) 7. Working software is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 9. Continuous attention to technical excellence and good design enhances agility. 10. Simplicity--the art of maximizing the amount of work not done--is essential. 11. The best architectures, requirements, and designs emerge from self-organizing teams. 12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 13
  • 14.
    Agile Principles Authors of the Agile Manifesto Kent Beck Ron Jeffries Mike Beedle Jon Kern Arie van Bennekum Brian Marick Alistair Cockburn Robert C. Martin Ward Cunningham Steve Mellor Martin Fowler Ken Schwaber James Grenning Jeff Sutherland Jim Highsmith Dave Thomas Andrew Hunt 14
  • 15.
  • 16.
    Adopting Agile Success Factors • Business problem to solve − Goal to achieve; visible • Freedom to change − No micromanaging; right people in, wrong people moved • Engergized team − Familiar with; team spirit; about product/goal • Customer communication − Dedicated; gets ‟it‟; respected in organization • Collaboration − must work together; fight the ”PC glare” • Quality focused − up front; clean; embodied in the product; automate • Incrementalism − JIT features; small chunks; task-by-task 16
  • 17.
    Adopting Agile Adoption Patterns • Start Small − Pilot team; >$ for mistakes, success optimized, experts − False hope, takes longer, sign of non-commitment, two types • All In − All teams; management commitment, quicker, one type − Risk, cost, reorg (?), stress • Technical Practices First − Concentrate on how to develop; quicker transition − More difficult, costly, less user-centric thinking • Iterative First − Concentrate on the repetitive cycles; less resistence, easier − May not adopt necessary engineering processes 17
  • 18.
    Adopting Agile Adoption Patterns(cont.) • Stealth Mode − Kept to the Agile team; focus on success, less distractions − No org support, skeptics • Times Square Approach − Communicated; success incentive, support, out skeptics − Announce then fail, skeptic disruption, ‟vendor wolves‟ Organizational Effects • Developers; micromanage/freedom/talent | no forethought • Management; new features, progress, impact, project end • HR; receive complaints, corrective action, • Marketing; feature announcement, release date, left out 18
  • 19.
    Adopting Agile Top-Down Bottom-Up Organization sponsored Department/Project sponsored Visibility Fewer Monday Morning QB‟s Executive strength Focused pressure Central change team Freedom to define change Execution consistency Time to learn, refine process More measurable Still measurable Business problem solution Appropriate business problem • Communication • Best practice / learn from Agile Coach • Tools to assist • Raise the bar • Plan for management and governance 19
  • 20.
    Impediments Organization Team • Management control • Agile knowledge • Department resistance • Work in silos • Trust in team/process • Individual resistance • Investment required • Proper tools • Unrealistic expectations • Documentation requirements • Customer commitments • Management support 20
  • 21.
  • 22.
  • 23.
    Agile Types Am I Agile? Adaptive, empowered, self-organizing Absence of phases Individuals and Interactions Use of minimal planning Scalable Continuous process refinement Iterative and incremental Working Working software measured in progress software Artifacts are minimized Customer Customer involvement throughout Collaboration Adaptive, empirical customer relationship Responding to Emergent requirements Change Frequent inspection 23
  • 24.
    Agile Types FDD (Feature-Driven Development) • Characteristics − UML modeling focused, iterative, testing absent, small teams • Processes − Develop an overall model − Build a Features List Done Sequentially − Plan by Feature − Design by Feature Done Iteratively − Build by Feature • Best Practices − Domain Object Modeling, Feature Teams, Visible Progress, Developing By Feature, Inspections, Individual Class Ownership, Regular Builds, Configuration Management − Requires all 8 to be FDD 24
  • 25.
    Agile Types FDD (Feature-Driven Development) • Features − Primary unit of coding − Similar to XP User Stories or Scrum Product Backlog − Completed within two weeks • Feature Set − Collection of features − Assigned to a Chief Programmer and team • Major Feature Set − A domain area, one or more feature sets 25
  • 26.
    Agile Types Am I Agile? Adaptive, empowered, self-organizing Not so much Absence of phases No Individuals and Interactions Use of minimal planning No Scalable Yes Continuous process refinement Not so much Iterative and incremental Somewhat Working Working software measured in progress No software Artifacts are minimized Somewhat Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements No Change Frequent inspection Yes 26
  • 27.
    Agile Types Agile Modeling • Characteristics − Collection of values, principles, and practices − Meant to be tailored into other methodologies • Values − Communication, Simplicity, Feedback, Courage, Humility • Principles − Assuming simplicity (modeling), embracing change (working), incremental change (agility), rapid feedback (reflects needs), model with a purpose (know) − multiple models (for intellect), travel light (discard), content (many ways), communication (open/honest), quality (focus) 27
  • 28.
  • 29.
    Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases Yes Individuals and Interactions Use of minimal planning Yes Scalable Yes Continuous process refinement Somewhat Iterative and incremental Somewhat Working Working software measured in progress Yes software Artifacts are minimized Yes Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements Yes Change Frequent inspection Yes 29
  • 30.
    Agile Types XP (Extreme Programming) • Characteristics − Collection of values and practices − 1 – 4 week iterations, all dials set to “10” − Stories (functionality), on-site customers − UNIT TESTING, simplest thing − YAGNI (You Aren‟t Gonna Need It) • Values − Simplicity: what is needed and asked for, no more − Communication: face to face, daily; work together on everything − Feedback: every iteration seriously delivering working software; listen change as needed; adapt process to project − Respect: everyone contributes; developers respect customers vice versa; management respects authority over work − Courage: truth about project/estimates; no fear no one works alone; adapt to changes 30
  • 31.
    Agile Types XP (ExtremeProgramming) Workflow 31
  • 32.
    Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases Yes Individuals and Interactions Use of minimal planning Yes Scalable Yes Continuous process refinement Mostly Iterative and incremental Yes Working Working software measured in progress Yes software Artifacts are minimized Yes Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements Yes Change Frequent inspection Yes 32
  • 33.
    Agile Types Scrum • Characteristics − Framework or Method NOT a Process or Technique − Self organizing teams − Progress in month-long or less “Sprints” (iterations) − Requirements are “Product Backlog” − Engineering “Free for Team” − Rules to maintain / be Agile on project • Scrum Team − 7 to 11 members optimal (PO, SM, Team) − Full-time i.e. devoted to Scrum Team; exc. Sys Admin − Change only between Sprints • Etc. − Sprint/Stabilization Sprint: Design, code, test − NO CHANGES during Sprints…take your scope creep and… − Few artifacts, Burndown charts 33
  • 34.
    Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases Yes Individuals and Interactions Use of minimal planning Yes Scalable Yes Continuous process refinement Yes Iterative and incremental Yes Working Working software measured in progress Yes software Artifacts are minimized Yes Customer Customer involvement throughout Yes Collaboration Adaptive, empirical customer relationship Yes Responding to Emergent requirements Yes Change Frequent inspection Yes 34
  • 35.
    Scrum Overview • ScrumHistory – Presented 1995, Jeff Sutherland/Ken Schwaber – Not a process or technique, framework (within you can employ processes/techniques • Scrum Theory – Empirical process control: continuous cycle of inspection for correct operation, adapt as needed – Three pillars for implementation • Transparency: affect the outcome is visible to those managing; what is being seen must be known • Inspection: to detect unacceptable variances; skill/diligence • Adaption: adjustment of unacceptable variances; quickly; Daily Scrum, Sprint Review & Planning meetings; Sprint Retrospective 35
  • 36.
    Scrum Overview • ScrumContent – Scrum Team • ScrumMaster, Product Owner, the Team – Time-Boxes • Release Planning Meeting, Sprint Planning Meeting, Sprint, Daily Scrum, Sprint Review, Sprint Retrospective – Artifacts • Product Backlog, Sprint Backlog, Release Burndown, Sprint Burndown – Rules • Connect/unite each: Scrum time-boxes, roles, and artifacts • Rule: Daily Scrums last only 15 minutes • Rule: Only the Team talks during Daily Scrums 36
  • 37.
    Scrum Overview • ScrumTeam – Product Owner • One person only • Manages Product Backlog, ensures value of work • Tip: product manager or business function manager – ScrumMaster • Coaches Scrum Team / organization, removes impediments • Upholds Scrum values, practices, rules • Tip: works to identify and instantiate Product Owner – Team • Developers • Tip: 7 optimal, + or – 2 is okay 37
  • 38.
    Scrum Overview • ScrumTime-Boxes – Release Planning Meeting • Establishes: plan and goals, high priority Product Backlog, major risks, features/functionality • Sets probable delivery date and budget – Sprint • A time-boxed iteration, max is 1 month • Consist of Sprint Planning Meeting, development work, Sprint Review, Sprint Retrospective • One after other, no time in between Sprints – Sprint Planning Meeting • Iteration is planned, 8 hours for 1 month Sprint • What/How: top priority Product Backlog/Team decides work • Sprint Goal: objective through Product Backlog implementation 38
  • 39.
    Scrum Overview • ScrumTime-Boxes (cont) – Sprint Review • 4 hours per 1 month Sprint, Scrum Team/stakeholders • What was done, what remains; what went well, problems, resolution; demo of work, Q&A • Input for next Sprint Planning Meeting – Sprint Retrospective • 3 hours per 1 month Sprint, Scrum Team • Inspect Sprint (people, relationships, process, tools) • Actionable improvements to implement in next Sprint – Daily Scrum • 15 minutes, inspect/adapt, same place and time • What: Accomplished, Going to do, Obstacles • Improve communication/knowledge, remove impediments 39
  • 40.
    Scrum Overview • ScrumArtifacts – Product Backlog & Release Burndown • Requirements for product, evolves and changes • List of all features, functions, technologies, enhancements, bug fixes • Product Owner: contents, availability, prioritization • Graph for sum of Product Backlog effort in time – Sprint Backlog & Sprint Burndown • Product Backlog tasks Team turns into “done” increment • Tasks decomposed/developed during Sprint Planning Meeting • One day or less per task (Sprint Backlog item) • Sprint Backlog only change by the Team • Burndown is a graph of daily estimates of remain sprint work 40
  • 41.
  • 42.
  • 43.
    Planning/Estimating General George S.Patton - "A good plan, violently executed now, is better than a perfect plan next week.” The Planning Onion 43
  • 44.
    Planning/Estimating Pre-planning points •Organizations culture • IT infrastructure investment • Sponsor / Management commitment • Project selection • Agile team selection • Training needed • Expert access • Project only assignment • Mandatory documentation 44
  • 45.
    Planning/Estimating Release Planning •All stakeholders • Release goal • Risks • Conditions of Satisfaction (Features / Functionality, Delivery, Budget) • Priority of Feature Set (confirm project idea first) • Estimating the Product Backlog or Feature Set • Change Management strategy • Define ‟Done‟ 45
  • 46.
    Planning/Estimating Iteration Planning •Daily Stand-up (Time/Place) • Technical process • Tools discussion (code migration, QA, project management, Backlog) • Iteration timebox • Capacity of team • Backlog priority (client: ”more of this, less of that”) • Tasks to complete Product Backlog item • Size of Product Backlog item • Velocity (previous iterations/sprints) 46
  • 47.
    Planning/Estimating Daily Planning •Inspect and Adapt meeting • Accomplishments • Going to accomplish • Impediments in the way • Coordinate individual activities • Wrap-up 47
  • 48.
    Planning/Estimating Estimating • ProductBacklog, Iteration Backlog, Tasks • Size not Time • Estimation types − Story points: Size and complexity, numerically relevant (10 = 5*2), relative estimating, focus on size vs. duration, units added together − Planning poker: Iterative approach 1) Estimators get deck of cards with valid estimates 2) Product owner reads story, briefly discussed 3) Estimators selects card as estimate 4) All estimators turn cards over 5) Discuss differences (outliers) 6) Re-estimate until they come together Good results: do the work estimate the work, justify estimates, group discussion, relative vs. absolute, involves all − Fibonacci number: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, ... 48
  • 49.
    Build Delivery Coding Practices •Pair Programming – Typing, Reading, Both Thinking; discuss often, instant review, helps inexperienced developers, accountability, collaboration • No Code Ownership – Anyone can review and fix code; inexperienced limitations • Code/Test – Automate tests; „smoke tests‟, integration testing; raise visibility • Test First Design – Writing code against test for requirements; think through design • Refactoring – Improve readability and maintainability; reduce complexity 49
  • 50.
    Build Delivery Integrate Often • Automate the Build – Repeatable, build anytime • Build is Self-Testing – Build includes automated testing, covers large part of code base • Daily Commits – Quicker failure, bugs/defects founds sooner • Commits create Builds – Integration is tested daily • Keep Builds Fast – Developers have status quickly; queue of builds, email status 50
  • 51.
    Tools • Consulting firm – Agile transformation – All parts of organization • Agile Coaches – Understanding of Agile processes; ease transition for team – Directory at: Agile Alliance and Scrum Alliance • Project Management – Built for Agile (hosted/on-premise; high cost/low cost) – Agile templates, dashboards • Build/Test – Integration, comparison; code evaluation, modeling, bug isolation • Vendors/Products – Rally Software, CollabNet, IBM, Microsoft, JUnit/XUnit, ScrumWorks, Electric Cloud, OpenMake Software 51
  • 52.
  • 53.
    Agile Success Impact • Organization − For holistic success devote attention downstream − Manifesto implies organization (customer, business people, feedback) − Greater role in decision making, product outcome − Better collaboration with other departments • Organization Tips − Pick one problem to solve − Don‟t forget governance and regulatory requirements − Incentives and Rewards − Customer interaction with departments 53
  • 54.
    Agile Success Impact • Agile Team − Development ownership in process (estimate, quality, delivery) − New techniques for meeting deliverables − Retrospectives/Feedback to immediate improvement − Defects caught early − PM‟s/ScrumMaster becomes the snowplow − PM‟s/ScrumMaster provide vs. need, coach vs. enforcer • Agile Team Tips − Adopt the right mix (maybe more than one) − Initial focus on team principles and build practices − Team consistency/accountable to one another − Empowerment is not a noun, it is a verb − Do not under estimate the challenge of transforming − Utilize tools to fullest extent 54
  • 55.
    Agile Success Full Potential • Needs − Assessment plan − Support plan (training, coaches, management) − Balance business needs with technical − Realize change effects all moving parts − Smaller teams, self managed, reduced silos − New skills, automate the routine • Results − More transparent organization − Realistic product horizons − Better moral − Reduced time to market − Quality improvement − Less surprises − Higher customer satisfaction 55
  • 56.
    Buzzwords • Done – Shippable increment of product containing all Product Backlog for the increment – Must be additive to all prior increments – Defined by Team, Product Owner informed • Continuous Integration – Integrating of code by team members at a frequent pace (daily) – Can produce numerous builds daily (10 team members = 10 builds) • Kanban – A Lean Manufacturing “Pull” process developed by Toyota – Software development used the same process with a physical task board (To Do, In Progress, Done, etc.) 56
  • 57.
    Resources • People − Kent Beck, Jeff Sutherland, Tobias Mayer, Mike Beedle, Ken Schwaber, Peter Hundermark, Jim Highsmith • Books − Succeeding with Agile, Agile Estimating Planning, Scrum and XP from the Trenches, Continuous Delivery, Agile Software Development with Scrum, Agile Coaching • Organizations − Agile Alliance, Scrum Alliance, Scrum.org, PMI • Websites − (See Organizations), Google, Amazon, Forrester, AgileJournal, MountainGoatSoftware, AgileManifesto.org, ExtremeProgramming.org, LinkedIn(groups), tech related 57
  • 58.
    Sources • Certified ScrumMasterTraining, Conscires Agile Practices • http://agilemanifesto.org/ • Scrum, Jeff Sutherland/Ken Schwaber, http://www.scrum.org, Feb. 2010 • Do Better Scrum, Peter Hundermark, ScrumSense, Nov. 2009 • The Truth About Agile Process, Carey Schwaber, Forrester, Aug. 2007 • The Forrester Wave: Agile Development Management Tools Q2 2010, Dave West/Jeffrey Hammond, Forrester, May 2010 • From Agile Development To Agile Engagement, Tom Grant, Forrester, May 2009 • Agile Development: Mainstream Adoption Has Changed Agility, Dave West/Tom Grant, Forrester, Jan. 2010 58
  • 59.
    Sources • Agile Estimatingand Planning, Mike Cohn, Prentice Hall, Nov. 2005 • Planning and Tracking Agile Projects, Mike Cohn, Mountain Goat Software, March 2007 • Agile Project Management: Estimating the Unknown, Rick Freedman, TechRepublic, June 2009 • Agile Success Factors, Jeff Langr/Tim Ottinger, agileinaflash.blogspot.com, July 2010 • New Patterns of Agile Adoption, Mike Cohn, Agile Journal, Jan. 2008 • Introduction an Agile Process to an Organization, Mike Cohn/Doris Ford, IEEE, June 2003 • Scaling Up: An Approach to Organizational Agile Adoption, Ross Pettit, Agile Journal, Nov. 2006 59
  • 60.
    Sources • Key SuccessFactors in Top-Down Agile Adoption, Ross Pettit, Agile Journal, March 2007 • The Agile Heartbeat, John Graham-Cumming, Electric Cloud, 2009 • Best Practices for Implementing Agile Methods: A Guide for Department of Defense Software Developers, Ann Fruhling/Alvin Tarrell, University of Nebraska at Omaha, 2008 • Selecting an Agile Process: Choosing Among the Leading Alternatives, Mike Cohn, Mountain Goat Software, Sept. 2004 • An Introduction to Agile Modeling, Scott Ambler, Ambysoft, 2006 • Feature-Driven Development, Peter Coad/Eric Lefebvre/Jeff De Luca, Java Modeling in Color with UML, Prentice Hall, June 1999 • http://www.microtool.de/instep/en/prod_scrum_edition.asp 60
  • 61.