Lean & Agile Project Manaagement: Its Leadership Considerations


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Lean & Agile Project Manaagement: Its Leadership Considerations

  1. 1. Lean & AgileProject Management& Its Leadership ConsiderationsDr. David F. Rico, PMP, ACP, CSMTwitter: @dr_david_f_ricoWebsite: http://www.davidfrico.comLinkedIn: http://www.linkedin.com/in/davidfricoFacebook: http://www.facebook.com/profile.php?id=1540017424Dave’s Agile Articles: http://davidfrico.com/agile-message.doc
  2. 2. Author Background DoD contractor with 30+ 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, & Europe2 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.
  3. 3.  Need for Agile Project Mgt.Intro to Agile Project Mgt.Model of Agile Project Mgt.Phases of Agile Project Mgt.Scaling of Agile Project Mgt.Metrics for Agile Project Mgt.Summary of Agile Project Mgt.Agenda3
  4. 4. Today’s Whirlwind Environment4OverrunsAttritionEscalationRunawaysCancellationGlobalCompetitionDemandingCustomersOrganizationDownsizingSystemComplexityTechnologyChangeVagueRequirementsWork LifeImbalanceInefficiencyHigh O&MLower DoQVulnerableN-M BreachReducedIT Budgets81 MonthCycle TimesRedundantData CentersLack ofInteroperabilityPoorIT SecurityOverburdeningLegacy SystemsObsoleteTechnology & SkillsPine, 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 AnnualAFEI/NDIA Conference on Agile in DoD, Springfield, VA, USA.
  5. 5. Traditional Projects5 Big projects result in poor quality and scope changes Productivity declines with long queues/wait times Large projects are unsuccessful or canceledJones, C. (1991). Applied software measurement: Assuring productivity and quality. New York, NY: McGraw-Hill.Size vs. QualityDefectDensity0.003.206.409.6012.8016.000 2 6 25 100 400Lines of Code (Thousands)Size vs. ProductivityCodeProductionRate0. 2 6 25 100 400Lines of Code (Thousands)Size vs. Requirements GrowthPercentage0%8%16%24%32%40%0 2 6 25 100 400Lines of Code (Thousands)Size vs. SuccessPercentage0%12%24%36%48%60%0 2 6 25 100 400Lines of Code (Thousands)
  6. 6. Global Project Failures6Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch. 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 lost16% 53% 31%27% 33% 40%26% 46% 28%28% 49% 23%34% 51% 15%29% 53% 18%35% 46% 19%32% 44% 24%33% 41% 26%0% 20% 40% 60% 80% 100%199419961998200020022004200620082010YearSuccessful Challenged Failed$0.0$0.4$0.7$1.1$1.4$1.82002 2003 2004 2005 2006 2007 2008 2009 2010Trillions(USDollars)Expenditures Failed Investments
  7. 7. Requirements Defects & Waste7Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20Johnson, J. (2002). ROI: Its your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy. Requirements defects are #1 reason projects fail Traditional projects specify too many requirements More than 65% of requirements are never used at allOther 7%Requirements47%Design28%Implementation18%DefectsAlways 7%Often 13%Sometimes16%Rarely19%Never45%Waste
  8. 8. Need for Agile Project Mgt. Intro to Agile Project Mgt.Model of Agile Project Mgt.Phases of Agile Project Mgt.Scaling of Agile Project Mgt.Metrics for Agile Project Mgt.Summary of Agile Project Mgt.Agenda8
  9. 9. 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 toprofit in a turbulent global business environment The ability to quickly reprioritize use of resources whenrequirements, technology, and knowledge shift A very fast response to sudden market changes andemerging threats by intensive customer interaction Use of evolutionary, incremental, and iterative deliveryto converge on an optimal customer solution Maximizing BUSINESS VALUE with right sized, just-enough, and just-in-time processes and documentationHighsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.9 
  10. 10. What are Agile Methods?10 People-centric way to create innovative solutions Product-centric alternative to documents/process Market-centric model to maximize business valueAgile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.orgRico, 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 http://davidfrico.com/agile-concept-model-1.pdfCustomer CollaborationWorking SoftwareIndividuals & InteractionsResponding to Changevaluedmore thanvaluedmore thanvaluedmore thanvaluedmore thanContractsDocumentationProcessesProject Plans Frequent comm. Close proximity Regular meetings Multiple comm. channels Frequent feedback Relationship strength Leadership Boundaries Empowerment Competence Structure Manageability/Motivation Clear objectives Small/feasible scope Acceptance criteria Timeboxed iterations Valid operational results Regular cadence/intervals Org. flexibility Mgt. flexibility Process flexibility System flexibility Technology flexibility Infrastructure flexibility Contract compliance Contract deliverables Contract change orders Lifecycle compliance Process Maturity Level Regulatory compliance Document deliveries Document comments Document compliance Cost Compliance Scope Compliance Schedule Compliance
  11. 11. Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.Rico, D. F. (2012). Agile vs. traditional projects. Retrieved February 6, 2013, from http://davidfrico.com/tpm-vs-apm-ii.pdfAgile Project Management High levels of uncertainty and unpredictability High technology projects Fast paced, highly competitive industries Rapid pace of technological change Research oriented, discovery projects Large fluctuations in project performance Shorter term, performance based RDT&E contracts Achieving high impact product/service effectiveness Highly creative new product development contracts Customer intensive, one off product/service solutions Highly volatile and unstable market conditions High margin, intellectually intensive industries Delivering value at the point of saleTraditional Project Management Predictable situations Low technology projects Stable, slow moving industries Low levels of technological change Repeatable operations Low rates of changing project performance Long term, fixed price production contracts Achieving concise economic efficiency goals Highly administrative contracts Mass production and high volume manufacturing Highly predictable and stable market conditions Low margin industries such as commodities Delivering value at the point of plan11 Exploratory or research/development projects When fast customer responsiveness is paramount In organizations that are highly innovative/creativeWhen to use Agile Methods 
  12. 12. How do Lean & Agile Intersect?12 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 systemWomack, 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).  Economic ViewDecentralizationFast FeedbackControl Cadence& Small BatchesManage Queues/Exploit VariabilityWIP Constraints& KanbanFlow PrinciplesAgile ValuesCustomerCollaborationEmpoweredTeamsIterativeDeliveryRespondingto ChangeLean PillarsRespectfor PeopleContinuousImprovementCustomer ValueRelationshipsCustomer PullContinuous FlowPerfectionValue StreamLean Principles Customer relationships, satisfaction, trust, and loyalty Team authority, empowerment, and resources Team identification, cohesion, and communicationLean & Agile Practices Product vision, mission, needs, and capabilities Product scope, constraints, and business value Product objectives, specifications, and performance As is policies, processes, procedures, and instructions To be business processes, flowcharts, and swim lanes Initial workflow analysis, metrication, and optimization Batch size, work in process, and artifact size constraints Cadence, queue size, buffers, slack, and bottlenecks Workflow, test, integration, and deployment automation Roadmaps, releases, iterations, and product priorities Epics, themes, feature sets, features, and user stories Product demonstrations, feedback, and new backlogs Refactor, test driven design, and continuous integration Standups, retrospectives, and process improvements Organization, project, and process adaptability/flexibility
  13. 13. Need for Agile Project Mgt.Intro to Agile Project Mgt. Model of Agile Project Mgt.Phases of Agile Project Mgt.Scaling of Agile Project Mgt.Metrics for Agile Project Mgt.Summary of Agile Project Mgt.Agenda13
  14. 14. Agile Project ManagementHighsmith, J. A. (2004). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Created by Jim Highsmith at Cutter in 2003 Focus on strategic plans and capability analysis Most holistic agile project management frameworkInnovation LifecycleEnvision Product Vision Product Architecture Project Objectives Project Community Delivery ApproachSpeculate Gather Requirements Product Backlog Release Planning Risk Planning Cost EstimationExplore Iteration Management Technical Practices Team Development Team Decisions CollaborationLaunch Final Review Final Acceptance Final QA Final Documentation Final DeploymentClose Clean Up Open Items Support Material Final Retrospective Final Reports Project CelebrationIterative DeliveryTechnical Planning Story Analysis Task Development Task Estimation Task Splitting Task Planning Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and IntegrationStory DeploymentAdapt Focus Groups Technical Reviews Team Evaluations Project Reporting Adaptive ActionOperational Testing Integration Testing System Testing Operational Testing Usability Testing Acceptance TestingDevelopment, Test, & Evaluation Development Pairing Unit Test Development Simple Designs Coding and Refactoring Unit and Component TestingContinuous14
  15. 15. Need for Agile Project Mgt.Intro to Agile Project Mgt.Model of Agile Project Mgt. Phases of Agile Project Mgt.Scaling of Agile Project Mgt.Metrics for Agile Project Mgt.Summary of Agile Project Mgt.Agenda15
  16. 16. Envision PhaseHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Determine product vision and project objectives Identifies project community and project team The major output is a “Product Vision Box”Envision PhaseDelivery Approach Self-Organization Strategy Collaboration Strategy Communication Strategy Process Framework Tailoring Practice Selection & TailoringProject ObjectivesProject Data SheetKey Business ObjectivesTradeoff MatrixExploration FactorRequirements VariabilityProduct Architecture Skeleton Architecture Hardware Feature Breakdown Software Feature Breakdown Organizational Structure Guiding PrinciplesProject Community Get the Right People Participant Identification Types of Stakeholders List of Stakeholders Customer-Developer InteractionProduct Vision Product Vision Box Elevator Test Statement Product Roadmap Product Features Product Vision Document16
  17. 17. Speculate PhaseHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Determine organizational capability/mission needs Identifies feature-sets and system requirements The major output is a “System Release Plan”Speculate PhaseRelease Planning Project Startup Activities Assign Stories to Iterations First Feasible Deployment Estimate Feature Velocity Determine Product ScopeRisk Planning Risk Identification Risk Analysis Risk Responses Risk Monitoring Risk ControlProduct Backlog Product Features List Feature Cards Performance Requirements Prioritize Features Feature Breakdown StructureCost Estimation Establish Estimate Scope Establish Technical Baseline Collect Project Data Size Project Information Prepare Baseline EstimatesGather Requirements Analyze Feasibility Studies Evaluate Marketing Reports Gather Stakeholder Suggestions Examine Competitive Intelligence Collaborate with Customers17
  18. 18. Explore PhaseHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Determine technical iteration objectives/approaches Identifies technical tasks and technical practices The major output is an “Operational Element”Explore PhaseTeam Development Focus Team Molding Group into Team Develop Individual Capabilities Coach Customers Orchestrate Team RhythmTeam Decisions Decision Framing Decision Making Decision Retrospection Leadership and Decision Making Set and Delay Decision MakingTechnical Practices Reduce Technical Debt Simple Design Continuous Integration Ruthless Automated Testing Opportunistic RefactoringCollaboration Pair Programming Daily Standup Meetings Daily Product Team Interaction Stakeholder Coordination Customer InteractionsIteration Management Iteration Planning Estimate Task Size Iteration Length Workload Management Monitoring Iteration Progress18
  19. 19. Adapt PhaseHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Determine the effectiveness of operational elements Identifies customer feedback and corrective actions The major output is a “Process Improvement Plan”Adapt PhaseTeam Evaluations Communications Quality Team Cohesiveness Interpersonal Trust Individual Talent and Effort Team Performance/EffectivenessProject Reporting Scope and Quality Status Cost and Schedule Status Risk and Value Status Customer Satisfaction Status Team and Agility StatusTechnical Reviews Desk Checks/Individual Reviews Structured Walkthroughs Formal Software Inspections Quality Assurance Audits Configuration Management AuditsAdaptive Action Release Plan Adaptations Iteration Plan Adaptations Feature Set Adaptations User Story Adaptations Task Plan AdaptationsCustomer Focus Groups Requirements Reviews Preliminary Design Reviews Critical Design Reviews Product Demonstration Reviews Acceptance Testing Reviews19
  20. 20. Close PhaseHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Determine project outcome and effectiveness Identifies strengths, weaknesses, and rewards The major output is a “Lessons-Learned Report”Close PhaseSupport Material Finalize Documentation Finalize Production Material Finalize Manufacturing Material Finalize Customer Documentation Finalize Maintenance InformationFinal Reports End-of-Project Reports Administrative Reports Release Notes Financial Reports Facilities ReportsFinal Retrospective Process Performance Assessment Internal Product Assessment External Product Assessment Team Performance Assessment Project Performance AssessmentProject Celebration Individual Rewards Group Rewards Partner Rewards Managerial Rewards Product RewardsClean Up Open Items Close Open Action Items Close Open Change Requests Close Open Problem Reports Close Open Defect Reports Close Open Project Issues20
  21. 21. Need for Agile Project Mgt.Intro to Agile Project Mgt.Model of Agile Project Mgt.Phases of Agile Project Mgt. Scaling of Agile Project Mgt.Metrics for Agile Project Mgt.Summary of Agile Project Mgt.Agenda21
  22. 22. Multi-Level TeamsHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Enables projects to plan for the future and present Decomposes capabilities into implementable pieces Unclogs the drainpipes to let the execution flow freelyMulti-Level TeamsProduct Management Team Product Management Team Chief Product Manager Chief Architect Product Development Manager Release Management Team members (1-2 per release team)Release Management TeamFeature TeamRelease Management Team Product Manager Project Manager Chief Architect Feature team members (1-2 per feature team)Feature Teams Product Specialist (and owner) Iteration Manager Technical and product Members Development team members (1-2 per development team)22
  23. 23. Multi-Level PlanningHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Enables multiple level enterprise plans to co-exist Allows stakeholders to build viewpoint-specific plans Ensures capabilities are delivered at regular intervalsMulti-Level PlanningProduct Roadmap Product Roadmap Enterprise architecture needs Capability focused Vision, objectives, and backlog 18 to 36 weeksRelease PlanIteration PlanRelease Plan Subsystem architecture Feature set focused Strategy, objectives, and backlog 6 to 12 weeksIteration Plan Component-level architecture User story focused Implementation plan, objectives, and backlog 2 to 4 weeks23
  24. 24. Multi-Level BacklogHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Enables multiple levels of abstraction to co-exist Allows customers and developers to communicate Makes optimum use of people’s time and resourcesMulti-Level BacklogCapabilities Capability Mission goal or objective level High-level business or product function Also called an Epic, i.e., multiple feature sets Comprises 18-90 days worth of workFeature Set Cross-functional mission threads Related user stories that are grouped together Also called a Theme, i.e., implemented as an entity Comprises 6 to 30 days worth of workUser Story Functional, system-level requirements Simple requirement written by customer or user A small unit of functionality having business value Comprises 2 to 10 days worth of workCapability1Capability2Capability3Feature SetsFeature1Feature2Feature3User StoriesStory 1 Story 4 Story 7Story 2 Story 5 Story 8Story 3 Story 6 Story 924
  25. 25. Multi-Level Coord. & GovernanceHighsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education. Enables agile methods to scale to big programs Allows programs to coordinate functional activities Ensures optimal technical performance is achieved25Multi-Level Coordination & GovernanceUser Story Teams User Story Teams User Story TeamsFeature Set TeamCapability TeamFeature Set Team Feature Set Team
  26. 26. Agile Enterprise Delivery ModelBeck, K., & Fowler, M. (2001). Planning extreme programming. Upper Saddle River, NJ: Addison-Wesley.Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.Larman, C., & Vodde, B. (2010). Practices for scaling lean and agile development. Boston, MA: Addison-Wesley.Leffingwell, D. (2011). Agile software requirements: Lean requirements practices for teams, programs, and the enterprise. Boston, MA: Pearson Education. Begins with a high-level product vision/architecture Continues with needs development/release planning Includes agile delivery teams to realize business value26
  27. 27. Need for Agile Project Mgt.Intro to Agile Project Mgt.Model of Agile Project Mgt.Phases of Agile Project Mgt.Scaling of Agile Project Mgt. Metrics for Agile Project Mgt.Summary of Agile Project Mgt.Agenda27
  28. 28. Studies of Agile Methods Dozens of surveys of agile methods since 2003 100s of Agile and CMMI case studies documented Agile productivity, quality, and cost better than CMMI28Rico, D. F. (2008). What is the return-on-investment of agile methods? Retrieved February 3, 2009, from http://davidfrico.com/rico08a.pdfRico, D. F. (2008). What is the ROI of agile vs. traditional methods? TickIT International, 10(4), 9-18.
  29. 29. Agile Cost of Quality (CoQ) Agile testing is 10x better than code inspections Agile testing is 100x better than traditional testing Agile testing is done earlier “and” 1,000x more often29Rico, D. F. (2012). The Cost of Quality (CoQ) for Agile vs. Traditional Project Management. Fairfax, VA: Gantthead.Com.
  30. 30. Agile Cost & Benefit Analysis Costs based on avg. productivity and quality Productivity ranged from 4.7 to 5.9 LOC an hour Costs were $588,202 and benefits were $3,930,63130Rico, 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.d1 = [ln(Benefits  Costs) + (Rate + 0.5  Risk2)  Years]  Risk   Years, d2 = d1  Risk   Years 51i
  31. 31. 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%)Mah, M. (2008). Measuring agile in the enterprise: Proceedings of the Agile 2008 Conference, Toronto, Canada.Project Cost in Millions $0.751.502. AgileAfter Agile61%LowerCostTotal Staffing1811Before AgileAfter Agile39%LessStaff5101520Delivery Time in Months51015201813.5Before AgileAfter Agile24%FasterCumulative Defects6251250187525002270381Before AgileAfter Agile93%LessDefects31
  32. 32. 32Agile Performance MeasurementWork(Story,Point,Task)orEffort(Week,Day,Hour)Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)BurndownWork(Story,Point,Task)orEffort(Week,Day,Hour)Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)Cumulative FlowWork(Story,Point,Task)orEffort(Week,Day,Hour)Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)Earned Value Management - EVM CPISPIPPCAPCWork(Story,Point,Task)orEffort(Week,Day,Hour)Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)Earned Business Value - EBV
  33. 33. Need for Agile Project Mgt.Intro to Agile Project Mgt.Model of Agile Project Mgt.Phases of Agile Project Mgt.Scaling of Agile Project Mgt.Metrics for Agile Project Mgt. Summary of Agile Project Mgt.Agenda33
  34. 34. Agile Adoption34House, D. (2012). Sixth annual state of agile survey: State of agile development. Atlanta, GA: VersionOne. VersionOne found 80% using agile methods today Most are using Scrum with several key XP practices Lean-Kanban is a rising practice with a 24% adoption ContinuousIntegration●●●●●●●●●●●●
  35. 35. Agile ProliferationScrum Alliance. (2012). Scrum certification statistics. Retrieved February 6, 2013, from http://www.scrumalliance.org/resource_download/2505Taft, D. K. (2012). Agile developers needed: Demand outpaces supply. Foster City, CA: eWeek. 35 Number of CSMs have doubled to 200,000 in 2 years 558,918 agile jobs for only 121,876 qualified people 4.59 jobs available for every agile candidate (5:1)
  36. 36. Agile Industry Case Studies 80% of worldwide IT projects use agile methods Includes regulated industries, i.e., DoD, FDA, etc. Agile now used for safety critical systems, FBI, etc.36IndustryShrinkWrappedElectronicCommerceHealthCareLawEnforcementOrg 20 teams 140 people 5 countriesSize 15 teams 90 people Collocated 4 teams 20 people Collocated 10 teams 50 people Collocated 3 teams 12 people CollocatedU.S.DoDPrimaveraGoogleStratcomFBIFDAProjectPrimaveraAdwordsSKIwebSentinelm2000PurposeProjectManagementAdvertisingKnowledgeManagementCase FileWorkflowBloodAnalysis 1,838 User Stories 6,250 Function Points 500,000 Lines of CodeMetrics 26,809 User Stories 91,146 Function Points 7,291,666 Lines of Code 1,659 User Stories 5,640 Function Points 451,235 Lines of Code 3,947 User Stories 13,419 Function Points 1,073,529 Lines of Code 390 User Stories 1,324 Function Points 105,958 Lines of CodeRico, D. F. (2010). Lean and agile project management: For large programs and projects. Proceedings of the First International Conference on LeanEnterprise Software and Systems, Helsinki, Finland, 37-43.
  37. 37. Agile vs. Traditional Success Traditional projects succeed at 50% industry avg. Traditional projects are challenged 20% more often Agile projects succeed 3x more and fail 3x less oftenStandish Group. (2012). Chaos manifesto. Boston, MA: Author.37Agile TraditionalSuccess42%Failed9%Challenged49%Success14%Failed29%Challenged57%
  38. 38. Hoque, F., et al. (2007). Business technology convergence. The role of business technology convergence in innovationand adaptability and its effect on financial performance. Stamford, CT: BTM Institute.38 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%Benefits of Organizational Agility
  39. 39. Agile Recap Agile methods DON’T mean deliver it now & fix it later Lightweight, yet disciplined approach to development Reduced cost, risk, & waste while improving quality39Rico, D. F. (2012). What’s really happening in agile methods: Its principles revisited? Retrieved June 6, 2012, from http://davidfrico.com/agile-principles.pdfRico, D. F. (2012). The promises and pitfalls of agile methods. Retrieved February 6, 2013 from, http://davidfrico.com/agile-pros-cons.pdfRico, D. F. (2012). How do lean & agile intersect? Retrieved February 6, 2013, from http://davidfrico.com/agile-concept-model-3.pdfWhat How ResultFlexibility Use lightweight, yet disciplined processes and artifacts Low work-in-processCustomer Involve customers early and often throughout development Early feedbackPrioritize Identify highest-priority, value-adding business needs Focus resourcesDescope Descope complex programs by an order of magnitude Simplify problemDecompose Divide the remaining scope into smaller batches Manageable piecesIterate Implement pieces one at a time over long periods of time Diffuse riskLeanness Architect and design the system one iteration at a time JIT waste-free designSwarm Implement each component in small cross-functional teams Knowledge transferCollaborate Use frequent informal communications as often as possible Efficient data transferTest Early Incrementally test each component as it is developed Early verificationTest Often Perform system-level regression testing every few minutes Early validationAdapt Frequently identify optimal process and product solutions Improve performance
  40. 40. Conclusion40 Agility is the evolution of management thought Confluence of traditional and non-traditional ideas Improve performance by over an order of magnitude“The world of traditional project management belongs to yesterday”“Don’t waste your time using traditional methods on 21st century projects”Agile methods are …Systems development approachesNew product development approachesExpertly designed to be fast and efficientIntentionally lean and free of waste (muda)Systematic highly-disciplined approachesCapable of producing high quality systemsRight-sized, just-enough, and just-in-time tools Scalable to large, complex mission-critical systems Designed to maximize business value for customersWysocki, R.F. (2010). Adaptive project framework: Managing complexity in the face of uncertainty. Boston, MA: Pearson Education. 
  41. 41. Books on ROI of SW Methods Guides to software methods for business leaders Communicates business value of software methods Rosetta stones to unlocking ROI of software methods http://davidfrico.com/agile-book.htm (Description) http://davidfrico.com/roi-book.htm (Description)41
  42. 42. 42LeadershipConsiderations
  43. 43. 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 LeadersAgile Organization ChangeAgile Acquisition & ContractingAgile Strategic PlanningAgile Capability AnalysisAgile Program ManagementAgile Tech.Agile Information SystemsAgile ToolsAgile Processes & PracticesAgile Systems DevelopmentAgile Project Management43
  44. 44. Leadership Theory44Van Seters, D. A., & Field, R. H. (1990). The evolution of leadership theory. Journal of Organizational Change Management, 3(3), 29–45.Daft, R. L. (2011). The leadership experience. Mason, OH: Thomson Higher Education.Day, D. V., & Anbtonakis, J. (2012). The nature of leadership. Thousand Oaks, CA: Sage Publications.Northouse, P. G. (2013). Leadership: Theory and practice. Thousand Oaks, CA: Sage Publications. Many leadership theories emerged in last 100 years Many believe there is no unified theory of leadership Truth is somewhere in the midst of old and new ideas
  45. 45. Agile Leadership Theories45 Numerous theories of agile leadership have emerged Many have to do with delegation and empowerment Leaders have major roles in visioning and enablingAugustine(2005)Pink(2009)Denning(2010)Poppendieck(2010)Appelo(2011)Organic TeamsGuiding VisionTransparencyLight TouchSimple RulesImprovementAutonomyAlignmentTransparencyPurposeMasteryImprovementSelf OrganizingCommunicationTransparencyIterative ValueDelight ClientsImprovementTalented TeamsAlignmentSystems ViewReliabilityExcellenceImprovementEmpowermentAlignmentMotivationScalingCompetencyImprovementAugustine, S. (2005). Managing agile projects. Upper Saddle River, NJ: Pearson Education.Pink, D. H. (2009). Drive: The surprising truth about what motivates us. New York, NY: Penguin Books.Poppendieck, M, & Poppendieck, T. (2010). Leading lean software development: Results are not the point. Boston, MA: Pearson Education.Anderson, D. J. (2010). Kanban: Successful evolutionary change for your technology business. Sequim, WA: Blue Hole Press.Appelo, J. (2011). Management 3.0: Leading agile developers and developing agile leaders. Boston, MA: Pearson Education.
  46. 46. Agile Project Leadership46 Agile management is delegated to the lowest level There remain key leadership roles & responsibilities Communication, coaching, and facilitation key onesCustomer CommunicationProduct VisioningDistribution StrategyTeam DevelopmentStandards & PracticesTelecom InfrastructureDevelopment ToolsHigh Context MeetingsCoordination MeetingsF2F CommunicationsPerformance ManagementFacilitate selection of methods for obtaining and maintaining executive commitment, projectresources, corporate communications, and customer interactionFacilitate selection of methods for communicating product purpose, goals, objectives, mission,vision, business value, scope, performance, budget, assumptions, constraints, etc.Facilitate selection of virtual team distribution strategy to satisfy project goals and objectivesFacilitate selection of methods for training, coaching, mentoring, and other team buildingapproachesFacilitate selection of project management and technical practices, conventions, roles,responsibilities, and performance measuresFacilitate selection of high bandwidth telecommunication products and servicesFacilitate selection of agile project management tools and interactive development environmentFacilitate selection of high context agile project management and development meetingsFacilitate selection of meetings and forums for regular communications between sitecoordinatorsFacilitate selection of methods for maximizing periodic face to face interactions andcollaborationFacilities selection of methods for process improvement, problem resolution, conflictmanagement, team recognition, product performance, and customer satisfactionMaholtra, A., Majchrzak, A., & Rosen, B. (2007). Leading virtual teams. Academy of Management Perspectives, 21(1), 60-70.Hunsaker, P. L., & Hunsaker, P. L. (2008). Virtual teams: A leadership guide. Team Performance Management, 14(1/2), 86-101.Fisher, K., & Fisher, M. D. (2001). The distance manager: A hands on guide to managing off site employees and virtual teams. New York, NY: McGraw-Hill.
  47. 47. Agile Leadership Coaching47 Executive coaching considered latest development 100s of books on executive coaching and mentoring Well coached teams & individuals perform 10x betterDavies, R., & Sedley (2009). Agile coaching. Raleigh, NC: Pragmatic Bookshelf.Adkins, L. (2010). Coaching agile teams: A companion for scrummasters, agile coaches, and project managers in transition. Boston, MA: Addison-Wesley. Respect. Always treat people with respect and dignity Peaceful. Be slow to speak, anger, and overreact Composed. Walk away from a situation when in doubt Space. Give space, dont crowd, and dont be pushy Patience. Be calm, cool, rational, and even-tempered Objective. Keep focus and dont escalate or exacerbate Maturity. Strive be a role model of maturity at all times Listen. Observe and wait for subtle cues to add value Guide. Gently and respectfully guide, correct, and lead      BE OPEN OBSERVE LISTEN LEARN CONNECT RESPECT PRIVACY
  48. 48. Traditional Organizational ChangeSatir, V., Banmen, J., Gerber, J., & Gomori, M. (1991). The satir model: Family therapy and beyond. Palo Alto, CA: Science and Behavior Books. Humans can’t cope with large technological change Changes may be resisted for a long time (years) Big changes plunge organizations into chaos48
  49. 49. Agile Organizational ChangeSidky, A. (2008). Becoming agile in an imperfect world. Washington, DC: Agile Project Leadership Network (APLN). Enable us to cross-the-chasm sooner or earlier Reduce chaos associated with large-scale change Reduce or divide the risk of change into small pieces49
  50. 50. Organizational Change ModelsHeath, 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. Change, no matter how small or large, is difficult Smaller focused changes help to cross the chasm Shrinking, simplifying, and motivation key factors50Switch - How to Change Things When Change is Hard Influencer - The Power to Change AnythingDirect the Rider Follow the bright spots - Clone what works Script the critical moves - Use prescriptive behaviors Point to the destination - Focus on the end gameMotivate the Elephant Find the feeling - Appeal to emotion Shrink the change - Use incremental change Grow your people - Invest in training and educationShape the Path Tweak the environment - Simplify the change Build habits - Create simple recipes for action Rally the herd - Get everyone involvedMake the Undesirable Desirable Create new experiences - Make it interesting Create new motives - Appeal to sensibilitySurpass your Limits Perfect complex skills - Establish milestones Build emotional skills - Build maturity and people skillsHarness Peer Pressure Recruit public personalities - Involve public figures Recruit influential leaders - Involve recognized figuresFind Strength in Numbers Utilize teamwork - Enlist others to help out Enlist the power of social capital - Scale up and outDesign Rewards and Demand Accountability Use incentives wisely - Reward vital behaviors Use punishment sparingly - Warn before taking actionChange the Environment Make it easy - Simplify the change Make it unavoidable - Build change into daily routine