Enterprise Frameworks

Transcription

1 Lean & Agile Enterprise Frameworks For Managing Large U.S. Gov t Cloud Computing Projects Dr. David F. Rico, PMP, CSEP, ACP, CSM, SAFe Website: LinkedIn: Facebook: Agile Capabilities: Agile Resources: Agile Cheat Sheet:

2 Author Background Gov t contractor with 32+ 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 Career systems & software engineering methodologist Lean-Agile, Six Sigma, CMMI, ISO 9001, DoD 5000 NASA, USAF, Navy, Army, DISA, & DARPA projects Published seven books & numerous journal articles Intn l keynote speaker, 100+ talks to 11,000 people Adjunct at GWU, UMBC, UMUC, Argosy, & NDMU Specializes in metrics, models, & cost engineering Cloud Computing, SOA, Web Services, FOSS, etc. 2

3 Today s Whirlwind Environment Work Life Imbalance Vague Requirements Technology Change Global Competition Overruns Attrition Escalation Runaways Cancellation System Complexity Demanding Customers Organization Downsizing 81 Month Cycle Times Redundant Data Centers Reduced IT Budgets Obsolete Technology & Skills Inefficiency High O&M Lower DoQ Vulnerable N-M Breach Lack of Interoperability Overburdening Legacy Systems Poor IT Security Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press. Pontius, R. W. (2012). Acquisition of IT: Improving efficiency and effectiveness in IT acquisition in the DoD. Second Annual AFEI/NDIA Conference on Agile in DoD, Springfield, VA, USA. 3

4 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 % 41% 26% $1.8 Year % 44% 24% 35% 46% 19% 29% 53% 18% 34% 51% 15% 28% 49% 23% 26% 46% 28% 27% 33% 40% Trillions (US Dollars) $1.4 $1.1 $0.7 $ % 53% 31% 0% 20% 40% 60% 80% 100% Successful Challenged Failed $ Expenditures Failed Investments Standish Group. (2010). Chaos summary Boston, MA: Author. Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch. 4

5 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 Requirements 47% Never 45% Other 7% Always 7% Implementation 18% Design 28% Often 13% Sometimes 16% Rarely 19% Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy. 5

6 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 BUSINESS VALUE with right sized, justenough, and just-in-time processes and documentation Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley. 6

7 What are Agile Methods? People-centric way to create innovative solutions Product-centric alternative to documents/process Market-centric model to maximize business value Frequent comm. Close proximity Regular meetings Customer Collaboration Multiple comm. channels Frequent feedback Relationship strength valued more than Contracts Contract compliance Contract deliverables Contract change orders Individuals & Interactions Leadership Competence Courage Boundaries Structure Empowerment Manageability/Motivation valued more than Processes Lifecycle compliance Process Maturity Level Regulatory compliance Working Systems & Software Clear objectives Small/feasible scope Acceptance criteria Timeboxed iterations Valid operational results Regular cadence/intervals valued more than Documentation Document deliveries Document comments Document compliance Org. flexibility Mgt. flexibility Process flexibility Responding to Change System flexibility Technology flexibility Infrastructure flexibility valued more than Project Plans Cost Compliance Scope Compliance Schedule Compliance Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing. Rico, D. F. (2012). Agile conceptual model. Retrieved February 6, 2012, from 7

8 How Agile Works Agile requirements implemented in slices vs. layers User needs with higher business value are done first Reduces cost & risk while increasing business success Agile Traditional Faster Early ROI Lower Costs Fewer Defects Manageable Risk Better Performance Smaller Attack Surface JIT, Just-enough architecture Early, in-process system V&V Fast continuous improvement Scalable to systems of systems Maximizes successful outcomes MINIMIZES GUI APIs Applications Middleware Operating System Computer Network Seven Wastes 1. Rework 2. Motion 3. Waiting 4. Inventory 5. Transportation 6. Overprocessing 7. Overproduction MAXIMIZES Late No Value Cost Overruns Very Poor Quality Uncontrollable Risk Slowest Performance More Security Incidents Myth of perfect architecture Late big-bang integration tests Year long improvement cycles Breaks down on large projects Undermines business success Shore, J. (2011). Evolutionary design illustrated. Norwegian Developers Conference, Oslo, Norway. 8

