Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Agile Development Product Delivery For Successful Organizations


Published on

Agile presentation given to IEEE

  • Be the first to comment

Agile Development Product Delivery For Successful Organizations

  1. 1. Agile Development: Product Delivery for Successful Organizations Marc Crudgington© Copyright Pacific Technology Consulting Group, LLC
  2. 2. 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. 3. 3
  4. 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. 5. Framework vs. ProcessFramework Process• Set of principles with no parent- • Prescriptive and linear series ofchild relationship which within steps taken to repeatedlyactivities are performed. generate the same output.• Not all components required to • All components usedbe used • It is a sequence / same order• Not always used in the same • Structuredorder • PMBOK (Project Management• Less structured Body of Knowledge), Waterfall• Agile 5
  6. 6. Iterative or PredictivePredictive • 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. 7. Iterative or PredictivePredictive • 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. 8. Iterative or PredictiveIterative • 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. 9. Iterative or PredictiveIterative • 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. 10. Iterative or PredictiveComparison 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. 11. Agile Principles Manifesto for Agile Software DevelopmentWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left more. 11
  12. 12. Agile Principles Principles behind the Agile ManifestoWe 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 customers 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. 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. 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. 15. Adopting Agile 15
  16. 16. Adopting AgileSuccess 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. 17. Adopting AgileAdoption 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. 18. Adopting AgileAdoption 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. 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. 20. ImpedimentsOrganization 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. 21. Agile TypesAgile Survey 2006 21
  22. 22. Agile TypesAgile Survey 2009 22
  23. 23. Agile Types Am I Agile? Adaptive, empowered, self-organizing Absence of phasesIndividuals 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 throughoutCollaboration Adaptive, empirical customer relationshipResponding to Emergent requirements Change Frequent inspection 23
  24. 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. 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. 26. Agile Types Am I Agile? Adaptive, empowered, self-organizing Not so much Absence of phases NoIndividuals 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 YesCollaboration Adaptive, empirical customer relationship YesResponding to Emergent requirements No Change Frequent inspection Yes 26
  27. 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. 28. Agile TypesAgile ModelingBest Practices 28
  29. 29. Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases YesIndividuals 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 YesCollaboration Adaptive, empirical customer relationship YesResponding to Emergent requirements Yes Change Frequent inspection Yes 29
  30. 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. 31. Agile TypesXP (Extreme Programming) Workflow 31
  32. 32. Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases YesIndividuals 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 YesCollaboration Adaptive, empirical customer relationship YesResponding to Emergent requirements Yes Change Frequent inspection Yes 32
  33. 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. 34. Agile Types Am I Agile? Adaptive, empowered, self-organizing Somewhat Absence of phases YesIndividuals 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 YesCollaboration Adaptive, empirical customer relationship YesResponding to Emergent requirements Yes Change Frequent inspection Yes 34
  35. 35. 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
  36. 36. 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
  37. 37. 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
  38. 38. 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
  39. 39. 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
  40. 40. 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
  41. 41. Scrum OverviewSprint Burndown Chart 41
  42. 42. Scrum Overview Scrum Sprint 42
  43. 43. Planning/EstimatingGeneral George S. Patton - "A good plan, violently executed now, isbetter than a perfect plan next week.” The Planning Onion 43
  44. 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. 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. 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. 47. Planning/Estimating Daily Planning• Inspect and Adapt meeting• Accomplishments• Going to accomplish• Impediments in the way• Coordinate individual activities• Wrap-up 47
  48. 48. 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
  49. 49. Build DeliveryCoding 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. 50. Build DeliveryIntegrate 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. 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. 52. Tools 52
  53. 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. 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. 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. 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. 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,, PMI• Websites − (See Organizations), Google, Amazon, Forrester, AgileJournal, MountainGoatSoftware,,, LinkedIn(groups), tech related 57
  58. 58. Sources• Certified ScrumMaster Training, Conscires Agile Practices•• Scrum, Jeff Sutherland/Ken Schwaber,, 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, DaveWest/Tom Grant, Forrester, Jan. 2010 58
  59. 59. Sources• Agile Estimating and Planning, Mike Cohn, Prentice Hall, Nov. 2005• Planning and Tracking Agile Projects, Mike Cohn, Mountain GoatSoftware, March 2007• Agile Project Management: Estimating the Unknown, Rick Freedman,TechRepublic, June 2009• Agile Success Factors, Jeff Langr/Tim Ottinger,, 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. 60. Sources• Key Success Factors in Top-Down Agile Adoption, Ross Pettit, AgileJournal, March 2007• The Agile Heartbeat, John Graham-Cumming, Electric Cloud, 2009• Best Practices for Implementing Agile Methods: A Guide for Departmentof Defense Software Developers, Ann Fruhling/Alvin Tarrell, University ofNebraska 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• 60
  61. 61. THANK YOU!