Your SlideShare is downloading. ×
0
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lean & Agile Project Management: For Executives, Sr. Managers, & Key Decision Makers

2,024

Published on

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,024
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
148
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Lean & AgileProject Managementfor Executives, Sr. Managers, & Key Decision Makers Dr. David F. Rico, PMP, ACP, CSM Twitter: @dr_david_f_rico Website: http://www.davidfrico.com LinkedIn: http://www.linkedin.com/in/davidfrico Facebook: http://www.facebook.com/profile.php?id=1540017424
  • 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. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 3
  • 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. 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. 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. Technological 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. 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. 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. 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. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 11
  • 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. Need for a New Model  Need for a new model of project management  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. 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. Values of Agile Project Mgt. People-centric way to create innovative solutions Market-centric model to maximize business value Alternative to large document-based methodologies 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. 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. When to use Agile Proj. Mgt. 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. Agile World View “Agility” has many dimensions other than IT It ranges from leadership to technological agility The focus of this brief is program management 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. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 19
  • 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. 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. 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. 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. Agile Testing Costs & Benefits Most agile testing tools are “free” open source A build server is no more than a commodity PC 10x more efficient/effective than traditional testing Grant, T. (2005). Continuous integration using cruise control. Northern Virginia Java Users Group (Novajug), Reston, Virginia, USA. Fredrick, J. (2008). Accelerate software delivery with continuous integration and testing. Japanese Symposium on Software Testing, Tokyo, Japan. 24
  • 25. Business Value of Agile Methods Productivity is accelerated with light weight processes Quality goals are obtained with disciplined processes Agile Methods have up to 20 times lower total costs Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross. 25
  • 26. 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. 26
  • 27. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 27
  • 28. 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. 28
  • 29. 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. 29
  • 30. 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. 30
  • 31. 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. 31
  • 32. Adaptive Project Framework 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. 32
  • 33. 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. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 33
  • 34. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 34
  • 35. 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. 35
  • 36. 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. 36
  • 37. 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. 37
  • 38. Adapt Phase Determine the effectiveness of operational elements Identifies customer feedback and corrective actions The major output is a “Process Improvement Plan” Adapt Phase Customer Focus Groups  Requirements Reviews  Preliminary Design Reviews  Critical Design Reviews  Product Demonstration Reviews Adaptive Action  Acceptance Testing Reviews Technical Reviews  Release Plan Adaptations  Desk Checks/Individual Reviews  Iteration Plan Adaptations  Structured Walkthroughs  Feature Set Adaptations  Formal Software Inspections  User Story Adaptations  Quality Assurance Audits  Task Plan Adaptations  Configuration Management Audits Project Reporting Team Evaluations  Scope and Quality Status  Communications Quality  Cost and Schedule Status  Team Cohesiveness  Risk and Value Status  Interpersonal Trust  Customer Satisfaction Status  Individual Talent and Effort  Team and Agility Status  Team Performance/Effectiveness Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 38
  • 39. 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. 39
  • 40. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 40
  • 41. 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. 41
  • 42. 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. 42
  • 43. 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. 43
  • 44. 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. 44
  • 45. 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. 45
  • 46. User Story Example Simple one sentence user needs from customers May be decomposed into lower level user stories Acceptance test criteria are often written as well 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. 46
  • 47. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 47
  • 48. Write Technical Tasks Customers 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. 48
  • 49. 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. 49
  • 50. 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. 50
  • 51. 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. 51
  • 52. 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. 52
  • 53. Release/Iteration Plan An example of release and iteration plan Relationships between user stories and plans Shows key data such as story points and velocity Product Backlog, Release Plan, & Iteration Plan Product Backlog Release Plan Iteration Plan User Story Points Release Iteration Task Team Plan Actual  Find a flight 1  Release 1 Iteration 1  Specify airport Bob/Sue 2 hours 1 hours  Specify dates 2 hours 1 hours  Specify times 2 hours 1 hours  Reserve a flight 2 Iteration 2  Enter name John/Dave 4 hours 3 hours  Enter address 4 hours 3 hours  Get confirmation no 4 hours 3 hours  Book a flight 4 Iteration 3  Enter credit card Barb/Carol 8 hours 6 hours  Enter billing info 8 hours 6 hours  Get receipt 8 hours 6 hours  Verify a flight 1  Release 2 Iteration 4  Enter confirmation no Matt/Ken 2 hours 2 hours  View itinerary 2 hours 2 hours  View payment info 2 hours 2 hours  Generate itinerary 2 Iteration 5  Enter confirmation no Jim/Jane 4 hours 3 hours  Print itinerary 4 hours 3 hours  Download itinerary 4 hours 3 hours  Check flight status 4 Iteration 6  Enter confirmation no Nat/Tim 8 hours 6 hours  View flight status 8 hours 6 hours  View gate info 8 hours 6 hours  Change flight 4  Release 3 Iteration 7  Enter confirmation no Kim/Pat 8 hours 6 hours  Change dates 8 hours 6 hours  Change times 8 hours 6 hours  Cancel flight 1 Iteration 8  Enter confirmation no Sam/Ron 2 hours 2 hours  Cancel flight 2 hours 2 hours  Verify cancellation 2 hours 2 hours  Get a refund 2 Iteration 9  Enter confirmation no Mark/Dan 4 hours 4 hours  Initiate refund 4 hours 4 hours  Verify refund status 4 hours 4 hours 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. 53
  • 54. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 54
  • 55. Wideband Delphi (PERT) Created by RAND corporation in 1940s Applied to software effort estimation in 1970s Relies on expert judgment and consensus (PERT) Estimate Using Wideband Delphi (PERT) Hold Meeting with Customers Discuss Review and Verify Each Estimates User Story Use PERT Solicit to Combine Individual Estimates Estimates Graefe, A., & Armstrong, J. S. (2011). Comparing face-to-face meetings, nominal groups, delphi, and prediction markets on an estimation task. International Journal of Forecasting, 27(1), 183-195. 55
  • 56. Planning Poker Created by James Grenning for Scrum in 2002 Similar to Wideband Delphi (or PERT) estimating Goal is to estimate size (complexity) in story points Estimate Using Planning Poker Hold Meeting with Customers Discuss Distribute and Verify Planning Estimates Poker Cards Vote on Review Size in Each Story Points User Story Molokken-Ostvold, K., & Haugen, N. C. (2007). Combining estimates with planning poker: An empirical study. Proceedings of the 18th Australian Software Engineering Conference (ASWEC 2007), Melbourne, Australia, 349-358. 56
  • 57. Analogous Estimating Utilized for software estimating in the 1970s Goal is to match new user stories with prior ones Generates estimate based on similar historical work Estimate by Analogy Hold Meeting with Customers Agree on Review Size of New Each User Stories User Story Match Analyze Old and New Previous User Stories User Stories Wen, J., Li, S., & Tang, L. (2009). Improve analogy-based software estimation using principal components analysis and correlation weighting. Proceedings of the 16th Asia-Pacific Software Engineering Conference (APSEC2009), Penang, Malaysia, 179-186. 57
  • 58. Algorithmic Models First regression models popularized in 1970s Grew into complex logarithmic models in 1990s Many algorithms and tools exist for agile estimates Estimate Using Algorithmic Models Hold Meeting with Customers Average Review Output of Each Algorithmic Models User Story Generate Select One or More One or More Estimates Algorithmic Models Rico, D. F. (2008). What is the ROI of agile vs. traditional methods? An analysis of extreme programming, test-driven development, pair programming, and scrum (using real options). TickIT International, 10(4), 9-18. 58
  • 59. Prototypes (Spikes) Prototyping applied to software in the 1970s Used for estimation by JAD and Spiral in 1980s Agile teams create rapid “Spikes” to size user stories Estimate Based on Prototypes (Spikes) Hold Meeting with Customers Estimate Review User Story Each from New Data User Story Develop Identify Rapid Problematic Prototype (Spike) User Stories Keaveney, S., & Conboy, K. (2006). Cost estimation in agile development projects. Proceedings of the European Conference on Information Systems (ECIS 2006), Goteborg, Sweden. 59
  • 60. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 60
  • 61. Risk Planning Kickoff meeting is held during release planning Type of project and risks of initial stories identified Risk management process is aligned with challenges Risk Planning Hold Customer Meeting Identify Review and Approve Risk Processes Risk Plan or Stages Identify Identify Risk Evaluation Risk Tracking Criteria Artifacts Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011 from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes. 61
  • 62. Risk Identification Low level risks identified at each stage Risks are attached to stories, tasks, tests, etc. Many risks identified during standups/retrospectives Risk Identification Identify Risks During Release Planning Identify Identify Risks During Risks During Retrospectives Sprint Planning Identify Identify Risks Risks During During Daily Sprint Reviews Standups Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011 from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes. 62
  • 63. Risk Assessment Risk backlog is periodically reviewed Risks are categorized along with likelihood Risk impact is estimated and risk data is verified Risk Assessment Review Risk Backlog Verify Categorize Risk or Determine Assessment Data Type of Risk Identify Determine Impact of Risk Probability Potential Risk or Likelihood Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011 from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes. 63
  • 64. Risk Response Risks are reviewed along with response types Appropriate responses are selected and assigned Contingency plans are developed if risks are realized Risk Response Review Risk Assessment Data Verify Review Risk Risk Response Response Data Categories Define Select a Contingency Risk Response Plans and Actions Category Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011 from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes. 64
  • 65. Risk Review Risk meetings are held with customers High priority risks are evaluated from backlog Risks are mitigated and reprioritized as necessary Risk Review Review Risk Backlog Re-categorize Evaluate & Reprioritize High-Priority Risk Backlog Risks Activate Determine if Risk Responses Risks Have if Necessary Been Realized Hamilton-Whitaker, T. (2009). Agile risk management for projects and programmes. Retrieved April 20, 2011 from http://agile101.net/2009/07/27/agile-risk-management-for-projects-and-programmes. 65
  • 66. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 66
  • 67. Security by Plan First step is to appoint a security team lead Identifying security risks & requirements is key Emphasis on training & security incident prevention Security by Plan Appoint Security Coordinator Develop Perform Security Security Plan Training Identify Security Perform Security & Privacy & Privacy Risk Requirements Assessment Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author. Microsoft. (2010). Security development lifecycle. Redmond, WA: Author. 67
  • 68. Security by Design Next step is to identify design requirements Identify security architecture and subsystems Develop threat model and reduce attack surface Security by Design Identify Security & Privacy Design Requirements Perform Document Security Security Architecture & Design Review Attack Surface Develop and Identify Critical Analyze Threat Components & Model & Reduce Security Assets Attack Surface Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author. Microsoft. (2010). Security development lifecycle. Redmond, WA: Author. 68
  • 69. Security by Implementation Then identify development & evaluation tools Identify and apply security patterns & practices Must perform manual & automated code reviews Security by Implementation Identify Development Environment Perform Manual Identify Static & Automated & Dynamic Security Security Tools Code Analysis Identify Security Apply Coding Patterns, Security Coding Standards, & Best Practices Practices Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author. Microsoft. (2010). Security development lifecycle. Redmond, WA: Author. 69
  • 70. Security by Validation Also develop security test plans and procedures Perform automated security testing & analysis Validate to-be vs. as-is security architecture Security by Validation Create Security & Privacy Test Plans & Review Procedures Perform Dynamic Test Results & Security Testing Update Security & Analysis Documentation Perform Threat Perform Fuzz Model & Attack & Penetration Surface Review Testing Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author. Microsoft. (2010). Security development lifecycle. Redmond, WA: Author. 70
  • 71. Security by Support Finally, develop security incidence response plan Systematically collect security incident reports Analyze, implement, re-verify, and update Security by Support Develop Incidence Response Plan Implement & Verify Perform Final Security Changes, Security Review & Enhancements, Archive Project & Upgrades Collect, Analyze, Develop & Prioritize & Classify Security Security Incident Maintenance Plans Reports Microsoft. (2009). Security development lifecycle for agile development. Redmond, WA: Author. Microsoft. (2010). Security development lifecycle. Redmond, WA: Author. 71
  • 72. Top 25 Vulnerabilities Top 25 security vulnerabilities identified each year Many resources available to help mitigate them 88% are preventable by security engineering Top 25 Most Dangerous Security Vulnerabilities Interactions Resources Defenses  Cross Site Scripting  Buffer Overflow  Access Control  SQL Injection  Path Traversal  Untrusted Inputs  Cross Site Requests  PHP File Inclusion  Missing Encryption  Unrestricted File Upload  Incorrect Buffer Length  Hard Coded Credentials  OS Command Injection  Improper Exceptions  Missing Authentication  Information Exposure  Array Index Validation  Permission Assignment  URL Redirection  Integer Overflow  Cryptographic Algorithm  Race Condition  Buffer Size Calculation  Software Download  Resource Allocation Brink, D. E. (2010). Security and the software development lifecycle: Secure at the source. Boston, MA: Aberdeen Group. Sans Institute. (2010). Top 25 most dangerous software errors. Retrieved April 21, 2011 from http://www.sans.org/top25-software-errors 72
  • 73. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 73
  • 74. Multi-Level Teams Enables projects to plan for the future and present Decomposes capabilities into implementable pieces Unclogs the drainpipes to let the execution flow freely Multi-Level Teams Product Management Team Product Management Team  Chief Product Manager  Chief Architect  Product Development Manager  Release Management Team members (1-2 per release team) Release Management Team Release Management Team  Product Manager  Project Manager  Chief Architect  Feature team members (1-2 per feature team) Feature Team Feature Teams  Product Specialist (and owner)  Iteration Manager  Technical and product Members  Development team members (1-2 per development team) Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 74
  • 75. Multi-Level Planning Enables multiple level enterprise plans to co-exist Allows stakeholders to build viewpoint-specific plans Ensures capabilities are delivered at regular intervals Multi-Level Planning Product Roadmap Product Roadmap  Enterprise architecture needs  Capability focused  Vision, objectives, and backlog  18 to 36 weeks Release Plan Release Plan  Subsystem architecture  Feature set focused  Strategy, objectives, and backlog  6 to 12 weeks Iteration Plan Iteration Plan  Component-level architecture  User story focused  Implementation plan, objectives, and backlog  2 to 4 weeks Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 75
  • 76. Multi-Level Backlog Enables multiple levels of abstraction to co-exist Allows customers and developers to communicate Makes optimum use of people’s time and resources Multi-Level Backlog Capabilities Capability  Mission goal or objective level Capability Capability Capability  High-level business or product function 1 2 3  Also called an Epic, i.e., multiple feature sets  Comprises 18-90 days worth of work Feature Sets Feature Set  Cross-functional mission threads Feature Feature Feature 1 2 3  Related user stories that are grouped together  Also called a Theme, i.e., implemented as an entity  Comprises 6 to 30 days worth of work User Stories User Story Story 1 Story 4 Story 7  Functional, system-level requirements  Simple requirement written by customer or user Story 2 Story 5 Story 8  A small unit of functionality having business value Story 3 Story 6 Story 9  Comprises 2 to 10 days worth of work Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 76
  • 77. Multi-Level Coordination Enables lean and agile methods to scale-up Allows enterprises to create large-scale programs Unleashes optimum productivity and overall control Multi-Level Coordination Capability Team Feature Set Team Feature Set Team Feature Set Team Feature Team Feature Team Feature Team Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 77
  • 78. Multi-Level Governance Enables enterprises to achieve functional needs Allows programs to coordinate functional activities Ensures optimal technical performance is achieved Multi-Level Governance Governing Team R T S Functional Team Functional Team Functional Team R R R T T T S S S R R R T T T S S S R R R T T T S S S Feature Team Feature Team Feature Team R A D R A D R A D R A D R A D R A D R A D R A D R A D I T C I T C I T C I T C I T C I T C I T C I T C I T C Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S R A D R A D R A D R A D R A D R A D R A D R A D R A D I T C I T C I T C I T C I T C I T C I T C I T C I T C Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S R A D R A D R A D R A D R A D R A D R A D R A D R A D I T C I T C I T C I T C I T C I T C I T C I T C I T C Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S Q M S Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 78
  • 79. Multi-Level Delivery Model Begins with a high-level product vision/architecture Includes multi-level teams and product requirements Demonstrates agile delivery model for large programs Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education. 79
  • 80. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 80
  • 81. Standard Practices Standard practices is an oft cited aid to virtual teams Agile methodologies are not known in every country Training should be provided and standards created VIDEO Video used to record and playback communications CODING Coding conventions are established WIRE FRAMES Wire frames are used for visual support USER STORIES Customer needs are captured in user stories TEMPLATES Templates are established for project communications PROCESSES Entire team follows the same agile process TRAINING Entire team is trained on agile methods Young, C., & Terashima, H. (2008). How did we adapt agile processes to our distributed development? Agile Conference, Toronto, Canada, 304-309. 81
  • 82. Virtual Infrastructure Infrastructure needs are most often overlooked Many countries do not have adequate computers Internet service is also a luxury in across the globe SECURITY Information security is established to protect project information SUPPORT 24x7 infrastructure support is available INTERNET Broadband Internet is leased and utilized SOFTWARE Synchronous and asynchronous tools are selected SERVERS Dedicated servers are established for project information LAPTOPS Entire team is provided with laptops for office and home use MOBILE Entire team is provided with cell phones, smart phones, tablets, etc. Vax, M., & Michaud, S. (2008). Distributed agile: Growing a practice together. Agile Conference, Toronto, Canada, 310-314. 82
  • 83. Virtual Tools Many projects do not standardize development tools Complete development tools are easy to assemble Development environments should be integrated MULTIMEDIA Development tools with collaborative capabilities are utilized CONTENT Wikis and other repositories are utilized METRICS Code metrics and defect tracking tools are used TESTING Unit, system, and acceptance testing tools are used BUILD Build tools are used for continuous integration and deployment VERSIONING Configuration management tools are used to manage source code WORKFLOW Release and iteration workflow tools are usedCannizzo, F., Marcionetti, G., & Moser, P. (2008). Evolution of the tools and practices of a large distributed agile team. Agile Conference, Toronto, Canada, 513-518. 83
  • 84. Virtual Meetings Frequent communication is a key to project success Communication is better than documentation alone A critical key is to encourage frequent interactions SPLINTER Virtual splinter group meetings are held, i.e., design, brainstorming, etc. RETROSPECTIVE Virtual iteration retrospectives are held DEMONSTRATION Entire team participates in virtual demonstrations DEVELOPMENT Virtual development meetings held, i.e., pair programming STANDUP Entire team participates in virtual daily standup meetings ITERATION Entire team participates in virtual iteration planning meetings RELEASE Entire team participates in virtual release planning sessions Summers, S. (2008). Insights into an agile adventure with offshore partners. Agile Conference, Toronto, Canada, 513-518. 84
  • 85. Light Coordination The work of two or more teams requires facilitation Local/remote team leaders must communicate often All team leaders can then pass on critical information FEEDBACK Customer feedback to developers is provided very quickly REPORTING Manual and automated status reporting FACILITATION Proactive management of intercultural dissonance TECHNICAL Coordination between local and remote technical leaders GOVERNANCE Lightweight governance teams with local and remote members LEADERSHIP Regular communications between local and remote process leaders CUSTOMER Regular communications between customers and remote teams Drummond, B. S., & Unson, J. F. (2008). Yahoo distributed agile: Notes from the world over. Agile Conference, Toronto, Canada, 315-321. 85
  • 86. Periodic Rotations Periodic F2F interaction is a CSF for virtual teams Teams should meet at critical junctures, i.e., kickoff Rotating customers and leaders helps establish trust ENDPOINTS Teams collocate at critical junctures, i.e., kickoff, middle, closeout, etc. DEVELOPMENT Teams periodically collocate for iterations PLANNING Teams collocate for release and iteration planning PERSONNEL Individuals rotate to maintain healthy relationships LEADERS Project leaders keep local and remote teams in-synch AMBASSADORS Ambassadors are exchanged to minimize intercultural dissonance CUSTOMERS Customer apprises remote teams of product vision, mission, goals, objectives, etc. Robarts, J. M. (2008). Practical considerations for distributed agile projects. Agile Conference, Toronto, Canada, 327-332. 86
  • 87. Regional Localization Minimizing interfaces between timezones is oft cited Products should be structured to localize activities It’s easier to communicate with nearshore teams DEVELOPMENT Subsystem interfaces are devised to localize development activities SOCIALIZATION Remote teams engage in social activities EMPOWERMENT Empower remote teams to make technical decisions MEETINGS Hold synchronous meetings at the local level LEADERS Empower local personnel to serve as process facilitators CUSTOMERS Empower local personnel to serve as customer proxies TIMEZONES Minimize organizational interfaces and organize teams by timezones Ramesh, B., Cao, L., Mohan, K., & Xu, P. (2006). Can distributed software development be agile? Communications of the ACM, 41(10), 41-46. 87
  • 88. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 88
  • 89. What is Kanban? Kan-ban (kæn-bæn): Signboard, billboard, signal cards; Lean, just-in-time system of production  A lean and just-in-time manufacturing process for regulating the flow of production based on demand  A pull-system philosophy of customized production vs. a push system of mass-market manufacturing  A set of principles for creating a lean, efficient, and waste-free product flow by limiting work-in-process  Use of simple organizational policy changes resulting in order-of-magnitude performance improvements  Framework for optimizing workflow that maximizes efficiency, product quality, and customer satisfaction Kniberg, H., & Skarin, M. (2010). Kanban and scrum: Making the most of both. Toronto, ON: C4 Media, Inc. Ladas, C. (2008). Scrumban: Essays on kanban systems for lean software development. Seattle, WA: Modus Cooperandi. Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 89
  • 90. Kanban Goals Kanban initially seeks to change as little as possible Change without resistance is the first Kanban goal Focus on improving quality, lead time and morale Goal 1 Optimize existing processes (rather than change them) Goal 2 Deliver high product quality (to build stakeholder trust) Goal 3 Reduce long lead times (and stabilize them) Goal 4 Achieve sustainable pace (work-life balance) Goal 5 Provide process slack (for process improvement) Goal 6 Simplify workload prioritization (of customer needs) Goal 7 Provide transparency (into design and operations) Goal 8 Strive for process maturity (to improve performance) Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 90
  • 91. Kanban Recipe for Success  Based on principles for product development flow  Uses operations and mathematical queue theory  Pragmatic operating principles for development Focus on Quality Reduce WIP Deliver Often Balance Demand Prioritize Attack Variability Walkthroughs  Process flowcharts  Short releases  Regulate inputs  Prioritize inputs  Work item size Inspections  Workflow analysis  Short increments  Identify bottlenecks  Business focus-  Work item type mix Technical reviews  Kanban boards  Short iterations  Create slack  Business value focus  Service class mix Peer reviews  Limit work tasks  Small releases  Limit work-in-process  Influence prioritization  Irregular flow Pair programming  Limit queues  Frequent releases  Create pull system  Stabilize process  Rework Test driven design  Limit buffers  Small batch sizes  Focus on precision  Build stakeholder trust  Ambiguous reqmnts. Continuous integration  Limit backlogs  Customer collaboration  Focus on quality  Perform risk analysis  Expedited requests Design patterns  Simple prioritization  Developer collaboration  Take pride in work  Analyze demand  Environment avail. Refactoring  Adequate resources  Ample communication  Improve morale  Evaluate size  Market fluctuations Design simplicity  Process automation  Frequent builds  Learn new skills  Evaluate complexity  Coordination Usability engineering  Policy statements  Deploy often  Obtain training  Market forecasting  Technological change Formal methods  Simplify process  Automatic updates  Continuously improve  Technology analysis  Skill/experience mix Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 91
  • 92. Value Stream Mapping Start by flow-charting the as-is product workflow Add buffers and queues one feels are necessary Add WIP limits to buffers, queues, and activity Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 92
  • 93. Work-in-Process High work-in-process leads to longest lead times Low work-in-process greatly reduces lead times Results in better customer trust and satisfaction Bad Project Good Project 175 240 140 192Features Features 105 144 70 96 35 48 0 0 10/9 10/23 11/6 11/20 12/4 12/18 1/1 1/15 1/29 2/12 2/26 2/10 2/17 2/24 3/2 3/9 3/16 Time Time Inventory Started Designed Coded Complete Inventory Started Designed Coded Complete Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 93
  • 94. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 94
  • 95. Basic Agile Proj. Mgt. Metrics Agile methods are based on traditional measures Size, effort, velocity, structure, and quality common Top-notch shops use satisfaction and business value Type Example Size Story Points, Ideal Days, Function Points, Lines of Code, etc. Effort Ideal or Actual Hours, Days, Weeks, Months, Years, etc. Velocity Release/Iteration Burndown/Burnup, Cumulative Flow, EVM, etc. Structure Object-Oriented, Relational Database, McCabe, Halstead, etc. Quality Running Tested Features, Defect Density, FURPS, MTBF, etc. Satisfaction CUPRIMDA, Communications, Trust, Loyalty, Retention, etc. Business Value Costs, Benefits, BEP, B/CR, ROI, NPV, IRR, ROA, EBV, etc. Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 95
  • 96. Burndown/Burnup Metrics Time expended is used for project tracking Tracked on a per iteration or per sprint basis Often described as a basic earned value metric Type Example Ideal Days How many days something takes without interruptions Actual Days How many days something takes with interruptions Ideal Hours How many hours something takes without interruptions Actual Hours How many hours something takes with interruptions User Stories How many customer requirements have been satisfied Story Points How many units of software size have been satisfied Technical Tasks How many technical tasks have been completed Cohn, M. (2006). Agile estimating and planning. Upper Saddle River, NJ: Pearson Education. 96
  • 97. Agile Cost Models Costs based on productivity and quality models Development costs based on LOC  productivity rate Maintenance costs based on defects  KLOC  MH Type Example Basic Form (LOC  Productivity + Quality  KLOC  100)  Hourly Rate XP (LOC  16.1575 + 0.7466  KLOC  100)  Hourly Rate TDD (LOC  29.2800 + 2.1550  KLOC  100)  Hourly Rate PP (LOC  33.4044 + 2.3550  KLOC  100)  Hourly Rate Scrum (LOC  05.4436 + 3.9450  KLOC  100)  Hourly Rate Agile (LOC  21.2374 + 1.7972  KLOC  100)  Hourly Rate Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 97
  • 98. Agile Business Value A major principle of Agile Methods is creating value ROI is the measure of value within Agile Methods There are seven closely related ROI measures Type Example Costs Total amount of money spent on agile methods Benefits Total amount of money gained from using agile methods Breakeven Point when the benefits of using agile methods exceed the costs B/CR Ratio of agile methods benefits to costs of using agile methods ROI Ratio of adjusted agile methods benefits to costs of using them NPV Present value of agile methods benefits that result from their use Real Options Value gained from incremental investments in high-risk projects Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 98
  • 99. Agile EVM EVM has been adapted to Agile Methods EVM based on notion that total scope is known EVM may “not” be well-suited for large agile projects Type Example PMB Total number of story points planned for a release SBL Total number of iterations multiplied by iteration length BAC The planned budget for the release PPC Number of current iterations divided by planned iterations APC Total story points completed divided by story points planned SPC Story points of work completed from backlog during iteration SPA Story points added/subtracted from backlog during iteration Sulaiman, T., Barton, B., & Blackburn, T. (2006). Agile EVM: Earned value management in scrum projects. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 7-16. 99
  • 100. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 100
  • 101. Extreme Programming Costs based on avg. productivity and quality Productivity ranged from 3.5 to 43 LOC an hour Costs were $136,551, benefits were $4,373,446 Metric Formula Value Costs (10,000 16.1575 0.7466 10 30) 100 $136,551 Benefits (10,000 .51 – 6,666.7 ) 100 – $136,551 $4,373,446 B/CR $4,373,446 $136,551 32:1 ROI ($4,373,446 – $136,551) $136,551 100% 3,103% NPV ( ($4,373,446 1.055) – $136,551 5 i 1 5) $3,650,396 BEP $136,551 ($4,509,997 $136,551 – 1) $4,263 NORMSDIST (8.07) $4,373,446 – ROA $4,267,100 NORMSDIST (7.59) $136,551 EXP (–5% 5) Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 101
  • 102. Test Driven Development Costs based on avg. productivity and quality Productivity ranged from 12 to 46 LOC an hour Costs were $249,653, benefits were $4,260,344 Metric Formula Value Costs (10,000 29.2800 + 2.1550 10 100) 100 $249,653 Benefits (10,000 10.51 – 6,666.67 9) 100 – $249,653 $4,260,344 B/CR $4,260,344 $249,653 17:1 ROI ($4,260,344 – $249,653) $249,653 100% 1,607% NPV ( ($4,260,344 1.055) – $249,653 5 i 1 5) $3,439,359 BEP $249,653 ($4,509,997 $249,653 – 1) $14,629 NORMSDIST(2.79) $4,260,344 – ROA $4,074,506 NORMSDIST(1.27) $249,653 EXP(–5% 5) Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 102
  • 103. Pair Programming Costs based on avg. productivity and quality Productivity ranged from 15 to 86 LOC an hour Costs were $265,436, benefits were $4,244,561 Metric Formula Value Costs (10,000 33.4044 + 2.3550 10 100) 100 $265,436 Benefits (10,000 10.51 – 6,666.67 9) 100 – $265,436 $4,244,561 B/CR $4,244,561 $265,436 16:1 ROI ($4,244,561 – $265,436) $265,436 100% 1,499% NPV ( ($4,244,561 1.055) – $265,436 5 i 1 5) $3,409,909 BEP $265,436 ($4,509,997 $265,436 – 1) $16,599 NORMSDIST(2.69) $4,244,561 – ROA $4,050,919 NORMSDIST(1.10) $265,436 EXP(–5% 5) Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 103
  • 104. Scrum Costs based on avg. productivity and quality Productivity ranged from 4.7 to 5.9 LOC an hour Costs were $578,202, benefits were $3,931,795 Metric Formula Value Costs (10,000 5.4436 + 3.9450 10 100) 100 $578,202 Benefits (10,000 10.51 – 6,666.67 9) 100 – $578,202 $3,931,795 B/CR $3,931,795 $578,202 7:1 ROI ($3,931,795 – $578,202) $578,202 100% 580% NPV ( ($3,931,795 1.055) – $578,202 5 i 1 5) $2,826,321 BEP $578,202 ($4,509,997 $578,202 – 1) $85,029 NORMSDIST(2.08) $3,931,795 – ROA $3,660,805 NORMSDIST(-0.15) $578,202 EXP(–5% 5) Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 104
  • 105. Agile Methods Costs based on avg. productivity and quality Productivity ranged from 3.5 to 86 LOC an hour Costs were $226,807, benefits were $4,283,190 Metric Formula Value Costs (10,000 21.2374 + 1.7972 10 100) 100 $226,807 Benefits (10,000 10.51 – 6,666.67 9) 100 – $226,807 $4,283,190 B/CR $4,283,190 $226,807 19:1 ROI ($4,283,190 – $226,807) $226,807 100% 1,788% NPV ( ($4,283,190 1.055) – $226,807 5 i 1 5) $3,481,988 BEP $226,807 ($4,509,997 $226,807 – 1) $12,010 NORMSDIST(2.99) $4,283,190 – ROA $4,110,305 NORMSDIST(1.59) $226,807 EXP(–5% 5) Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 105
  • 106. ROI of Agile Methods XP ROI 18X more than traditional methods Scrum ROI 3.4X more than traditional methods Agile methods ROI 10X more than trad. methods 3,700% 3,103% Return on Investment 2,775% 1,788% 1,850% 1,607% 1,499% 925% 580% 173% 0% XP Agile TDD PP Scrum CMMI® Software Method Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 106
  • 107. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 107
  • 108. Burndown Most basic tracking chart for agile projects Tracks number of work or time units completed Commonly used to track no. story points completed Burndown Chart Work (Story, Point, Task) or Effort (Week, Day, Hour) Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day) Rawsthorne, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA. 108
  • 109. Burnup Popular tracking chart for agile projects Tracks number of work or time units completed Basic form of cumulative workflow & overall progress Burnup Chart Work (Story, Point, Task) or Effort (Week, Day, Hour) Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day) Nicolette, D. (2009). Agile metrics. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA. 109
  • 110. Cumulative Flow (Trad. vs. Agile) High work-in-process leads to longest lead times Low work-in-process greatly reduces lead times Results in better customer trust and satisfaction Traditional vs. Agile Cumulative Flow Traditional Cumulative Flow Agile Cumulative Flow Work (Story, Point, Task) or Effort (Week, Day, Hour) Work (Story, Point, Task) or Effort (Week, Day, Hour) Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.) Anderson, D. J. (2004). Agile management for software engineering. Upper Saddle River, NJ: Pearson Education. Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press. 110
  • 111. Agile EVM Adaptation of EVM for agile projects Mapping between traditional and agile projects Work completed is more authoritative in agile projects Agile EVM Chart Work (Story, Point, Task) or Effort (Week, Day, Hour) CPI SPI PPC APC Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day) Sulaiman, T., Barton, B., & Blackburn, T. (2006). Agile EVM: Earned value management in scrum projects. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 7-16. 111
  • 112. Earned Business Value ROI is estimated for user stories in agile projects Value accrues with each completed user story Value of completed tasks is more meaningful Earned Business Value Work (Story, Point, Task) or Effort (Week, Day, Hour) Planning (Roadmap, Release, Iteration) or Time Unit (Month, Week, Day) Rawsthorne, D. (2010). Monitoring scrum projects with agile evm and earned business value metrics. Brisbane, CA: Collab.Net. 112
  • 113. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 113
  • 114. APM Tool Variety There are literally dozens, if not 100s of APM tools There are dozens of free open source software tools Annual tool & price surveys are frequently conducted VersionOne. (2010). 5th annual state of agile survey. Atlanta, GA: Author. 114 Allen, W. (2008). Agile PM tools (hosted). Retrieved May 11, 2011 from http://weblogs.asp.net/wallen.
  • 115. VersionOne One of the first APM tools created in 2003 Has about 36% of the marketshare for APM tools Free for small teams, but increases sharply thereafter Product Roadmapping Iteration Closeout Reviews    Roadmap Authoring  Sprint Reviews  Customization  Sprint Retrospectives  Collaboration  Issue and Action Item Tracking  Publishing  Backlog reconciliation Product Planning Tracking    Backlog Planning and Management  Sprint and Member Tracking  Epics, Goals, Themes, Feature Groups  Storyboard Wall  Customer Requests and Idea Management  Task Board and Test Board  Product Roadmapping Features  My Work and My Dashboard Release Planning Reporting and Analytics    Release Planning  Program Dashboard  Release Forecasting  Project Dashboard  Cross Project Planning and Scheduling  Iteration Dashboard  Regression Test Planning  Burnup/Burndown Reports Sprint Planning Other Features    High Level Sprint Planning  Agile Closeout Reviews  Detailed Sprint Planning  Test Management  Capacity Planning  Collaboration  Issue Management Features  Open Source Integration http://www.versionone.com 115
  • 116. Rally One of the first web-based APM tools created in 2004 Has about 20-30% of the marketshare for APM tools Also free for small teams and gets more expensive Agile Project Management Communication and Collaboration    High Level Roadmap Decomposition  Customizable Role Dashboards  Epic, Theme, and Feature Tracking  Rich Text, Email, and RSS Support  User Story Planning and Tracking  Social Media Style Interfaces  User Story Breakdown Management  Comments, Discussions, and IM Multi-Team Management Development Management    Organization Chart Mirroring  Requirements Management  Multi Level Project Hierarchies  Test Management  Common Progress and Status Views  Defect Management  Program, Feature, and Resource Rollup  Build and Source Code Traceability Release Planning Reporting    Step by Step Release Planning  Flexible Queries and Filters  Team Velocity Determination  Customer Tabular Graphical Reports  Release and Iteration Schedules  Burnup/Burndown Reporting, etc.  User Story Allocation to Iterations  User Generated Mashup Support Iteration Planning Product Management    Iteration Goal and Theme Support  Customer Feedback Management  Team Capacity Determination  Product Field Support  Backlog Item Prioritization  Demand Management  Task Creation, Estimation, and Tracking  CRM Integration and Support http://www.rallydev.com 116
  • 117. ScrumWorks Scrum project management tool created circa 2004 Similar size of user base to VersionOne and Rally Leadership in agile metrics and business value Product Management Real Time Custom Dashboards    Project Milestone Management  Velocity Charts  Epics for Project Scope Goals  Milestone Charts  Categorization using Themes  Cycle Time Charts  Business Weighting and ROI  Cross Product Status Reporting Program Management Data Accessibility    Coordination of Multiple Projects  Full Excel Import/Export  Manage and Track Overlapping Goals  Print to User Story Cards  Shared Component/System Modeling  Web Services API  High Level Feature Management  Backups and Notifications Iteration Management User Management    Drag and Drop Iteration Planning  Full Access Control  Team Task Board  Role Based Access Permissions  Sprint Task Tracking  Cross Site Role Templates  Impediment Tracking  Security Management Reporting and Analytics Integration    Release Date Forecasting  Commercial Environment Integration  Basic Burnup/Burndown Reporting  Open Source Environment Integration  Canned and Custom Report Generation  Issue and Defect Tracking Integration  Analysis of Planned vs. Actuals  Support for Tool Plugins http://www.danube.com 117
  • 118. ExtremePlanner XP project management tool created around 2004 Noted commercial tool for managing XP projects No free version, although it is moderately priced Multiple Project Support Test Management    Multiple Project Definition  Test Criteria Generation  Multiple Project Status Tracking  Test Case Generation and Capture  Multiple Project Report Generation  Test Case Initiation  Multiple Project Task Tracking  Test Status Reporting User Story Generation Integrated Issue Tracking    Cross Project Story Themes  Track Customer Support Requests  Create a Story from an Issue  Track Bug Reports  Theme and Story Template Reuse  Track Ad Hoc Suggestions  Inter Project Story Management  Transition Issues to User Stories Release Planning Report Generation    Capture User Stories Generated  Velocity and Task Tracking  Estimate and Prioritize User Stories  Iteration Burnup/Burndown Charts  View Schedule Stories for Releases  Cumulative Workflow Diagrams  View Estimated Effort for Releases  User Defined Reports Drag and Drop Iteration Planning Notification and Alerts    Iteration Generation and Management  Email Notifications  Drag and Drop User Story Management  Notification Capture and Management  Iteration Effort Estimation  Notification Viewing and Filtering  Iteration Status Reporting  User Selectable Notifications http://www.extremeplanner.com 118
  • 119. Mingle APM tool created by ThoughtWorks in late 2007 Extensible templates for multiple agile methods Growing user base that is free for small teams Program Management Test Management    Support for Multiple Projects  Visual Defect Workflows  Multi Project Status Tracking  User Story and Defect Traceability  Multi Project Report Generation  RSS and Email Test Alerting  Resource Allocation and Management  Wiki Support for Screenshots and Reports Project Management Project Collaboration    Multi Agile Method Support  Virtual Drag and Drop Card Walls  Customizable Dashboards  Integrated Wiki  Workflow Generators  RSS Feeds and Email Alerts  User Management and Access Control  Murmurs, Queues , and Comments Release and Iteration Planning Enterprise Support    Hierarchical Card Trees  Application Life Cycle Management  Prioritized Card Ranking  Integration with IDEs  User Story Searching and Recall  Integration with Versioning Tools  Global User Story Updating  Integration with Build/Deployment Tools Tracking and Reporting External Interfaces    Customizable Templates  I/O from Common Data Formats  Customizable Tabs, Favorites, and Views  Integration with External Databases  Advanced Filtering, Properties, and Tags  Integration with Workflow Tools  Burndown, Velocity, and Ad Hoc Reports  Integration with External Software http://www.thoughtworks-studios.com 119
  • 120. Target Process APM tool originally created for XP circa 2004 Now includes support Scrum, Lean, Kanban, etc. Also free for small teams and then price rises sharply Agile Planning and Tracking Quality Assurance    Backlog Management and Prioritization  Test Plan and Test Case Generation  Release and Iteration Planning  Automated Test Initiation  Task Boards and Personal To Do Lists  User Story/Test Case Traceability  Impediments and Blockage Management  Defect Tracking and Management Lean Development Reports and Dashboards    Value Stream Mapping  Customizable Dashboards  Kanban Boards  Release and Iteration Forecasting  Cumulative Workflow Diagrams  Release and Iteration Burndown Charts  Work in Process Limits  Task, User Story, and Iteration Progress Customization Collaboration    Customizable Development Process  Customizable Email Notifications  Customizable User Roles and Terminology  Content Sharing and Management  Customizable Navigation and Lists  Support for Multiple Content Types  Customizable Fields and Other Attributes  Integration with Synchronous Tools Integration Product Support    Web Services API  Customer Help Desk Portal  Visual Studio and Eclipse IDE Integration  Ideas and Issues Tracking  Subversion, Bugzilla, JUnit, and Selenium  Bug Reports Traceable to User Stories  Single Sign On Support  Full Customer Email Integration http://www.targetprocess.com 120
  • 121. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 121
  • 122. Agile Contracting Models New contract models emerged for agile contracts Goals, objectives, and visions are established early Buyers and suppliers collaborate throughout contract Contract Type Description Dynamic Value Specify initial scope and needs (with iterative enhancements) Performance Based Establish performance objectives (but not technical solutions) Target Cost Broad boundaries for time, cost, and quality (but not scope) Optional Scope Set minimum and maximum costs (based on initial scope) Collaborative Outline initial scope (with fixed no. of releases and iterations) Lean Lean tools such as small batches, Kanban, WIP constraints, etc. Rico, D. F. (2011). The necessity of new contract models for agile project management. Fairfax, VA: Gantthead.Com. 122
  • 123. Performance Based Acquisition Developed by U.S. DoD in the 2000 timeframe Born out of radical acquisition reforms of 1990s Focuses on objectives and outcomes vs. process Performance Based Services Acquisition Integrated Solutions Team Problem Statement Private and Public Solutions  Ensure management involvement  Link acquisition to strategic roadmap  Team approach to market research  Tap multi disciplinary expertise  Link acquisition to mission objectives  Learn from public sector  Define roles and responsibilities  Link acquisition to performance goals  Consult with private sector firms  Develop rules of conduct  Define desired results at a high level  One on one industry meetings  Empower and incentivize team  Decide what constitutes success  Look for existing contracts  Identify stakeholders  Determine current performance level  Document market research Statement of Objectives Measure Performance Select Contract Manage Performance  Elevator message  Success determinants  Compete the solution  Keep the team together  Describe the scope  Quality standards  Oral presentations  Roles and responsibilities  Performance objectives  Proposed metrics  Past performance  Assign accountability  Share objectives  Meaningful measures  Best value evaluation  Formal kick off meeting  Identify the constraints  Contractual language  Final source selection  Performance based mgt  Develop the background  Order of precedence  Conflict of interest  Review performance Gansler, J. S. (2000). Guidebook for performance based services acquisition in the U.S. DoD. Washington, DC: Author. Sade, M. (2009). Seven steps to performance based services acquisition. Washington, DC: General Services Administration. 123
  • 124. Target Cost Concept attributed to Toyota Production System Adapted for agile project management in 2005 Good balance of structure, flexibility, & trust Target Cost Contract Scope Statement Statement of Work Master Agreement Release Plan Closeout  Business vision  Development days  Non -disclosure terms  Feature priorities  Acceptance test  System metaphor  Support estimate  Product ownership  Wireframes  Final documentation  User stories  Contingency  Indemnification terms  Development tasks  Document handover  Effort estimate  Cost estimate  Non-compete terms  Task effort  Deployment testing  Priorities  Fixed profit  Administration  Iteration plan  Joint evaluation  Roadmap  Total cost estimate  Termination terms  Workflow tool  Administrative close Development Iterations, Sprints, or Increments Change Management  Perform daily standup meetings  Perform customer demonstration  Develop acceptance and unit tests  Solicit feedback from client  Create or refactor software code in pairs  Classify and categorize feedback  Check-in code and perform unit testing  Negotiate scope changes with client  Perform continuous integration  Update letter of agreement (LOA)  Hold iteration retrospective  Update release and iteration plans Support Processes  Security engineering, user experience design, software certification testing, quality assurance, configuration management, etc.Eckfeldt, B., Madden, R., & Horowitz, J. (2005). Selling agile: Target cost contracts. Proceedings of the Agile Conference (Agile 2005), Denver, Colorado, USA, 160-166. 124
  • 125. PS2000 for Agile Developed by Norwegian Computer Society Adapted for IT, incremental, and agile methods Upfront scoping similar to Feature Driven Design PS2000 Agile Contract Needs Phase Solution Description Phase Approval and Completion Phase  Perform needs analysis  Develop high level prototypes  Perform acceptance testing  Develop uncertainty matrix Sign  Develop architecture and design  Perform quality certification  Analyze top level risks areas Contract  Establish development priorities  Deliver final documentation  Identify development environment  Prepare description of solution  Perform joint project evaluation  Prepare milestones and schedules  Verify solution description  Perform limited maintenance Approve Prepare Solution Delivery Iterative Construction Detailed Planning Product Development and Verification Testing and Debugging  Analyze needs and solution description  Document development methods and tools  Prepare test plans and specifications  Develop detailed iteration plan  Develop prototypes and components  Perform detailed component testing  Develop detailed specifications  Demonstrate prototypes and components  Perform integration and system testing  Develop detailed design models  Gather customer or end user feedback  Monitor, log, and remediate defects  Verify detailed design  Perform verification and quality assurance  Perform quality and reliability modeling Checkpoints, Beta Testing, and Other Services  Configuration management, iteration retrospectives, checkpoint progress reviews, re-planning and mid-course corrections, training, etc. Norwegian Computer Society. (2010). PS2000 standard contract for agile software development. Oslo, Norway: Author. 125
  • 126. Evolutionary Acquisition Idea originated from Barry Boehm in 1985 Adapted to U.S. DoD acquisitions in 1999/2000 Incrementally insert emerging technology into acq. Evolutionary Acquisition MDD 6 Months MDD 12 Months MDD 18 Months MDD 24 Months MDD 30 Months Material Increment 1 Increment 2 Increment 3 Increment 4 Increment 5 Solution Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Analysis Technology Strategy Technology Strategy Technology Strategy Technology Strategy Technology Strategy A1 A2 A3 A4 Increment 1 Increment 2 Increment 3 Increment 4 Technology Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Development System Prototype System Prototype System Prototype System Prototype B1 B2 B3 Increment 1 Increment 2 Increment 3 Engineering & Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Manufacturing Finished System Finished System Finished System CDR C1 CDR C2 CDR Increment 1 Increment 2 Production & Spiral 1 Spiral 2 Spiral 3 Spiral 1 Spiral 2 Spiral 3 Deployment LRIP LRIP FDR IOC FDR Increment 1 Operations & Spiral 1 Spiral 2 Spiral 3 Support FRPS FOC Ford, D. N., & Dillard, J. (2009). Modeling the performance an risks of evolutionary acquisition. Defense Acquisition Review Journal, 16(2), 143-158. 126
  • 127. Lean & Agile Acquisition Originated from agile methods popularity in 2002 Gained foothold in U.S. DoD with Scrum popularity Front loads acquisition process with early deliveries Lean & Agile Acquisition Material Technology Engineering & Production & Operations & Solution Development Manufacturing Deployment Support Analysis 6 months 12 months 18 months 24 months 30 months Release 1 Release 2 Release 3 Release 4 Release 5 Program 1 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Operational Capability Operational Capability Operational Capability Operational Capability Operational Capability MDD A1 B1 CDR C1 FDR FRP IOC FOC Release 1 Release 2 Release 3 Release 4 Release 5 Program 2 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Operational Capability Operational Capability Operational Capability Operational Capability Operational Capability MDD A2 B2 CDR C2 FDR FRP IOC FOC Release 1 Release 2 Release 3 Release 4 Release 5 Program n Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Sprint 0 Sprint 3 Sprint 6 Operational Capability Operational Capability Operational Capability Operational Capability Operational Capability MDD A3 B3 CDR C3 FDR FRP IOC FOC Reagan, R. B., & Rico, D. F. (2010). Lean and agile acquisition and systems engineering: A paradigm whose time has come. Defense AT&L Magazine, 39(6), 48-52. 127
  • 128. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 128
  • 129. Diffusion of Innovations Idea originated with Everett Rogers in 1962 A few early adopters will embrace a new idea The majority will resist change for a longer time Diffusion of Innovations Diffusion Early Early Late Innovators Laggards Adopters Majority Majority Rogers, E. (2003). Diffusion of innovations. New York, NY: Free Press. 129
  • 130. Crossing the Chasm Idea originated with Geoffrey Moore in 1991 Time between adoption phases is not uniform Large gap between early adopters and majority Crossing the Chasm Diffusion Early Early Late Innovators Laggards Adopters Majority Majority Moore, G. A. (2002). Crossing the chasm: Marketing and selling high tech products to mainstream customers. New York, NY: HarperCollins. 130
  • 131. Virginia Satir Model Idea originated with Virginia Satir in 1980s Large changes plunge organizations into chaos Depth and length of chaos is related to its magnitude Virginia Satir Model Productivity Status New Resistance Chaos Recovery Quo State Satir, V., Banmen, J., Gerber, J., & Gomori, M. (1991). The satir model: Family therapy and beyond. Palo Alto, CA: Science and Behavior Books. 131
  • 132. Incremental Change Large change, no matter how good, often fails Goal is to break changes into smaller increments Smaller and imperceptible change is more successful Incremental Change Productivity Status Resist- Reco- New Status Resist- Reco- New Status Resist- Reco- New Chaos Chaos Chaos Quo stance very State Quo ance very State Quo ance very State Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications. 132
  • 133. Organizational Change Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation are key factors How to Cross the Chasm Switch How to Change Things When Change is Hard Influencer The Power to Change Anything Direct the Rider Make the Undesirable Desirable  Create new experiences - Make it interesting  Follow the bright spots - Clone what works  Create new motives - Appeal to sensibility  Script the critical moves - Use prescriptive behaviors  Point to the destination - Focus on the end game Surpass your Limits  Perfect complex skills - Establish milestones  Build emotional skills - Build maturity and people skills Motivate the Elephant Harness Peer Pressure  Recruit public personalities - Involve public figures  Find the feeling - Appeal to emotion  Recruit influential leaders - Involve recognized figures  Shrink the change - Use incremental change  Grow your people - Invest in training and education Find Strength in Numbers  Utilize teamwork - Enlist others to help out  Enlist the power of social capital - Scale up and out Shape the Path Design Rewards and Demand Accountability  Use incentives wisely - Reward vital behaviors  Tweak the environment - Simplify the change  Use punishment sparingly - Warn before taking action  Build habits - Create simple recipes for action  Rally the herd - Get everyone involved Change the Environment  Make it easy - Simplify the change  Make it unavoidable - Build change into daily routine Heath, C., & Heath, D. (2010). Switch: How to change things when change is hard. New York, NY: Random House. Patterson, K., et al. (2008). Influencer: The power to change anything: New York, NY: McGraw-Hill. 133
  • 134. Organization Change Methods Top down big bang change is most often tried Punctuated equilibrium is most well known form Project champions and coaching are very effective Organization Change Methods Punctuated Equilibrium One time radical organizational change often motivated by a severe crisis, i.e., crisis is a catalyst for change Personal Influence Informal appeal for authority to change based on personal trust or relationships, i.e., elevator speech Business Case Compelling qualitative and quantitative business value analysis, i.e., return on investment analysis Executive Coaching Formal or informal mentoring or tutoring of organizational executives and senior leaders Executive Commitment A personal endorsement for change from an organizational executive or senior leader Adequate Resources Formal allocation of resources to execute a large organizational change initiative Top Down Change One time organization change initiative based on a formal strategic plan, i.e., big bang organization change Model Driven Change Isolated change initiatives based on step by step frameworks, i.e., PDCA, DMAIC, DMADV, etc. Manager Involvement Psychological involvement and commitment of middle managers to avoid bureaucratic obfuscation Employee Involvement Psychological involvement and commitment of lower level workforce to avoid operational resistance Training & Education Formal classroom instruction and education to impart the skills necessary for successful change Evolutionary Change The implementation of numerous smaller scale changes to prevent long term psychological resistance and chaos Project Champion Formal appointment of an individual to take personal responsibility for success of change, i.e., heavyweight PM Coaching & Mentoring Formal or informal mentoring or tutoring of employees or team members to help them overcome hidden obstacles Just Do It Assuming personal responsibility for change with or without formal authorization, i.e., forgiveness vs. permission Holman, P., Devane, T., & Cady, S. (2007). The change handbook: The definitive resource on today’s best methods for emerging whole systems. Berrett-Koehler. 134
  • 135. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 135
  • 136. E-Commerce—Google Google started using agile methods in 2005 Used it on one of their most profitable products Incrementally adopted agile one practice at a time Project Name AdWords Project Type Pay-per-Click (PPC) Internet Advertising Mechanism Project Size 20 teams of 140 people distributed over 5 countries Product Size 1,838 user stories, 6,250 function points, 500,000 lines of code Environment Entrepreneurial, egalitarian, dynamic, unpredictable, informal, unstructured Before APM Chronic schedule delays, poor quality, unpredictability, poor estimation APM Practices Release planning, wikis for APM support, early testing and continuous integration After APM Better planning and estimates, earlier testing, better quality, large-scale adoption Lessons Learned Agile fit like a hand-in-glove, introduce agile methods slowly and then scale-up Striebeck, M. (2006). Ssh: We are adding a process. Proceedings of the Agile 2006 Conference (Agile 2006), Minneapolis, Minnesota, USA, 193-201. 136
  • 137. Shrink-Wrapped—Primavera Primavera started using agile methods in 2004 Used it on their flagship project management tools Adopted agile all-at-once with top down mgt. support Project Name Primavera Project Type Enterprise Project Management Tool Project Size 15 teams of 90 people collocated at one site Product Size 26,809 user stories, 91,146 function points, 7,291,666 lines of code Environment Top-down, hierarchical, command and control, traditional, waterfall approach Poor relationships, quality, usability, and customer satisfaction, functional silos, Before APM 18-hour days, 7-day work weeks, frustration, disappointment, apathy, exhaustion APM Practices Release planning, agile project management tools, automated testing tools After APM 75% quality and 40% cycle time improvement, 40-hour work week, 0% attrition Lessons Learned Agile results in better communication, motivation, and empowerment Schatz, B., & Abdelshafi, I. (2005). Primavera gets agile: A successful transition to agile development. IEEE Software, 22(3), 36-42. 137
  • 138. Healthcare—FDA FDA suppliers started using agile methods in 2008 Used it on most stringent Class 3 certified products Used to modernize 1990s era products & processes Project Name m2000 Real-time PCR Diagnostics System Project Type Human Blood Analysis Tool (i.e., HIV-1, HBV, HCV, CT, NG, etc.) Project Size 4 teams of 20 people collocated at one site Product Size 1,659 user stories, 5,640 function points, 451,235 lines of code Environment FDA-regulated medical devices, real-time, safety-critical, Class III–most stringent Cumbersome process, poor quality, long cycle time, slow big-bang integration, obsolete, Before APM hard-to-staff tools and methods, inability to keep pace with changing requirements, Intense market competition, exponential rate of technological change, fewer resources APM Practices Release planning, lighter-weight agile testing techniques, continuous integration After APM 25% cycle time and staff-size reduction, 43% cost reduction, fewer defects Lessons Learned Agile enables the ability to balance fast cycle time with high-quality safety-critical solutions Rasmussen, R., Hughes, T., Jenks, J. R., & Skach, J. (2009). Adopting agile in an FDA regulated environment. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 151-155. 138
  • 139. Law Enforcement—FBI IC started using agile methods following 9/11 Used it on billion dollar transformation initiatives Goal is to catch bad guys better, faster, and cheaper Project Name Inter-Agency Intelligence Sharing System Project Type Domestic Terrorist Database/Data Warehouse Project Size 3 teams of 12 people collocated at one site Product Size 643 user stories, 2,188 function points, 175,000 lines of code CMMI Level 3, ISO 9001, government-mandated document-driven waterfall life cycle, Environment emerging federal directives for more information sharing and integration among intelligence community partners, rapidly changing customer requirements Unresponsive waterfall life cycles, chronic schedule delays, anxious customers, unhappy Before APM developers, resource focus on becoming CMMI Level 3 certified caused everyone to lose track of the real goal, which was to “catch bad guys” APM Practices Release planning, user stories, test-driven development, continuous integration After APM 50% quality improvement, 200% productivity increase, FBI created policy for agile methods Lessons Learned Agile enables fast response times, customer satisfaction, and ability to "catch bad guys" Babuscio, J. (2009). How the FBI learned to catch bad guys one iteration at a time. Proceedings of the Agile 2009 Conference (Agile 2009), Chicago, Illinois, USA, 96-100. 139
  • 140. U.S. DoD—STRATCOM U.S. DoD started using agile methods following 9/11 Used it on billion dollar software intensive systems Goals are to respond to rapidly emerging threats Project Name Strategic Knowledge Integration Website (SKIweb) Project Type Knowledge Management System (KMS)—Advanced Search Capability Project Size 3 teams of 12 people collocated at one site Product Size 390 user stories, 1,324 function points, 105,958 lines of code Traditional linear documentation-based development, contract-oriented, hierarchical communication, rapidly changing operational requirements, need for leaner U.S. military Environment force, seeking better and faster ways of getting critical information to decision makers, decentralization, migration to net-centric service oriented architectures, egalitarian decisions Before APM Long cycle times, dissatisfied customers, unresponsive life cycles, poor quality APM Practices Release planning, frequent customer collaboration, continuous integration After APM Good teamwork, 200% productivity increase, improved quality, fewer defects Lessons Learned Agile improves customer satisfaction/communication, and overall product quality Fruhling, A., McDonald, P, & Dunbar, C. (2008). A case study: Introducing extreme programming in a U.S. government system development project. Proceedings of the 41st Annual Hawaii International Conference on System Sciences (HICSS 2008), Waikaloa, Big Island, Hawaii, USA, 464-473. 140
  • 141. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 141
  • 142. 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 142
  • 143. Advanced Agile Measures Agile Methods are a fundamentally new paradigm Agile Methods are “not” lighter Traditional Methods They should not be viewed through a traditional lens Traditional Metrics Customer Collaboration Contracts  Interaction frequency  Customer trust valued  Contract compliance  Comm. quality  Customer loyalty more than  Contract deliverablesAgile Metrics  Relationship strength  Customer satisfaction  Contract change orders Individuals & Interactions Processes  Team competence  Team trust valued  Lifecycle compliance  Team motivation  Team cohesion more than  Process Maturity Level  Team cooperation  Team communications  Regulatory compliance Working Software Documentation  Batch/queue size  Experimental willingness valued  Document deliveries  WIP/WIP constraints  Risk/failure threshold more than  Document comments  Cadence/iterations  Feedback/criticism thresh.  Document compliance Responding to Change Project Plans  Org. flexibility  Process flexibility valued  Cost Compliance  Mgt. flexibility  Design flexibility more than  Scope Compliance  Individual flexibility  Technology flexibility  Schedule Compliance Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods: Maximizing ROI with just-in-time processes and documentation. Ft. Lauderdale, FL: J. Ross Publishing. 143
  • 144. Agile Teamwork Model A key element of any project is good teamwork Agile projects depend upon teamwork even more Balance between cohesion & out-of-the-box thinking Factor Attributes Leadership Credible, experienced, likeable, & nurturing project champion Boundaries Clear vision, mission, goals, & objectives Empowerment Adequate time, money, tools, & authority Competence Applicable skills, knowledge, experience, & personality Structure Clear roles, responsibilities, technical approach, & operating rules Manageability Small, collaborative, cohesive, & frequently-communicating Motivation Compensation, incentives, desire-to-succeed, & consequences Rico, D. F. (2011). The key attributes and factors of teams and teamwork for agile project management. Fairfax, VA: Gantthead.Com. 144
  • 145. Agile UX—User Experience Design User experience is key ingredient to success UX should be included throughout agile life cycle UX involves end to end product & service experience Product Owner Agile UX Development Define Product Vision & Define Build Build Strategy User Needs User Experience Product  Competitive Analysis  User Interviews  GUI Implementation  Front End Code  Define Feature Set  Contextual Inquiry  Core Capabilities  Back End Code  Quantify Business Value  User Flows  Core Services  Database Schema  Prioritization  Wireframes & Mockups  Value Adding Capabilities  Technology Selection  Define Business Rules  Prototyping  Value Adding Services  Usability Testing  Pricing & Budgeting  Usability Testing  Distributed Framework  User Experience Testing  Project Accountability  Web Metrics Analysis  Central Framework  Market Testing  Partnerships & Licensing  User Feedback  Support Services  Overall Product Evaluation Johnson, J. D. (2010). Agile UX retreat: We should value competencies over roles. Retrieved April 22, 2011 from http://www.jeremydjohnson.com/index.php/2010/03 Kollmann, J., Sharp, H., & Blandford, A. (2009). The importance of identity and vision to user experience designers on agile projects. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 11-18. 145
  • 146. Myths about Agile Proj. Mgt. Common myths abound, although agile methods have been around for ~20 years:  Agile methods are only for software development  Agile methods are only for small co-located teams  Agile methods have no documentation  Agile methods have no requirements  Agile methods need traditional system architectures  Agile methods have no project management  Agile methods are undisciplined and unmeasurable  Agile methods create unmaintainable systems  Agile methods result in security vulnerabilities 146
  • 147. Agile Documentation Myth that voluminous documentation is needed Myth that agile methods do not use documentation Right sized, just in time, and just enough documents Document Type Agile Documentation Contracts Performance, target cost, agile contract, lean acquisition Project Plans Release plans, iteration plans, kanban boards, workflow tools Requirements Vision, mission, capabilities, scope, user stories, use cases Architecture Metaphors, story boards, system modeling language, spikes Design Wire frames, design patterns, unified modeling language Coding Code patterns, program design language, coding comments Tests Unit, component, integration, system, and acceptance tests User guides XML documents, online help, wikis, FAQs, video & audio clips Quality Assurance Code structure, defects, running tests, reliability, performance Rico, D. F. (2008). Agile methods and software documentation. Retrieved April 21, 2011 from http://davidfrico.com/rico08e.pdf Rueping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, England: John Wiley & Sons. 147
  • 148. Conclusion  Agility is the evolution of management thought  Confluence of traditional and non-traditional ideas  Improve performance by over an order of magnitude Agile project management is …  A systems development approach  New product development approach  Expertly designed to be fast and efficient  Intentionally lean and free of waste (muda)  Systematic highly-disciplined approaches  Capable of producing high quality systems  Right-sized, just-enough, and just-in-time tools  Scalable to large, complex mission-critical systems  Designed to maximize business value for customers “The world of traditional project management belongs to yesterday”“Don’t waste your time using traditional project management on 21st century projects” Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education. 148
  • 149. Agenda• Motivation • Virtual Teams• Introduction • Lean/Kanban• Business Case • Metrics and Models• Major Approaches • Costs and Benefits• Major Phases • Earned Value Mgt.• Release Planning • Major Tools• Iteration Planning • Contract Models• Estimating Practices • Change Models• Risk Analysis • Case Studies• Security Engineering • Summary• Scaling Practices • Resources 149
  • 150. APM Textbooks I Over 15 text books for agile project management Many of them stem from Planning XP by Kent Beck Agile Project Mgt. by Jim Highsmith is most complete Beck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley. Schwaber, K. (2004). Agile project management with scrum. Redmond, WA: Microsoft Press. Highsmith, J. A. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education. DeCarlo, D. (2004). Extreme project management: Using leadership, principles, and tools to deliver value in the face of volatility. San Francisco, CA: Jossey-Bass. Wysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education. 150
  • 151. APM Textbooks II Many other Agile Project Management books Good background on Agile Project Management Newer Agile Project Management books emerging Chin, G. L. (2004). Agile project management: How to succeed in the face of changing project requirements. New York, NY: Amacom. Aguanno, K. (2005). Managing agile projects. Lakefield, Ontario, Canada: Multi-Media Publications. Pries, K. H., & Quigley, J. M. (2010). Scrum project management. Boca Raton, FL: CRC Press. Augustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education. Sliger, M., & Broderick, S. (2008). The software project managers bridge to agility. Boston, MA: Addison-Wesley. 151
  • 152. APM Textbooks III Project management books continuing to emerge Project management becoming dominant paradigm Some are from popular project management authorsWysocki, R. K. (2009). Effective project management: Traditional, agile, and extreme. Indianapolis, IN: Wiley.Anderson, D. J. (2004). Agile management for software engineering: Applying the theory of constraints for business results. Upper Saddle River, NJ: Pearson Education.Goodpasture, J. C. (2010). Project management the agile way: Making it work in the enterprise. Ft. Lauderdale, FL: J. Ross Publishing.Cobb, C. G. (2011). Making sense of agile project management: Balancing control and agility. Hoboken, NJ: John Wiley & Sons.Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing. 152
  • 153. Scaling Agile Methods Scaling is the new frontier in Agile Methods research Many of them stem from Planning XP by Kent Beck Books emerging on global distributed agile teams Woodward, E., Surdek, S., & Ganis, M. (2010). A practical guide to distributed scrum. Indianapolis, IN: IBM Press. Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education. Schiel, J. (2010). Enterprise-scale agile software development. Boca Raton, FL: CRC Press. Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley. Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley. 153
  • 154. Agile Organization Change Agile methods are one of the newest innovations Organizational change is a major obstacle for agile Many books emerging to help manage agile adoption Appelo, J. (2011). Management 3.0: Leading agile developers and developing agile leaders. Boston, MA: Pearson Education. Cohn, M. (2010). Succeeding with agile: Software development using scrum. Boston, MA: Pearson Education. Elssamadisy, A. (2009). Agile adoption patterns: A roadmap to organizational success. Boston, MA: Pearson Education. Coplien, J. O., & Harrison, N. B. (2004). Organizational patterns of agile software development. Upper Saddle River, NJ: Prentice-Hall. Smith, G., & Sidky, A. (2009). Becoming agile: In an imperfect world. Greenwich, CT: Manning Publications. 154
  • 155. Agile Development 100s of agile methods books exist for all disciplines Range from requirements through documentation Thwart notion that agile methods have big gaps Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education. Coplien, J. O., & Bjornvig, G. (2010). Lean architecture: For agile software development. West Sussex, UK: John Wiley & Sons. Martin, R. C. (2008). Clean code: A handbook of agile software craftsmanship. Upper Saddle River, NJ: Prentice-Hall. Crispin, L., & Gregory, J. (2009). Agile testing: A practical guide for testers and agile teams. Boston, MA: Addison-Wesley. Ruping, A. (2003). Agile documentation: A pattern guide to producing lightweight documents for software projects. West Sussex, UK: John Wiley & Sons. 155

×