9 Agile Development In-the-Large Incremental Business Value Organize needs into capabilities, features, and stories Prioritize features, group releases, and initiate sprints Develop minimum set of features with highest value (for example, assume 25 user stories per feature, 175 user stories per capability/mmf, and 1,225 user stories total) Capability/MMF #1 Capability/MMF #2 Capability/MMF #3 Capability/MMF #4 Capability/MMF #5 Capability/MMF #6 Capability/MMF #7 Feature 1 Feature 2 Feature 3 Feature 4 Feature 5 Feature 6 Feature 7 Release Feature 8 Feature 9 Feature 10 Feature 11 Feature 12 Feature 13 Feature 14 Release Feature 15 Feature 16 Feature 17 Feature 18 Feature 19 Feature 20 Feature 21 Feature 22 Feature 23 Feature 24 Feature 25 Feature 26 Feature 27 Feature 28 Feature 29 Feature 30 Feature 31 Feature 32 Feature 33 Feature 34 Feature 35 Release Feature 36 Feature 37 Feature 38 Feature 39 Feature 40 Feature 41 Feature 42 Feature 43 Feature 44 Feature 45 Feature 46 Feature 47 Feature 48 Feature 49 Release Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 A A B Evolving Unified/Integrated Enterprise Data Model A A A B C B C B C D D E Legacy MS SQL Server Stovepipes Inter-Departmental Linux Blade/Oracle/Java/WebSphere Server Leased DWA/HPC/Cloud Services A A B C B C D E F D E F G H I J K ETL ETL ETL ETL ETL ETL ETL Disparate LEGACY SYSTEM DATABASES (AND DATA MODELS) Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture: Enriching EA with lean, agile, and enterprise 2.0 practices. Waltham, MA: Elsevier. 9

10 Agile for EMBEDDED SYSTEMS 1st-generation systems used hardwired logic 2nd-generation systems used PROMS & FPGAs 3rd-generation systems use APP. SW & COTS HW Iterations, Integrations, & Validations AGILE Software Model -MOST FLEXIBLE - Short Lead Least Cost Lowest Risk 90% Software COTS Hardware Early, Iterative Dev. Continuous V&V NEO-TRADITIONAL FPGA Model -MALLEABLE - Moderate Lead Moderate Cost Moderate Risk 50% Hardware COTS Components Midpoint Testing Some Early V&V TRADITIONAL Hardwired Model -LEAST FLEXIBLE - Long Lead Highest Cost Highest Risk 90% Hardware Custom Hardware Linear, Staged Dev. Late Big-Bang I&T RISK Embedded Systems More HW Than SW START Competing With SW GOAL SHIFT FROM LATE HARDWARE TO EARLIER SOFTWARE SOLUTION Pries, K. H., & Quigley, J. M. (2010). Scrum project management. Boca Raton, FL: CRC Press. Pries, K. H., & Quigley, J. M. (2009). Project management of complex and embedded systems. Boca Raton, FL: Auerbach Publications. Thomke, S. (2003). Experimentation matters: Unlocking the potential of new technologies for innovation. Boston, MA: Harvard Business School Press. STOP Competing With HW 10

11 Rank Database Year Creator Firm Goal Model Lang I/F Focus Example User Rate KPro Agile for CLOUD COMPUTING 1st-generation systems used HPCs & Hadoop 2nd-generation systems used COTS HW & P2P 3rd-generation systems use APP. SW & COTS HW MongoDB Cassandra Redis HBase Elastic Search Steve Francia 10gen Avinash Lakshman Facebook 2009 Salvatore Sanfilippo Document C++ BSON Large-scale Web Apps Wide Column Pivotal Speed Key Value C Binary Mike Carafella Powerset Scale Wide Column Shay Banon Java CQL Fault-tolerant Data Stores Java Compass Search Document Java REST Real-time Messaging REST Petabyte-size Data Stores Full-text Search CRM Expedia 45% 48 Rapid-prototyping, Queries, Indexes, Replication, Availability, Load-balancing, Auto-Sharding, etc. Mission Critical Data itunes 20% 15 Distributed, Scalable, Performance, Durable, Caching, Operations, Transactions, Consistency Instant Messaging Image Repository Information Portals Twitter 20% 14 Real-time, Memory-cached, Performance, Persistence, Replication, Data structures, Age-off, etc. Ebay 10% 8 Scalable, Performance, Data-replication, Flexible, Consistency, Auto-sharding, Metrics, etc. Generality Reliability Wikimedia 5% 7 Real-time, Distributed, Multi-tenant, Document-based, Schema-free, Persistence, Availability, etc. 3 - $10M Gen App Reliable Low Cplx 2 - $100M Schema Dist P2P Med Cplx 1 - $1B Limited Sin PoF High Cplx Kovacs, K. (2015). Comparison of nosql databases. Retrieved on January 9, 2015, from Sahai, S. (2013). Nosql database comparison chart. Retrieved on January 9, 2015, from DB-Engines (2014). System properties comparison of nosql databases. Retrieved on January 9, 2015, from 11

