1 / 41

Agile methods: An unexpected journey

Agile methods: An unexpected journey. Diane Strode PhD Faculty of Business and Information Technology Whitireia Polytechnic Victoria Business School Victoria University of Wellington. Overview. Motivation

zev
Download Presentation

Agile methods: An unexpected journey

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Agile methods: An unexpected journey Diane Strode PhD Faculty of Business and Information Technology Whitireia Polytechnic Victoria Business School Victoria University of Wellington

  2. Overview • Motivation • Pre-history, agile methods in 2000, adaptation, optimal environments, adoption, governance...agile software development today • References and resources

  3. Motivation...teaching • Project management to future PMs • A project manager coordinates and controls software projects • Gantt charts, PERT charts • Analysis and design to future IT BAs • Analyse, then design, then code, then test, AND document • Programming to future developers • Testing – separation of concerns • Meeting specifications So what’s new in this area – Ahhh...agile methods

  4. Primary sources • Doctor of Philosophy (Information Systems) 2012 • A theory of coordination in agile software development projects • Master of Information Sciences (Information Systems) 2005 • The agile methods: An analytical comparison of five agile methods and an investigation of their target environment • 15 individual software development projects

  5. Agile pre-history • 17 practitioners decided to meet at Snowbird in USA, 2001 • Based on their experiences, they rejected waterfall processes and traditional project management practices  “heavyweight methodologies” • All working on individual “lightweight” methodologies based on their experience in development teams • Discussed and agreed on a manifesto

  6. http://agilemanifesto.org

  7. Focus on business value of software No detailed upfront requirement specification Frequent demos and feedback / Frequent releases to production Very close customer contact

  8. Focus on business value of software No detailed upfront requirement specification Frequent demos and feedback / Frequent releases to production Support the team Trust the team Co-location Very close customer contact No last minute rush / burnout

  9. Focus on business value of software No detailed upfront requirement specification Frequent demos and feedback / Frequent releases to production Support the team Trust the team Very close customer contact Co-locate Design and quality Completed functionality No gold plating Self-organising No last minute rush / burnout Continuous process improvement

  10. Purpose • Scrum –for project management of iterative projects • XP –software development practices for high-change environments • DSDM - a framework for iterative projects • Crystal methods - for designing a methodology

  11. Agile Software Development

  12. Scrum One-month “Sprints” or repeated cycles of activity

  13. XP – Extreme Programming Iterations of 1-4 weeks

  14. Agile practices

  15. Agile software development • Each agile method consists of a set of practices • Initially the belief was that a method should be adopted in its entirety • In projects, practices are “cherry picked” or tailored • So if you use any method, any combination of methods, or one or more agile practices, you can say you are doing… Agile software development

  16. Agile method combinations • XP + Scrum • XP provides software development techniques + Scrum provides management practices

  17. Commonalities – 5 agile methods • All published between 1995 – 2002 in USA and UK • Developed by practitioners (not academics) • Project manager and developer perspective • Incremental development • Iterative development - 1 month iterations optimal • Suitable for projects undergoing constant change • Active user involvement • Feedback (from testing, from users) and learning

  18. Commonalities – 5 agile methods cont’d. • Teamwork and empowered teams • Communication between all stakeholders is critical • Small teams of 3-10 programmers is optimal • Frequent meetings, daily is optimal • Working software is the main product of development • Modelling techniques are not mandated • Minimise documentation

  19. When should you use an agile method? • Research study... Nine projects, different types of organisation, different types of product, questionnaire Calculated agile method usage Looked at correlation between agile method usage and factors in the development environment

  20. When should you use an agile method? • Began with a definition of success • Success is when a project is using all of the practices from their selected method • e.g. if using XP then you are using all XP practices 100% of the time

  21. Research design • First, developed a list of factors that various authors believe are necessary for successful agile software development - 31 • Then, isolated all practices from five agile methods (XP, Scrum, ASD, Crystal, DSDM) – 45 • Studied correlation between environmental factors and adoption of practices

  22. Research design • Questionnaire • Included questions to assess use of 31 environment factors • Included a randomised list of 45 practices from five agile methods • Completed by nine experienced project leaders • Interview • Each project leader was interviewed to ensure consistency of understanding about the various practices

  23. The projects

  24. Organisational factors investigated • Organisation factors • social interaction is trustful, collaborative, competent… • Domain factors • Internet application domains, gaming, inventory … • Technological factors • automated testing, object-oriented technology… • Project factors • time pressure, requirements stability… • People factors • CRACK customers, experienced developers… Collaborative, Representative, Authorised, Committed, Knowledgeable

  25. Agile method usage Result: Certain organisational factors correlate with higher usage of agile practices Key Blue area shows non-agile projects All non-agile projects were assessed against XP

  26. Agile method usage Result: An agile project can tailor their agile method so much that it is the same as using ad hoc development (no method) Key Blue area shows non-agile projects All non-agile projects were assessed against XP

  27. Typical result Scatter plot of organisation enables empowerment of people Q34. Spearman’s Rho, 2 tailed, 0.05 significance level

  28. Target environment for agile methods • Organisation • Values feedback and learning. Social interaction in the organisation is trustful, collaborative, and competent • Values teamwork, is flexible and participative, and encourages social interaction. The project manager acts as a facilitator • Enables empowerment of people • Is results oriented • Is based on loyalty and mutual trust and commitment • The management style is that of leadership and collaboration • Leadership in the organisation is entrepreneurial, innovative, and risk taking • Project • Projects undergoing constant change 

  29. Is this generalisable, or cause and effect? - No - • Sample too small, as usual, further studies needed! Keep in mind that you might have fewer problems using an agile method if these factors are present in your organisation or project

  30. Implications • Many practices work well together, so… • If you change the method too much you loose some advantages, however… • If you don’t change the method you may need to change your organisation; this can be difficult, painful, and sometimes impossible.

  31. Agile software development impact... • Organisation • Structure – peoples’ roles – manager, project manager, business analyst, developer, tester.... • Culture – command & control  self-organisation • Human resource practice – rewards, individual  team, skill sets • Customer involvement • Contract negotiation • Software project • System quality - negotiable • Learn as you go/ incremental delivery • Software for communication (but it’s still star of the show) • Co-located & cross-functional teams (can understand and do each others work) • Technical practices • Test driven development , Continuous integration, Refactoring

  32. IT governance and agile projects • Are compatible, but not seamlessly compatible • Depends on the organisation’s ability to be flexible in their implementation of governance processes... “Agile thought leaders have not provided much clear or detailed guidance about scaling Agile practices to the enterprise level, where many governance issues are ready to pounce. To make Agile work within enterprise governance, managing the people issues first is critical. Next, organizations must apply a common-sense approach to processes, enabling transitioning teams to manage demand and deliver efficiently without adding layers of bureaucracy. In addition, organizations should use tools to provide the transparency necessary to ensure that demand is prioritized and selected based on the value the finished product will deliver to the organization.” Forrester Research July 2012

  33. Conflict in the need to meet governance requirements with the agile team’s focus on only delivering business value to their client

  34. Agile today • Coaches and coaching • Internal and external (consultants) • Certification • Certified IC Agile Professional (Alistair Cockburn) • Certified ScrumMaster and Scrum practitioner certifications • DSDM foundation/practitioner • PMIs Agile Certified Practitioner certification • Agile Project Management Certification (integrates with PRINCE2!) – APMG examination institute • Agile encroachment • IIBA - Agile extension integrated into the BABOK • Agile and PMBOK – remain incompatible on many fronts • Agile and SWEBOK – remain incompatible on many fronts

  35. http://www.eweek.com/developer/agile-developers-needed-demand-outpaces-supply-study/http://www.eweek.com/developer/agile-developers-needed-demand-outpaces-supply-study/ Development positions

  36. Adoption rates • Wide variation in reported adoption rates world wide • 14% (Dyba & Dingsoyr, 2008) – an academic report • 35% (West & Grant, 2010) – a Forrester research report • 69% (Ambler, 2009) – an agile guru’s report • Indisputable - agile software development - has grown in popularity in the last 12 years • Advocated as one of the top ten “best practices” of IT project management (Nelson, 2007)

  37. Further information… • APN • Agile Professionals Network • Not-for-profit • Monthly meetings in Wellington with seminars from industry on success and issues with agile software development • http://www.agileprofessionals.net/

  38. Resources • Doctor of Philosophy (Information Systems) 2012 • A theory of coordination in agile software development projects • Master of Information Sciences (Information Systems) 2005 • The agile methods: An analytical comparison of five agile methods and an investigation of their target environment • Please contact me if you would like copies of any of the resources mentioned in this seminar • diane.strode@alumni.unimelb.edu.au • My research site • https://sites.google.com/site/dianestrodepublic/

  39. Agile methods: An unexpected journey

More Related