A 3-Day Introduction for Sr. Engineers and Tech. Support Staff

13,070 views

Published on

A 3-Day Introduction for Sr. Engineers and Tech. Support Staff

  1. 1. A 3-Day Introductionfor Sr. Engineers and Tech. Support Staff Dr. David F. Rico, PMP, ACP, CSM Twitter: @dr_david_f_rico Website: http://www.davidfrico.com LinkedIn: http://www.linkedin.com/in/davidfricoFacebook: http://www.facebook.com/profile.php?id=1540017424
  2. 2. Author Background DoD contractor with 28+ years of IT experience B.S. Comp. Sci., M.S. Soft. Eng., & D.M. Info. Sys. Large gov’t projects in U.S., Far/Mid-East, & Europe  Published six books & numerous journal articles  Adjunct at George Washington, UMUC, & Argosy  Agile Program Management & Lean Development  Specializes in metrics, models, & cost engineering  Six Sigma, CMMI, ISO 9001, DoDAF, & DoD 5000  Cloud Computing, SOA, Web Services, FOSS, etc. 2
  3. 3. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 3
  4. 4. Information Age U.S. is no longer an industrial-age nation U.S. part of a group of post-industrial countries U.S. consists of information-age knowledge workers 100% 80%Percent of Economy Information 60% Service 40% Industry Agriculture 20% 0% 1860 1870 1880 1890 1900 1910 1920 1930 1940 1950 1960 1970 1980 1990 Bell, D. (1999). The coming of post industrial society. New York, NY: Basic Books. 4
  5. 5. System Complexity is Growing 21st century systems are becoming more complex Number of physical parts are becoming smaller Nano-circuitry and software hide complexity Moody, J. A., et al. (1997). Metrics and case studies for evaluating engineering designs. Upper Saddle River, NJ: Prentice-Hall. 5
  6. 6. Software Century No. of software-intensive systems is growing 80% of US DoD functions performed in software Major driver of cost, schedule, & tech. performance Kennedy, M. P., & Umphress, D. A. (2011). An agile systems engineering process: The missing link. Crosstalk, 24(3), 16-20. 6
  7. 7. Technology Change 21st century systems are technology-intensive Technology is evolving at an exponential speed Technology is obsolete before project completion Kurzweil, R. (2005). The singularity is near: When humans transcend biology. New York, NY: Penguin Group. 7
  8. 8. Large, Traditional Projects Big projects result in poor quality and scope changes Productivity declines with long queues/wait times Long projects are unsuccessful or canceled Size vs. Quality Size vs. Requirements Growth 16.00 40%Defect Density 12.80 32% Percentage 9.60 24% 6.40 16% 3.20 8% 0.00 0% 0 2 6 25 100 400 0 2 6 25 100 400 Lines of Code (Thousands) Lines of Code (Thousands) Size vs. Productivity Size vs. Success 5.00 60%Code Production Rate 4.00 48% Percentage 3.00 36% 2.00 24% 1.00 12% 0.00 0% 0 2 6 25 100 400 0 2 6 25 100 400 Lines of Code (Thousands) Lines of Code (Thousands) Jones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill. 8
  9. 9. Global Project Failures  Challenged and failed projects hover at 67%  Big projects fail more often, which is 5% to 10%  Of $1.7T spent on IT projects, over $858B were lost $1.8 2010 33% 41% 26% 2008 32% 44% 24% $1.4 Trillions (US Dollars) 2006 35% 46% 19% 2004 29% 53% 18% $1.1Year 2002 34% 51% 15% 2000 28% 49% 23% $0.7 1998 26% 46% 28% $0.4 1996 27% 33% 40% 1994 16% 53% 31% $0.0 0% 20% 40% 60% 80% 100% 2002 2003 2004 2005 2006 2007 2008 2009 2010 Successful Challenged Failed Expenditures Failed Investments Standish Group. (2010). Chaos summary 2010. Boston, MA: Author. Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch. 9
  10. 10. Requirements Defects & Waste  Requirements defects are #1 reason projects fail  Traditional projects specify too many requirements  More than 65% of requirements are never used at all Defects Waste Never Requirements 45% 47% Other 7% Always 7% Implementation Often 13% 18% Rarely Design 19% 28% Sometimes 16% Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20 Johnson, J. (2002). ROI: Its your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy. 10
  11. 11. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 11
  12. 12. Today’s Whirlwind Environment Global Competition Work Life Imbalance Demanding Customers  Overruns Vague  Attrition Requirements  Escalation  Runaways  Cancellation Organization Downsizing Technology Change System Complexity 12
  13. 13. Need for a New Model  Need for a new model of system development  Cope with high-level of uncertainty and ambiguity  With just the right balance of flexibility and discipline R&D Oriented People Centered Adaptive Customer Friendly Fast & Efficient Disciplined New discoveries  Highly-talented people  Global threats  Customer interaction  New technology  Lightweight strategy Complex problems  Cross-functional teams  Market threats  A lot of communication  Quick decision-making  Lightweight plans One-off systems  Small team size  New customer needs  Customer demos  Iterative delivery cycles  Lightweight lifecycles Vague requirements  A lot of communication  Changing scope  Customer feedback  Frequent deliveries  Security engineering Incomplete information  Interpersonal trust  Changing technology  Business value focus  Fast delivery schedules  Light requirements High uncertainty  Rich collaboration  Changing regulations  Customer satisfaction  Short timelines  Light architecture Experimentation  Empowered decisions  Continuous change  Customer responsive  Fast time-to-market  Lightweight design Simulations  Sustainable pace  Flexible culture  Customer sensitivity  First-mover capability  Code reviews Prototyping  Daily interaction  Flexible attitudes  Customer relationships  Minimal process costs  Rigorous V&V Innovation oriented  Rich communications  Flexible policies  Customer contact  Low work-in-process -  Rigorous CM New products  Face-to-face interaction  Flexible processes  Customer involvement  Flexible processes  Rigorous QA Creative solutions  Cohesiveness  Flexible technologies  Customer driven  Market responsiveness  Project reviews Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education. Chin, G. (2004). Agile project management: How to succeed in the face of changing project requirements. Broadway, NY: Amacom. DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass. Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 13
  14. 14. What is Agility? A-gil-i-ty (ə-ji-lə-tē) Property consisting of quickness, lightness, and ease of movement; To be very nimble  The ability to create and respond to change in order to profit in a turbulent global business environment  The ability to quickly reprioritize use of resources when requirements, technology, and knowledge shift  A very fast response to sudden market changes and emerging threats by intensive customer interaction  Use of evolutionary, incremental, and iterative delivery to converge on an optimal customer solution  Maximizing the BUSINESS VALUE with right-sized, just- enough, and just-in-time processes and documentation  Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley. 14
  15. 15. What are Agile Methods? People-centric way to create innovative solutions Market-centric model to maximize business value Product-centric vs. wasteful processes/documents Agile Methods Agile Methods Traditional Methods ‘Values’ ‘Principles’ ‘Values’ Customer also Customer valued Contract known as more than Collaboration Interaction Negotiation Individuals & also High Performance valued Processes known as more than Interactions Teams & Tools Working also Iterative valued Comprehensive known as more than Systems Development Documentation Responding also Adaptability valued Following to Change known as more than a Plan or Flexibility Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org. 15
  16. 16. How do Lean/Agile Intersect? Agile is naturally lean and based on small batches Agile directly supports six principles of lean thinking Agile may be converted to a continuous flow systemAgile Values Lean Pillars Lean Principles Lean & Agile Practices Flow Principles  Customer relationships, satisfaction, trust, and loyaltyEmpowered Relationships  Team authority, empowerment, and resources Decentralization Teams  Team identification, cohesion, and communication  Product vision, mission, needs, and capabilities Respect Customer Value  Product scope, constraints, and business value Economic View for People  Product objectives, specifications, and performance Customer  As is policies, processes, procedures, and instructionsCollaboration  To be business processes, flowcharts, and swim lanes WIP Constraints Value Stream  Initial workflow analysis, metrication, and optimization & Kanban  Batch size, work in process, and artifact size constraints Control Cadence Iterative Continuous Flow  Cadence, queue size, buffers, slack, and bottlenecks Delivery  Workflow, test, integration, and deployment automation & Small Batches  Roadmaps, releases, iterations, and product priorities Continuous  Epics, themes, feature sets, features, and user stories Customer Pull Fast Feedback Improvement  Product demonstrations, feedback, and new backlogsResponding  Refactor, test driven design, and continuous integration to Change  Standups, retrospectives, and process improvements Manage Queues/ Perfection  Organization, project, and process adaptability/flexibility Exploit Variability    Womack, J. P., & Jones, D. T. (1996). Lean thinking: Banish waste and create wealth in your corporation. New York, NY: Free Press. Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. New York, NY: Celeritas. Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. DoD AT&L Magazine, 39(6). 16
  17. 17. When to Use Agile Methods? On exploratory or research/development projects When fast customer responsiveness is paramount In organizations that are highly-innovative & creative Traditional Project Management Agile Project Management  Predictable situations  High-levels of uncertainty and unpredictability  Low-technology projects  High-technology projects  Stable, slow-moving industries  Fast-paced, highly-competitive industries  Low-levels of technological change  Rapid pace of technological change  Repeatable operations  Research-oriented, discovery projects  Low-rates of changing project performance  Large-fluctuations in project performance  Long-term, fixed-price production contracts  Shorter-term, performance-based RDT&E contracts  Achieving concise economic efficiency goals  Achieving high-impact product/service effectiveness  Highly-administrative contracts  Highly-creative new product development contracts  Mass production and high-volume manufacturing  Customer-intensive, one-off product/service solutions  Highly-predictable and stable market conditions  Highly-volatile and unstable market conditions  Low-margin industries such as commodities  High-margin, intellectually-intensive industries  Delivering value at the point-of-plan  Delivering value at the point-of-sale Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press. 17
  18. 18. Agile World View Agility has many dimensions other than IT Ranges from leadership to technological agility The focus of this brief is systems development agility Agile Leaders Agile Organization Change Agile Acquisition & Contracting Agile Strategic Planning Agile Capability Analysis  Agile Program Management Agile Project Management  Agile Systems Development Agile Processes & Practices Agile Tools Agile Information Systems Agile Tech. 18
  19. 19. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 19
  20. 20. Agile Adoption Rates VersionOne found 80% using agile methods today Most are using Scrum with several key XP practices Release planning/continuous integration are vital tools House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne. 20
  21. 21. Surveys of Agile Methods Many surveys of agile methods since 2003 AmbySoft and VersionOne collect annual data Agile benefits are above 50% in most categories Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdf. 21
  22. 22. Case Studies of Agile Methods Agile (138 pt.) and traditional methods (99 pt.) Agile methods fare better in all benefits categories Agile methods 359% better than traditional methods Category Agile Traditional Difference Cost Reduction 9% Schedule Reduction 33% Productivity Improvement 55% Quality Improvement 24% Customer Satisfaction Imp. 56% Return on Investment 2,811% 470% 2,341% Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18. 22
  23. 23. Benefits of Agile Methods Analysis of 23 agile vs. 7,500 traditional projects Agile projects are 54% better than traditional ones Agile has lower costs (61%) and fewer defects (93%) 2.8 18 Before Agile Before Agile 3.00 20 After Agile After Agile 2.25 15 11 1.1 1.50 10 61% 39% 0.75 5 Lower Less Cost Staff Project Cost in Millions $ Total Staffing 18 2270 Before Agile Before Agile 20 2500 13.5 After Agile After Agile 15 1875 10 1250 381 93% 5 24% 625 Less Faster Defects Delivery Time in Months Cumulative Defects Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada. 23
  24. 24. Benefits of Organizational Agility  Study of 15 agile vs. non-agile Fortune 500 firms  Based on models to measure organizational agility  Agile firms out perform non-agile firms by up to 36% Hoque, F., et al. (2007). Business technology convergence. The role of business technology convergence in innovation and adaptability and its effect on financial performance. Stamford, CT: BTM Institute. 24
  25. 25. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 25
  26. 26. Crystal Methods Created by Alistair Cockburn in 1991 Has 14 practices, 10 roles, and 25 products Scalable family of techniques for critical systems Cockburn, A. (2002). Agile software development. Boston, MA: Addison-Wesley. 26
  27. 27. Scrum Created by Jeff Sutherland at Easel in 1993 Has 5 practices, 3 roles, 5 products, rules, etc. Uses EVM to burn down backlog in 30-day iterations Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall. 27
  28. 28. Dynamic Systems Dev. Created by group of British firms in 1993 15 practices, 12 roles, and 23 work products Non-proprietary RAD approach from early 1990s Stapleton, J. (1997). DSDM: A framework for business centered development. Harlow, England: Addison-Wesley. 28
  29. 29. Feature Driven Development Created by Jeff De Luca at Nebulon in 1997 Has 8 practices, 14 roles, and 16 work products Uses object-oriented design and code inspections Palmer, S. R., & Felsing, J. M. (2002). A practical guide to feature driven development. Upper Saddle River, NJ: Prentice-Hall. 29
  30. 30. Extreme Programming Created by Kent Beck at Chrysler in 1998 Has 28 practices, 7 roles, and 7 work products Popularized pair programming and test-driven dev. Test User Scenarios Stories New Requirements Bugs Stories System Release Latest Customer Architectural Metaphor Release Plan Version Acceptance Approval Small Iteration Spike Planning Tests Releases Uncertain Confident Estimates Estimates Next Iteration Spike Beck, K. (2000). Extreme programming explained: Embrace change. Reading, MA: Addison-Wesley. 30
  31. 31. Kanban Adapted to IT by Dave Anderson in 2006 Activities, buffers, queues, WIP limits, tasks, etc. Lean, JIT pull/demand system leading to high quality Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 31
  32. 32. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 32
  33. 33. Onsite Customers Term coined by Kent Beck in 1999 Customer who sits with developers full-time Fast and efficient way to capture customer needs Tabaka, J. (2006). Collaboration explained: Facilitation skills for software project leaders. Upper Saddle River, NJ: Addison Wesley. 33
  34. 34. Release Planning Created by Kent Beck at Chrysler in 1998 Project plan with a 30-60-90-day timing horizon Disciplined and adaptable project management F/W Beck, K., & Fowler, M. (2004). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. 34
  35. 35. User Stories Term coined by Kent Beck in 1999 Functions or features of value to customers Highly-adaptable requirements engineering process Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley. 35
  36. 36. Test-Driven Development Term coined by Kent Beck in 2003 Consists of writing all tests before design Ensures all components are verified and validated Beck, K. (2003). Test-driven development: By example. Boston, MA: Addison-Wesley. 36
  37. 37. Pair Programming Term coined by Jim Coplien in 1995 Consists of two side-by-side developers Highly-effective group problem-solving technique Williams, L., & Kessler, R. (2002). Pair programming illuminated. Boston, MA: Pearson Education. 37
  38. 38. Refactoring Term coined by William Opdyke in 1990 Process of frequently redesigning the system Improves readability, maintainability, and quality Fowler, M. (1999). Refactoring: Improving the design of existing code. Boston, MA. Addison-Wesley. 38
  39. 39. Continuous Integration Term coined by Martin Fowler in 1998 Process of automated build/regression testing Evaluates impact of changes against entire system Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration: Improving software quality and reducing risk. Boston, MA: Addison-Wesley. 39
  40. 40. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 40
  41. 41. User Story Requirement written from perspective of a user Function or a feature that has value to a customer Discrete unit of functionality written on an index card Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley. 41
  42. 42. Conditions of Satisfaction Conditions of satisfaction added to user stories Serve as a set of user acceptance test criteria Used for development and operational tests Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley. 42
  43. 43. Detailed Sub-Stories Details can be added in smaller sub-stories Good way to functionally-decompose user stories May also represent an object-oriented point-of-view Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley. 43
  44. 44. Epics Epics are very large enterprise requirements They are often called capabilities or feature sets A very-large unit of work that must be decomposed Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley. 44
  45. 45. User Story Workshops Form stakeholder groups to brainstorm user stories Goal is to write as many user stories as possible Start with epics and decompose user stories Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Addison-Wesley. 45
  46. 46. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Autoamted Testing Agile Summary Agile Security Engineering Agile Resources 46
  47. 47. Scrum Project Management Created by Jeff Sutherland at Easel in 1993 Product backlog comprised of customer needs Barely-sufficient project management framework Initial Planning Sprint Cycle Discovery Session Sprint  Agile Training  Select Tasks and Create Tests  Project Discovery  Create Simple Designs  Code and Test Software Units  Process Discovery  Perform Integration Testing  Team Discovery  Maintain Daily Burndown Chart  Initial Backlog  Update Sprint Backlog Release Planning Sprint Planning Daily Scrum Sprint Review  Business Case  Set Sprint Capacity  Completed Backlog Items  Present Backlog Items  Desired Backlog  Identify Tasks  Planned Backlog Items  Record Feedback  Estimate Tasks  Impediments to Progress  Adjust Backlog  Hi-Level Estimates  Prioritize Backlog  Finalize Backlog Sprint Retrospective Product Backlog Sprint Backlog Potentially Shippable Product  Prioritized Requirements  List of Technical Tasks Assigned to a Sprint  Working Operational Software Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press. 47
  48. 48. XP Project Management Created by Kent Beck at Chrysler in 1998 Release plan is comprised of customer needs Lightweight, rigorous near-term planning element Release Planning Iteration Planning Exploration Phase Exploration Phase  Build a Team  Split User Stories  Analyze Release Plan  Read User Stories  Write User Stories  Spike User Stories  Identify Iteration Goal  Develop Tasks  Estimate User Stories  Write User Tests  Select User Stories  Split Tasks Commitment Phase Commitment Phase  Sort by Value  Choose a Scope  Accept Tasks  Analyze Schedules  Sort by Risk  Set Iteration Length  Set Individual Velocity  Set Load Factors  Set Velocity  Develop Release Plan  Estimate Tasks  Balance Tasks Steering Phase Steering Phase  Select Iteration  New Release Plan  Select Partner  Unit/Integration Test  Adjust Velocity  Select Tools  Write Unit Tests  User Acceptance Test  Insert New Stories  Adjust Teams  Design and Code  Record Progress Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. 48
  49. 49. Project Leadership Model Created by Sanjiv Augustine at CC Pace in 2005 Builds agile cultures, mind-sets, and environments Leadership model for managing agile project teams Foster Alignment and Cooperation Encourage Emergence and Self Organization Learning/Adaptation Organic Teams Guiding Vision Simple Rules Open Information Light Touch Adaptive Leadership Leadership Leadership Leadership Leadership Leadership Leadership Craftsmanship  Team Vision  Culture of Change  Conduct Standups  Adapt Style  Embodied Presence Collaboration  Team Alignment  Value Focus  Promote Feedback  Roving Leadership  Embodied Learning Guiding Coalition  Bold Future  Build Trust  Go With Flow Community  Shared Expectations  Facilitate Action  Work Life Quality  Build on Strengths  Gain Commitments Management Management Management Management Management Management Identify Community  Business Outcomes  Assess Status Quo  Team Collocation  Decentralize Control  Daily Feedback Design Structures  Delineate Scope  Customize Method  Get Onsite Customer  Pull vs. Push  Monitor/Adapt Rules Get Team Players  Estimate Effort  Release Plan  Practice Pairing  Manage Flow  Monitor Practices Adaptive Enterprise  Design Vision Box  Iteration Plans  Information Radiator  Use Action Sprints  Retrospectives  Elevator Statement  Facilitate Design  Map Value Stream  Scenario Planning  Conduct Testing  Manage Releases Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education. 49
  50. 50. Flexible Project Management Created by Doug DeCarlo at Cutter in 2004 Focus is on collaboration, scoping, and speed Thinner traditional project management approach Visionate Speculate Innovate Re-evaluate Disseminate Sponsor’s Vision Planning Meeting Learning by Doing Business Questions Product Launch  Interview Sponsor  Collective Vision  SCORE Model  Who Needs It?  Acceptance Testing  Describe Objectives  Size Deliverables  Architecture  What Will It Take?  Documentation  Project Prospectus  Map Schedule  Development  Can We Get It?  Support Plan  Business Questions  Choose Life Cycle  Construction  Is It Worth It?  Maintenance Plan  Requirements ID’d  Testing  Deploy Solution  Development Tools  Time Boxing  Customer Service Collective Vision Project Review  Risk Planning  Trial and Error  Scope Meeting  Check Performance  Collaboration  Future Scenarios  Check Schedule Stabilization Post Meeting  Project Skinny  Check Costs  Training/Education  Project Boundaries  PM Infrastructure Generate Results  Check Benefits  Utilization  Project Vision  Financial Goals  Visibility  Check Project ROI  Performance  Win Conditions  Benefit Plan  Early Value  Go/No-Go Decision  Feedback  Benefit Map  Partner Agreements  Fast Failures  Corrective Action  Wow Factor Project Changes  Uncertainty Profile Business Questions Business Questions Lessons Learned  Re-Direct As-Needed  Go/No-Go Decision  Modify Questions  Update Vision Collective Vision Team Rewards  Update Stakeholders Select Core Team Update Prospectus Update Prospectus  Re-examine Team Track Benefits DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass. 50
  51. 51. Adaptive Project Management Created by Bob Wysocki for consulting in 2008 Designed to be a generic model for non-IT projects Lightweight traditional project management approach Adaptive Project Framework Scoping Planning Feasibility Checkpoint Review  Identify Opportunity  Identify Project Type  Develop Prototype  Analyze Needs  Finalize Documents  Develop CoS  Prioritize Constraints  Reprioritize Needs  Evaluation Solution  Lessons Learned  Write PoS  Develop WBS  Detailed WBS  Estimate Value  Process Changes  Document Needs  Team Formation  Estimate Resources  Determine Success  Final Report  Stage Gate 1 Review  Stage Gate 2 Review  Stage Gate 3 Review  Stage Gate 4 Review  Stage Gate 5 Review Cyclical Product or Service Implementation Cycle Planning Product or Service Implementation Daily Meetings Cycle Reviews  Responsibilities  Select Personnel with Needed Skills  Arrange Facilities  Update Requirements  Timelines  Identify Detailed Technical Tasks  Prepare Agendas  Update Scope  Work Packages  Create Detailed Architectures and Designs  Send Meeting Notices  Update Schedules  Communications  Select and Implement Technical Solutions  Facilitate Meetings  Update Plans  Governance  Perform Development and Operational Tests  Record Action Items  Inform Stakeholders Continuous Improvement Stage Gate 3.n  Continually improve process, documents, team, architecture, designs, implementation, tests, etc. Review Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education. 51
  52. 52. Agile Project Management Created by Jim Highsmith at Cutter in 2003 Focus on strategic plans and capability analysis Most holistic agile project management framework Innovation Lifecycle Envision Speculate Explore Launch Close  Product Vision  Gather Requirements  Iteration Management  Final Review  Clean Up Open Items  Product Architecture  Product Backlog  Technical Practices  Final Acceptance  Support Material  Project Objectives  Release Planning  Team Development  Final QA  Final Retrospective  Project Community  Risk Planning  Team Decisions  Final Documentation  Final Reports  Delivery Approach  Cost Estimation  Collaboration  Final Deployment  Project Celebration Iterative Delivery Technical Planning Development, Test, & Evaluation Operational Testing Adapt  Story Analysis  Development Pairing  Integration Testing  Focus Groups  Task Development  Unit Test Development  System Testing  Technical Reviews  Task Estimation  Simple Designs  Operational Testing  Team Evaluations  Task Splitting  Coding and Refactoring  Usability Testing  Project Reporting  Task Planning  Unit and Component Testing  Acceptance Testing  Adaptive Action Continuous Story Deployment  Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and Integration Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 52
  53. 53. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 53
  54. 54. Envision Phase Determine product vision and project objectives Identifies project community and project team The major output is a “Product Vision Box” Envision Phase Product Vision  Product Vision Box  Elevator Test Statement  Product Roadmap  Product Features Delivery Approach  Product Vision Document Product Architecture  Self-Organization Strategy  Skeleton Architecture  Collaboration Strategy  Hardware Feature Breakdown  Communication Strategy  Software Feature Breakdown  Process Framework Tailoring  Organizational Structure  Practice Selection & Tailoring  Guiding Principles Project Community Project Objectives  Get the Right People  Project Data Sheet  Participant Identification  Key Business Objectives  Types of Stakeholders  Tradeoff Matrix  List of Stakeholders  Exploration Factor  Customer-Developer Interaction  Requirements Variability Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 54
  55. 55. Speculate Phase Determine organizational capability/mission needs Identifies feature-sets and system requirements The major output is a “System Release Plan” Speculate Phase Gather Requirements  Analyze Feasibility Studies  Evaluate Marketing Reports  Gather Stakeholder Suggestions  Examine Competitive Intelligence Cost Estimation  Collaborate with Customers Product Backlog  Establish Estimate Scope  Product Features List  Establish Technical Baseline  Feature Cards  Collect Project Data  Performance Requirements  Size Project Information  Prioritize Features  Prepare Baseline Estimates  Feature Breakdown Structure Risk Planning Release Planning  Risk Identification  Project Startup Activities  Risk Analysis  Assign Stories to Iterations  Risk Responses  First Feasible Deployment  Risk Monitoring  Estimate Feature Velocity  Risk Control  Determine Product Scope Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 55
  56. 56. Explore Phase Determine technical iteration objectives/approaches Identifies technical tasks and technical practices The major output is an “Operational Element” Explore Phase Iteration Management  Iteration Planning  Estimate Task Size  Iteration Length  Workload Management Collaboration  Monitoring Iteration Progress Technical Practices  Pair Programming  Reduce Technical Debt  Daily Standup Meetings  Simple Design  Daily Product Team Interaction  Continuous Integration  Stakeholder Coordination  Ruthless Automated Testing  Customer Interactions  Opportunistic Refactoring Team Decisions Team Development  Decision Framing  Focus Team  Decision Making  Molding Group into Team  Decision Retrospection  Develop Individual Capabilities  Leadership and Decision Making  Coach Customers  Set and Delay Decision Making  Orchestrate Team Rhythm Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 56
  57. 57. Launch Phase Determine the state of the final deployment system Perform final development, test, and QA reviews The major output is a “Deployment Package” Launch Phase Final Review  Final Release Plan Review  Final Requirements Review  Final Design Review  Final Code Review Final Deployment  Final Development Team Review Final Acceptance  Final Source Code  Final Test Plan Review  Final Build  Final Test Case Review  Final Integration  Final Test Environment Review  Final Image  Final Acceptance Test Review  Final Deployment Package  Final Test Results Review Final Documentation Final Quality Assurance  Final Release Plans  Final Functional Configuration Audit  Final Requirements Database  Final Physical Configuration Audit  Final Development Documents  Final Quality Assurance Plan Review  Final Maintenance Documents  Final QA Procedures Review  Final Operations Documents  Final Quality Assurance Review Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 57
  58. 58. Close Phase Determine project outcome and effectiveness Identifies strengths, weaknesses, and rewards The major output is a “Lessons-Learned Report” Close Phase Clean Up Open Items  Close Open Action Items  Close Open Change Requests  Close Open Problem Reports  Close Open Defect Reports Project Celebration  Close Open Project Issues Support Material  Individual Rewards  Finalize Documentation  Group Rewards  Finalize Production Material  Partner Rewards  Finalize Manufacturing Material  Managerial Rewards  Finalize Customer Documentation  Product Rewards  Finalize Maintenance Information Final Reports Final Retrospective  End-of-Project Reports  Process Performance Assessment  Administrative Reports  Internal Product Assessment  Release Notes  External Product Assessment  Financial Reports  Team Performance Assessment  Facilities Reports  Project Performance Assessment Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 58
  59. 59. Leadership Considerations Agile management is delegated to the lowest level There remain key leadership roles & responsibilities Communication, coaching, & facilitation are key ones Facilitate selection of methods for obtaining and maintaining executive commitment, project Customer Communication resources, corporate communications, and customer interaction Product Visioning Facilitate selection of methods for communicating product purpose, goals, objectives, mission, vision, business value, scope, performance, budget, assumptions, constraints, etc. Distribution Strategy Facilitate selection of virtual team distribution strategy to satisfy project goals and objectives Facilitate selection of methods for training, coaching, mentoring, and other team building Team Development approaches Standards & Practices Facilitate selection of project management and technical practices, conventions, roles, responsibilities, and performance measures Telecom Infrastructure Facilitate selection of high bandwidth telecommunication products and services Development Tools Facilitate selection of agile project management tools and interactive development environment High Context Meetings Facilitate selection of high context agile project management and development meetings Coordination Meetings Facilitate selection of meetings and forums for regular communications between site coordinators Facilitate selection of methods for maximizing periodic face to face interactions and F2F Communications collaboration Facilities selection of methods for process improvement, problem resolution, conflict Performance Management management, team recognition, product performance, and customer satisfaction Rico, D. F. (2010). The paradox of agile project management and virtual teams. Fairfax, VA: Gantthead.Com. 59
  60. 60. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 60
  61. 61. Release Planning Release planning is basic agile planning approach Begins with capturing and ordering customer needs Output is a release plan with resources and timelines Write User Stories Estimate User Stories Prioritize User Stories Split User Stories Develop Release Plan • Hold customer • Estimate size • Estimate total • Evaluate story • Select release meeting using Delphi resources size scope (PERT) • Propose user • Estimate • Evaluate • Select iteration stories • Estimate using business value needed velocity & planning poker resources length • Clarify user • Estimate stories • Estimate using technical risks • Evaluate • Estimate analogy business value release budget • Record user • Sequence user stories • Estimate user stories • Evaluate risks • Identify overall algorithmic and sequence constraints • Verify user • Verify overall models stories sequence • Divide and • Develop • Estimate using reorder user release plan prototypes stories (spikes) Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 61
  62. 62. Write User Stories Release planning begins by identifying user needs User needs are captured in form of user stories Customer records needs on user story cards Write User Stories Hold Customer Meeting Verify Propose User User Stories Stories Record Clarify User User Stories Stories Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 62
  63. 63. Estimate User Stories The complexity of each user story is then estimated Complexity is captured in the form of story points Story points are a relative size of user needs Estimate User Stories Estimate Using Delphi (PERT) Estimate Estimate Using Using Prototypes (Spikes) Planning Poker Estimate Estimate Using Using Algorithmic Models Analogy Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 63
  64. 64. Prioritize User Stories Customers must prioritize all of their user stories Cost, value, risk, and other factors are considered Tradeoffs are made when rank ordering user stories Prioritize User Stories Estimate Total Resources Verify Estimate Overall Business Sequence Value Sequence Estimate User Technical Stories Risks Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 64
  65. 65. Split User Stories Stories may be decomposed for a variety of reasons Oftentimes, user stories are too big and complex Customers are responsible for splitting them Split User Stories Evaluate User Story Size Divide Evaluate and Reorder Needed User Stories Resources Evaluate Evaluate Risks and Business Sequence Value Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 65
  66. 66. Develop Release Plan Customers identify which user stories they want Developers estimate iteration length, budget, etc. A release plan is designed covering 9 to 18 months Develop Release Plan Select Release Scope Develop Select Release Iteration Plan Velocity & Length Identify Estimate Overall Release Constraints Budget Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 66
  67. 67. Agenda Agile Background Agile Teamwork Agile Introduction Agile Scalability Agile Business Case Agile Lean/Kanban Agile Life Cycles Agile Scrum Agile Practices Agile Metrics & Models Agile Requirements Agile Costs & Benefits Agile Project Mgt. Models Agile Earned Value Mgt. Agile Project Mgt. Phases Agile Documentation Agile Release Planning Agile Automated Tools Agile Iteration Planning Agile Contract Models Agile Estimating Agile Change Models Agile Risk Analysis Agile Case Studies Agile Automated Testing Agile Summary Agile Security Engineering Agile Resources 67
  68. 68. Write Technical Tasks Customer and developers review user stories Developers divide user stories into technical tasks Detailed technical activity is recorded on task cards Write Technical Tasks Hold Customer Meeting Develop Review Acceptance User Criteria Stories Write Identify Task Technical Descriptions Tasks Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 68
  69. 69. Assign Technical Tasks Complete task list is reviewed by developers Technical requirements are aligned by skill sets Technical tasks are assigned to programmer pairs Assign Technical Tasks Evaluate Initial Tasks Assign Identify Tasks Technical to Pairs Requirements Organize Align with Into Skills and Pairs Interests Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 69
  70. 70. Estimate Technical Tasks Technical tasks are analyzed by pair groupings Effort is estimated by analogy, Delphi method, etc. Unit test cases are developed and tasks are verified Estimate Technical Tasks Analyze Assigned Tasks Verify Estimate Technical by Analogy, Tasks Delphi, Tool, etc. Develop Determine Unit Level Effort in Test Cases Ideal Days Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 70
  71. 71. Decompose Technical Tasks Overall technical task sizes are evaluated Larger tasks are decomposed into smaller ones New technical tasks are developed and propagated Decompose Technical Tasks Analyze Technical Task Sizes Assign New Decompose Technical Tasks Large to Pairs Technical Tasks Write New Identify Technical Task New Descriptions Technical Tasks Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 71
  72. 72. Develop Iteration Plans Establish individual productivity time and pace Balance the workload among individual resources Develop iteration plans with tasks, dates, pairs, etc. Develop Iteration Plans Establish Personnel Load Factors Establish Balance Iteration Personnel Plan Resources Compile Establish Technical Task Technical Task Assignments Traceability Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Cohn, M. (2004). User stories applied: For agile software development. Boston, MA: Pearson Education. 72

×