12 Scrum Created by Jeff Sutherland at Easel in 1993 Product backlog comprised of needed features Sprint-to-sprint, iterative, adaptive emergent model Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall. 12

13 Scrum-XP Hybrid Created by Sanjiv Augustine of Lithespeed in 2008 Release planning used to create product backlog Extends Scrum beyond Sprint-to-sprint planning Initial Planning Discovery Session Sprint Cycle Sprint Agile Training Project Discovery Process Discovery Team Discovery Initial Backlog Select Tasks and Create Tests Create Simple Designs Code and Test Software Units Perform Integration Testing Maintain Daily Burndown Chart Update Sprint Backlog Release Planning Sprint Planning Daily Scrum Sprint Review Business Case Desired Backlog Hi-Level Estimates Set Sprint Capacity Identify Tasks Estimate Tasks Completed Backlog Items Planned Backlog Items Impediments to Progress Present Backlog Items Record Feedback Adjust Backlog 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 Augustine, S. (2008). Certified scrum master training: Not just how, buy why. Herndon, VA: LitheSpeed. 13

14 Agile Project Management Created by Jim Highsmith of Cutter in 2010 Front-end visions and architectures and final QA Light project model wrapped around agile practices 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 Project Community Release Planning Risk Planning Team Development Team Decisions Final QA Final Documentation Final Retrospective 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 Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and Integration Story Deployment Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. 14

15 Agile Project Management Simplified Created by Mark Layton at PlatinumEdge in 2012 Mix of new product development, XP, and Scrum Simple codification of common XP-Scrum hybrid Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing. 15

16 Agile Performance Measurement Burndown Cumulative Flow 16 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.) Earned Value Management - EVM CPI SPI PPC APC Earned Business Value - EBV 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.)

17 Agile Summary Agile methods DON T mean deliver it now & fix it later Lightweight, yet disciplined approach to development Reduced cost, risk, & waste while improving quality What How Result Flexibility Use lightweight, yet disciplined processes and artifacts Low work-in-process Customer Involve customers early and often throughout development Early feedback Prioritize Identify highest-priority, value-adding business needs Focus resources Descope Descope complex programs by an order of magnitude Simplify problem Decompose Divide the remaining scope into smaller batches Manageable pieces Iterate Implement pieces one at a time over long periods of time Diffuse risk Leanness Architect and design the system one iteration at a time JIT waste-free design Swarm Implement each component in small cross-functional teams Knowledge transfer Collaborate Use frequent informal communications as often as possible Efficient data transfer Test Early Incrementally test each component as it is developed Early verification Test Often Perform system-level regression testing every few minutes Early validation Adapt Frequently identify optimal process and product solutions Improve performance Rico, D. F. (2012). What s really happening in agile methods: Its principles revisited? Retrieved June 6, 2012, from Rico, D. F. (2012). The promises and pitfalls of agile methods. Retrieved February 6, 2013 from, Rico, D. F. (2012). How do lean & agile intersect? Retrieved February 6, 2013, from 17

