The document discusses the challenges and contradictions of using agile development techniques within project frameworks, questioning whether traditional project management aligns with the agile approach. It highlights the mixed success of agile projects and proposes alternative models such as ongoing service teams that focus on continuous value delivery rather than fixed project outcomes. Ultimately, it suggests that while projects and agile can coexist, a reevaluation of how projects are conceptualized and managed may be necessary.

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