La quasi totalità degli sviluppi software è basata su un approccio per progetto. Un progetto, per definizione, è qualcosa di effimero. Ha un inizio, e soprattutto una fine, qualcosa di temporaneo. Il software non è temporaneo. Un software sopravvive fino a quando esiste almeno una persona che lo utilizza. A volte sopravvive anche più a lungo. Perché continuiamo ad usare qualcosa di effimero per gestire qualcosa che effimero non è? Quali alternative abbiamo? Possiamo fare veramente a meno dei progetti?

1. https://www.linkedin.com/in/dimitri-favre-088675/
@DimitriFavre
Dimitri Favre
#noprojects
Modern software developement focus on
teams and products

2. Are you going to talk
about yet another
#nosomething
hashtag?

3. I’d actually loved to hold a symposium on
«Ditemi perché se la mucca fa mu il merlo
non fa me. Digressione sul grande vuoto
dato dall'assenza del coach waterfall»

4. Inspired by the work of Allan Kelly,
Shane Estie, Evan Leybourn and
others.
Images and illustrations from «Spongebob Squarepants», © Viacom

5. Inspired by the work of Allan Kelly,
Shane Estie, Evan Leybourn and
others.
And my very own experience
Images and illustrations from «Spongebob Squarepants», © Viacom

6. A few steps back

7. We are (still) uncovering
better ways of developing
software by doing it and
helping others to do it
Agile Manifesto, 2001

8. I want to stress is the importance of getting rid of software
projects as a notion. Instead we want to switch to
a product-oriented view of the world where instead of
projects that you spin up, run for a while and then stop;
you instead say,
"Let's focus on things that are much more long-lasting
and organize a product team around that.“
Martin Fowler, «The State of Agile», August 2018

9. It’s not the project
It’s the project model

10. We are so used to the project model
that we are not able to see we have a
problem with the project model

11. My top 5 problems with the
project model

14. The power of teams

15. Bruce Tuckman, 1965

16. Bruce Tuckman, 1965
End of project.
Let’s dismantle the team.
We’ll create a brand new
team when and if a new
project will start

17. And while you celebrate
project success, you
destroy all the team
value by dismantling it

19. Products are forever
(kind of)
and continuously
evolving

20. A project is a temporary
endeavor undertaken to
create a unique product,
service or result.
Source: What is Project Management, PMI - https://www.pmi.org/about/learn-about-pmi/what-is-project-management

21. It means that

22. Projects start

23. … and finish
(well, not all of them)

24. At the end of a project success is typically
(still) associated with the iron sulphite triplet:
- On time (schedule)
- On budget
- On scope

25. Where’s value?
What about quality?

26. Project success focus on the wrong things
(what is measurable, not what is valuable)

28. What happens when the
project ends?

29. Typically two choices:
- The projects is extended
- Handover to AMS

30. Praying for
extra-budget

31. Here’s the budget

32. Handover to
AMS Teams

33. AMS is the
retirement home
of products

34. Until they are
declared officially
dead
phased off

35. Maintenance should
be just a transient
state before next
evolutionary step
Source: By Dzonatas - Own work, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=4376189

36. DEV-AMS Conflict of interest
AMS and support contracts with any
form of per incident fee has no interest
in reducing technical debt during the
development project

37. Major league teams
VS
Minor league teams

39. Project model enforce the view of the
IT as a cost center and foster silos
creation

40. Organizational silos
represent one of the
major barrier to agility

41. Projects (even agile ones) are actually
built around silos

42. Instead of value the outcome is
local optimizations, redundancy and
increased complexity

43. Silos fight for budget allocation based
on a cost perspective

44. And teams are created, split, changed,
recombined or even terminated in
order to match the project that justify
their work

45. Bruce Tuckman, 1965
End of project.
Let’s dismantle the team.
We’ll create a brand new
team when and if a new
project will start

46. And this is so typical
for outsourcers
working for
commissioned
orders

48. Projects are typically
based on a defined
scope
(with a long and detailed
list of requirements)

49. The project model poisons the
whole delivery even if you are
an agile factory

50. Agile and Project in the same
sentence is an oxymoron

51. Ooops

52. Forecasts and budgets are
typically based on the defined
set of requirements that will be
then become a project

53. Here’s the budget
(again)

54. Leading to scope
based contracts

55. At the end of the day, Time&Material
(with variations that take in account for
value delivered) is the most common
kind of agile contract

56. As a matter of fact, funding is based on
capacity more than scope

57. 5. Disposable ad-hoc teams
4. Project Model focus on the wrong things
3. Projects have expiration date
2. Project foster silos
1. The Agile Project oxymoron

58. #noproject world

59. Perfection is achieved, not
when there is nothing
more to add, but when
there is nothing left to take
away.
Antoine de Saint-Exupéry

60. Everything is continuous nowadays

61. Continuous Improvement

62. Continuous Integration

63. Continuous Delivery

64. Continuous Release

65. But never heard of
Continuous Project

66. Modern (and agile) software
development should abandon the
project model and its legacy

67. Business agility can be really achieved
only by removing the project model
(and jargon) wherever and whenever
possible

68. Focus your efforts on the evolution
of your product portfolio (including
adding new products)

69. … bring the work to (existing)
teams, with the right priorities

70. … and scale up when and if needed

71. Some suggestions on the top 5

72. 5. Disposable ad-hoc teams
4. Project Model focus on the wrong things
3. Projects have expiration date
2. Project foster silos
1. The Agile Project oxymoron

74. A team dealing with multiple products
is far better than several little
disposable ad hoc teams

75. Manage a team backlog
(through a team Products Owner)

76. It’s not a matter of Happiness
It’s just plain f***ing money
(and money can’t buy happiness anyway)

78. Project success focus on the wrong things
(what is measurable, not what is valuable)

79. Indeed, the goal is to create value,
for the customer, for the organization and
for society as a whole

80. Instead of asking
“How much it costs?”
ask
“What is worth”

82. Why in the hell should we manage a
long lasting thing with ephemeral stuff
named projects?

83. Living products have long
lists of requests waiting to
be implemented
(and new ones will arise
continuously during their
lifetime)

84. Don’t be afraid of having
unallocated people and teams.
They won’t

85. BTW
There’s no better place for maintaining
a software product than in the team
that created it

87. You will probably not be able to shut
down organizational silos, but at least
try to remove them in the software you
implement

88. Be lean

89. Be lean by adopting system thinking
and global optimization

90. Be lean in portfolio management
(you might think of stealing the probably best
part of SAFe)

92. No real suggestions, just think twice
before using agile and project in the
same sentence
;)

93. Oh no, I’m a Project
Manager

94. There is still room for
projects and the project
model

95. In some cases
the project model is
still the best fit

96. For everything else
there are
Products, Teams and #noprojects

97. References

98. Project Myopia: Why projects damage software #NoProjects
Allan Kelly, 2018

99. Continuous Digital: An agile alternative to projects for
digital business
Allan Kelly, 2018

100. #noprojects: A Culture of Continuous Value
Evan Leybourn, Shane Estie, 2018

101. Follow #noprojects on twitter and on Slack

102. Questions?

103. https://www.linkedin.com/in/dimitri-favre-088675/
@DimitriFavre
Dimitri Favre
Thank you