18 Agile Enterprise Frameworks Dozens of Agile project management models emerged Many stem from principles of Extreme Programming All include product, project, & team management escrum SAFe LeSS DaD RAGE Product Mgt Strategic Mgt Business Mgt Business Mgt Business Program Mgt Portfolio Mgt Portfolio Mgt Portfolio Mgt Governance Project Mgt Program Mgt Product Mgt Inception Portfolio Process Mgt Team Mgt Area Mgt Construction Program Business Mgt Quality Mgt Sprint Mgt Iterations Project Market Mgt Delivery Mgt Release Mgt Transition Delivery Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press. Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education. Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley. Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education. Thompson, K. (2013). cprime s R.A.G.E. is unleashed: Agile leaders rejoice! Retrieved March 28, 2014, from 18

19 Enterprise Scrum (escrum) Created by Ken Schwaber of Scrum Alliance in 2007 Application of Scrum at any place in the enterprise Basic Scrum with extensive backlog grooming Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press. 19

20 Scaled Agile Framework (SAFe) Created by Dean Leffingwell of Rally in 2007 Knowledge to scale agile practices to enterprise Hybrid of Kanban, XP release planning, and Scrum Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education. 20

21 Large Scale Scrum (LESS) Created by Craig Larman of Valtech in 2008 Scrum for larger projects of 500 to 1,500 people Model to nest product owners, backlogs, and teams Sprint Planning II 2-4 hours Feature Team + Scrum Master Sprint Backlog Daily Scrum 15 minutes 1 Day 2-4 Week Sprint Product Backlog Refinement 5-10% of Sprint Sprint Retrospective Product Backlog Owner Area Sprint Product Backlog Owner Planning I 2-4 hours Potentially Shippable Product Increment Sprint Review Joint Sprint Review Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley. 21

22 Disciplined Agile Delivery (DaD) Created by Scott Ambler of IBM in 2012 People, learning-centric hybrid agile IT delivery Scrum mapping to a model-driven RUP framework Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education. 22

23 Recipes for Agile Governance (RAGE) Created by Kevin Thompson of cprime in 2013 Agile governance model for large Scrum projects Traditional-agile hybrid of portfolio-project planning Thompson, K. (2013). cprime s R.A.G.E. is unleashed: Agile leaders rejoice! Retrieved March 28, 2014, from 23

24 Comparison of Frameworks Numerous lean-agile enterprise frameworks emerging escrum & LeSS were 1st (but SAFe & DaD dominate) SAFe is the most widely-used (with ample resources) Factor escrum SAFe LeSS DaD RAGE Simple Well-Defined Web Portal Books Measurable Results Training & Cert Consultants Tools Popularity International Fortune 500 Government Lean-Kanban Rico, D. F. (2014). Scaled agile framework (SAFe) comparison. Retrieved June 4, 1024 from 24

25 SAFe Revisited Quality, execution, alignment, & transparency focus Proven, public well-defined F/W for scaling Lean-Agile Synchronizes alignment, collaboration, and deliveries Portfolio Program Team Leffingwell, D. (2014). Scaled agile framework (SAFe). Retrieved June 2, 1024 from 25

26 SAFe Scaling at PORTFOLIO Level Vision, central strategy, and decentralized control Investment themes, Kanban, and objective metrics Value delivery via epics, streams, and release trains AGILE PORTFOLIO MANAGEMENT Decentralized decision making Demand-based continuous flow Lightweight epic business cases Decentralized rolling wave planning Objective measures & milestones Agile estimating and planning Strategy Governance Investment Funding Program Management Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education. 26

27 SAFe Scaling at PROGRAM Level Product and release management team-of-team Common mission, backlog, estimates, and sprints Value delivery via program-level epics and features AGILE RELEASE TRAINS Driven by vision and roadmap Lean, economic prioritization Frequent, quality deliveries Fast customer feedback Fixed, reliable cadence Regular inspect & adapt CI Alignment Synchronization Collaboration Value Delivery Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education. 27

28 SAFe Scaling at TEAM Level Empowered, self-organizing cross-functional teams Hybrid of Scrum PM & XP technical best practices Value delivery via empowerment, quality, and CI AGILE CODE QUALITY Pair development Emergent design Test-first Refactoring Continuous integration Collective ownership Product Quality Predictability Customer Satisfaction Speed Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education. 28

