Are projects agile?
- 1. Are projects agile? Andy Longshaw
- 2. 2 There seems to be concern about projects • Mixed results running projects using agile development techniques – Sometimes they work, sometimes they don’t • Some current agile thinking seems to go against some fundamentals of projects – E.g. some approaches suggested by the #NoEstimates discussions • The #NoProjects hashtag 2
- 3. 3 What do we mean by a project? • We use projects to manage many shapes and sizes of work – Strategic product enhancements – Bespoke changes for a customer – Rollout of product to a customer – Internal system enhancements – Bespoke client application – Etc. 3 A project is a temporary endeavor undertaken to create a unique product, service or result. A project is temporary in that it has a defined beginning and end in time, and therefore defined scope and resources. Source: https://www.pmi.org/about/learn-about-pmi/what-is-project-management
- 4. 4 What do you think? – 1 Who thinks that projects and agile software development don’t mix well? 4
- 5. 5 Are projects agile? • I used to be fairly sure but now I’m less so • I ran some workshops in collaboration with Kevin Rutherford Good software provides value and benefit to its users. Most good software has a long life; and most good software evolves continuously, keeping pace with the needs of its users. By contrast, a project is, by definition, a temporary structure created to manage and deliver a specific goal. Some projects that were run using agile software development techniques have succeeded, and some have failed. What is it about the context, team structure and governance of those that succeeded (and what was their definition of success) compared to those that failed? Do projects even make sense in a truly agile software development context? This workshop will ask participants to explore whether projects are a good fit for software development. Participants will work in small groups to exchange thoughts and ideas, build them into a coherent viewpoint and present them back to the other groups.
- 6. 6 The workshops 6 Agile Manchester 2016 SPA Conference 2016 Agile On the Beach 2016
- 7. 7 The case for the prosecution • Projects address a static need – Bad at handling change • Projects have explicit and implicit costs – Overheads, overruns, (lost) opportunity • Estimates on which they are based are frequently (very) inaccurate • Risk of failure of a infrequent deliveries • Loss of knowledge at the end of the project – Subject matter, architecture 7
- 8. 8 Some other specific issues in workshops • External (or internal) customers and trust – Trust us – we’re developers… – Enforced fairness • Capitalisation of investment and attribution to projects • Money spent vs features delivered / may not get what you wanted • Fear of “throwing things away” 8
- 9. 9 Some alternative approaches – the stream • Most common – the stream – Ongoing product/service team – Growing a service and then ongoing provision of a service and not a single deliverable – Focus on value delivery and measure as you go – Mixed backlog of updates, features and bugs – No end date “Deliver until bored” 9
- 10. 10 The stream - context • Important that it matches your context • Key context for the stream includes – Good customer collaboration – Customer must be open to agreeing a chunk of money and a timebox (sounds a bit like a project?) – Flexible delivery organisation (pack up and go when value stops) 10
- 11. 11 Some more alternative approaches • Buying trust – Context: obtaining new business – Initial engagement at low trust time can be a “loss leader” • Agreed allocation of time to capitalisation – Context: Internal system/product build – New features vs bugs and operational work – As long as it has enough science to satisfy the auditor – Ref Brett Ansley AOTB “Accounting for Agile Software” 11
- 12. 12 Potential problems • Expectation management – Drop one of the points on the iron triangle – Working with ranges, probabilities and other explicit representations of uncertainty – People aren’t used to working in this way • Initial delivery can be a bit underwhelming – Setup costs to get pipeline working – Early risk mitigation can look like slow progress 12
- 13. 13 Should it really be… • #NoContracts? • That’s a little scary… • Implicit psychological contracts for internal projects as well as explicit external contracts • Make them explicit… • Build trust and discover opportunities together • Ongoing work, smaller impacts on a regular basis 13
- 14. 14 …or maybe more • #DifferentContracts • A more agile contract maybe? – Master agreement with specific Statements of Work (SoW) – SoW => says “what sort of things” will be delivered • A more agile delivery – Initial T&M discovery still trying to deliver working software – Add on new work packages that are under signoff limit of your customer contact – Terminate at the end of the current work package • Meaningful KPIs in contract – Fail to meet them => penalties – E.g. story completion rates based on initial discovery, effort variance (no burnout), defect rates, etc. 14
- 15. 15 Conclusions • Projects can be orthogonal to agile development • We imbue them with baggage from bad organisations • In some cases they are useful or needed – Customer contracts – Internal organisation structures – Check your context • Explore a better way… • …but if you’re managing cost/time/value it still sounds a bit like a project 15
- 16. 16 What do you think? - 2 • Anyone less convinced? – That projects per-se are non-agile? • Anyone more convinced? Andy Longshaw @andylongshaw andy.longshaw@lexisnexis.co.uk https://blogs.blueskyline.com 16