29 SAFe Benefits Cycle time and quality are most notable improvement Productivity on par with Scrum at 10X above normal Data shows SAFe scales to teams of 1,000+ people Benefit Nokia SEI Telstra BMC Trade Station Discount Tire Valpak Mitchell John Deere Spotify Comcast Average App Maps Trading DW IT Trading Retail Market Insurance Agricult. Cable PoS Weeks People Teams Satis 25% 29% 15% 23% Costs 50% 10% 30% Product 2000% 25% 10% 678% Quality 95% 44% 50% 50% 60% Cycle 600% 600% 300% 50% 300% 370% ROI 2500% 200% 1350% Morale 43% 63% 10% 39% Leffingwell, D. (2014). Scaled agile framework (SAFe) case studies. Denver, CO: Leffingwell, LLC. Rico, D. F. (2014). Scaled agile framework (SAFe) benefits. Retrieved June 2, 2014, from 29

30 SAFe Case Studies Most U.S. Fortune 500 companies adopting SAFe Goal to integrate enterprise, portfolios, and systems Capital One going through end-to-end SAFe adoption John Deere Spotify Comcast Agricultural automation 800 developers on 80 teams Rolled out SAFe in one year Transitioned to open spaces Field issue resolution up 42% Quality improvement up 50% Warranty expense down 50% Time to production down 20% Time to market down 20% Job engagement up 10% Television cable/dvr boxes Embedded & server-side 150 developers on 15 teams Cycle time - 12 to 4 months Support 11 million+ DVRs Design features vs. layers Releases delivered on-time 100% capabilities delivered 95% requirements delivered Fully automated sprint tests GUI-based point of sale sys Switched from CMMI to SAFe 120 developers on 12 teams QA to new feature focus Used Rally adoption model 10% productivity improvement 10% cost of quality reduction 200% improved defect density Production defects down 50% Value vs. compliance focus Leffingwell, D. (2014). Scaled agile framework (SAFe) case studies. Denver, CO: Leffingwell, LLC. Rico, D. F. (2014). Scaled agile framework (SAFe) benefits. Retrieved June 2, 2014, from 30

31 SAFe Summary Lean-agile frameworks & tools emerging in droves Focus on scaling agility to enterprises & portfolios SAFe emerging as the clear international leader SAFe is extremely well-defined in books and Internet SAFe has ample training, certification, consulting, etc. SAFe leads to increased productivity and quality SAFe is scalable to teams of up to 1,000+ developers SAFe is preferred agile approach of Global 500 firms SAFe is agile choice for public sector IT acquisitions SAFe cases and performance data rapidly emerging Rico, D. F. (2014). Dave's Notes: For Scaling with SAFe, DaD, LeSS, RAGE, ScrumPLoP, Enterprise Scrum, etc. Retrieved March 28, 2014 from 31

32 Enterprise Continuous Delivery Created by Jez Humble of ThoughtWorks in 2011 Includes CM, build, testing, integration, release, etc. Goal is one-touch automation of deployment pipeline CoQ 80% MS Tst 8/10 No Val $24B in 90s Rep by CD Not Add MLK Humble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education. Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration. Boston, MA: Addison-Wesley. Ohara, D. (2012). Continuous delivery and the world of devops. San Francisco, CA: GigaOM Pro. 32

33 Continuous Integration Fewer integrations leave in higher bug counts Frequent, early integrations eliminate most defects Goal is to have as many early integrations as possible Number of Integrations More Defects Few Integrations Late Integrations Less Defects More Integrations Early Integrations Lacoste, F. J. (2009). Killing the gatekeeper: Introducing a continuous integration system. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA,

34 Continuous Delivery (Assembla) Goal of continuous delivery is releases vs. build/tests Market-driven releases creates rapid business value Assembla went from 2 to 45 monthly releases w/cd 3,645x Faster U.S. DoD IT Project 62x Faster U.S. DoD IT Project Singleton, A. (2014). Unblock: A guide to the new continuous agile. Needham, MA: Assembla, Inc. 34

35 Agile Scaling at Google Google early adopter of agile methods and Scrum Google also uses agile testing at enterprise scale 15,000 developers run 120 million tests per day 440 billion unique users run 37 trillion searches each year Single monolithic code tree with mixed language code Submissions at head One branch All from source 20+ code changes/minute 50% code change/month 5,500+ submissions/day 120 million tests per day 80,000 builds per day 20 million builds per year Auto code inspections For low defect density 10X programming productivity improvement $150 million in annual labor savings (ROI as a result) Micco, J. (2013). Continuous integration at google scale. Eclipse Con, Boston, MA. Whittaker, J., Arbon, J., & Carollo, J. (2012). How google tests software. Upper Saddle River, NJ: Pearson Education. 35

36 Agile Scaling at Amazon Amazon adopted agile in 1999 and Scrum in 2004 Using enterprise-scale continuous delivery by ,000+ developers deploy over 8,600 releases a day Software deployment every 11.6 seconds (as of 2011) 24,828 to 86,320 releases per Iteration 161,379 to 561,080 releases per Quarter 645,517 to 2,244,320 releases per Year Automatic, split-second roll-forward & backward 75-90% reduction in release-caused outages (0.001%) Millions of times faster (than traditional methods) 4,357,241 to 15,149,160 per traditional release Thousands of times faster (than manual agility) 161,379 to 561,080 per Scrum/SAFe release Used agile methods long before U.S. government (1999) Atlas, A. (2009). Accidental adoption: The story of scrum at amazon.com. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, Jenkins, J. (2011). Velocity culture at amazon.com. Proceedings of the Velocity 2011 Conference, Santa Clara, California, USA. Elisha, S. (2013). Continuous deployment with amazon web services. Proceedings of the AWS Summit 2013, Sydney, New South Wales, Australia. 36

37 Agile Scaling w/amazon Web Svcs AWS is most popular cloud computing platform Scalable service with end-to-end security & privacy AWS is compliant & certified to 30+ indiv. S&P stds. AICPA COBIT CSA DoD CSM DIACAP FedRAMP FIPS SSAE SOC SAS Cross Service Analytics Application Services Storage & Content Del. Database Compute & Networking Deployment & Management FISMA GLBA HITECH NoSQL Sols MongoDB Cassandra HBase PCI NIST MPAA ITAR ISO/IEC ISAE HIPAA Barr, J. (2014). AWS achieves DoD provisional authorization. Retrieved January 12, 2015, from Dignan, L. (2014). Amazon web services lands DoD security authorization. Retrieved January 12, 2015, from Amazon.com (2015). AWS govcloud earns DoD CSM Levsl 3-5 provisional authorization. Retrieved January 12, 2015, from 37

38 Agile Leadership Power & authority delegated to the lowest level Tap into the creative nuclear power of team s talent Coaching, communication, and relationships key skills Personal Project Enterprise Don't Be a Know-it-All Be Open & Willing to Learn Treat People Respectfully Be Gracious, Humble, & Kind Listen & Be Slow-to-Speak Be Patient & Longsuffering Be Objective & Dispassionate Don't Micromanage & Direct Exhibit Maturity & Composure Don't Escalate or Exacerbate Don't Gossip or be Negative Delegate, Empower, & Trust Gently Coach, Guide, & Lead Customer Communication Product Visioning Distribution Strategy Team Development Standards & Practices Telecom Infrastructure Development Tools High-Context Meetings Coordination & Governance F2F Communications Consensus Based Decisions Performance Management Personal Development Business Value vs. Scope Interactions vs. Contracts Relationship vs. Regulation Conversation vs. Negotiation Consensus vs. Dictatorship Collaboration vs. Control Openness vs. Adversarialism Exploration vs. Planning Incremental vs. All Inclusive Entrepreneurial vs. Managerial Creativity vs. Constraints Satisfaction vs. Compliance Quality vs. Quantity Rico, D. F. (2013). Agile coaching in high-conflict environments. Retrieved April 11, 2013 from Rico, D. F. (2013). Agile project management for virtual distributed teams. Retrieved July 29, 2013 from Rico, D. F. (2013). Agile vs. traditional contract manifesto. Retrieved March 28, 2013 from 38

39 Organizational Change Models Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation key factors SWITCH INFLUENCER DRIVE DECISIVE Direct the Rider Follow the bright spots Script the critical moves Point to the destination Motivate the Elephant Find the feeling Shrink the change Grow your people Shape the Path Tweak the environment Build habits Rally the herd Make it Desirable Create new experiences Create new motives Surpass your Limits Perfect complex skills Build emotional skills Harness Peer Pressure Recruit public personalities Recruit influential leaders Find Strength in Numbers Utilize teamwork Enlist the power of social capital Design Rewards Use incentives wisely Use punishment sparingly Change Environment Make it easy Make it unavoidable Purpose Purpose and profit equality Business and societal benefit Share control of profits Delegate implementation Culture and goal alignment Remake society and globe Autonomy Be accountable to someone Self-selected work tasks Self-directed work tasks Self-selected timelines Self-selected teams Self-selected implementation Mastery Experimentation and innovation Align tasks to abilities Continuously improve abilities Elevate learning over profits Create challenging tasks Establish high expectations Villains of Good Decisions Narrow framing Confirmation bias Short term emotion Over confidence Widen Your Options Avoid a narrow frame Multi-track Find someone who solved problem Reality Test Assumptions Consider the opposite Zoom out & zoom in Ooch Attain Distance Overcome short-term emotion Gather more info & shift perspective Self-directed work tasks Prepare to be Wrong Bookend the future Set a tripwire Trust the process 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. Pink, D. H. (2009). Drive: The surprising truth about what motivates us. New York, NY: Riverhead Books. Heath, C., & Heath, D. (2013). Decisive: How to make better choices in life and work. New York, NY: Random House. 39

40 Conclusion One must think and act small to accomplish big things Slow down to speed up, speed up til wheels come off Scaling up lowers productivity, quality, & business value EMPOWER WORKFORCE - Allow workers to help establish enterprise business goals and objectives. ALIGN BUSINESS VALUE - Align and focus agile teams on delivering business value to the enterprise. PERFORM VISIONING - Frequently communicate portfolio, project, and team vision on continuous basis. REDUCE SIZE - Reduce sizes of agile portfolios, acquisitions, products, programs, projects, and teams. ACT SMALL - Get large agile teams to act, behave, collaborate, communicate, and perform like small ones. BE SMALL - Get small projects to act, behave, and collaborate like small ones instead of trying to act larger. ACT COLLOCATED - Get virtual distributed teams to act, behave, communicate and perform like collocated ones. USE SMALL ACQUISITION BATCHES - Organize suppliers to rapidly deliver new capabilities and quickly reprioritize. USE LEAN-AGILE CONTRACTS - Use collaborative contracts to share responsibility instead of adversarial legal ones. USE ENTERPRISE AUTOMATION - Automate everything with Continuous Integration, Continuous Delivery, & DevOps. Rico, D. F. (2014). Dave's Notes: For Scaling with SAFe, DaD, LeSS, RAGE, ScrumPLoP, Enterprise Scrum, etc. Retrieved March 28, 2014 from 40

41 Dave s Professional Capabilities Organization Change Government Acquisitions Government Contracting Cost Estimating Systems Engineering BPR, IDEF0, & DoDAF Valuation Cost-Benefit Analysis, B/CR, ROI, NPV, BEP, Real Options, etc. Innovation Management CMMI & ISO 9001 PSP, TSP, & Code Reviews Technical Project Mgt. Software Development Methods Software Quality Mgt. Evolutionary Design Research Methods DoD 5000, TRA, & SRA Lean-Agile Scrum, SAFe, Continuous Integration & Delivery, DevOps, etc. Statistics, CFA, EFA, & SEM Lean Kanban Six Sigma Metrics, Models, & SPC Workflow Automation Big Data, Cloud, NoSQL STRENGTHS Data Mining Gathering & Reporting Performance Data Strategic Planning Executive & Management Briefs Brownbags & Webinars White Papers Tiger-Teams Short-Fuse Tasking Audits & Reviews Etc. 32 YEARS IN IT INDUSTRY Action-oriented. Do first (talk about it later). Data-mining/analysis. Collect facts (then report findings). Simplification. Communicating complex ideas (in simple terms). Git-r-done. Prefer short, high-priority tasks (vs. long bureaucratic projects). Team player. Consensus-oriented collaboration (vs. top-down autocratic control). PMP, CSEP, ACP, CSM, & SAFE 41

42 Books on ROI of SW Methods Guides to software methods for business leaders Communicates the business value of IT approaches Rosetta stones to unlocking ROI of software methods (Description) (Description) 42