#noprojects: Live happily ever after without projects
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 50 | |
| Author | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/55172 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language | ||
| Production Year | 2019 |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Plone Conference 201920 / 50
5
8
10
11
14
16
17
25
26
27
28
29
32
34
35
36
37
41
42
44
46
49
50
00:00
Plane (geometry)Kolmogorov complexitySystem programmingAbstractionSoftwareDigital rights managementModemKeilförmige AnordnungSpecial unitary groupMusical ensembleSpeech synthesisSoftwareFeedbackContext awarenessBitComputer hardwareSystems integratorExpert systemSoftware developerProduct (business)Software industryLevel (video gaming)CodeData managementState of matterUniqueness quantificationWordCharacteristic polynomial1 (number)Focus (optics)Self-organizationProjective planeRevision controlAnalytic continuationWeb pageService (economics)ResultantCoroutineTransformation (genetics)View (database)WebsiteCone penetration testJSONXMLComputer animationMeeting/Interview
09:32
Plane (geometry)Smith chartVector potentialLocal GroupData modelKeilförmige AnordnungSoftwareInclined planeStrategy gameMultiplication signPoint (geometry)Projective planeCurveView (database)SoftwareProduct (business)CodeData miningFactory (trading post)Different (Kate Ryan album)Group actionServer (computing)Staff (military)FeedbackSoftware developerMedical imagingFunction (mathematics)WritingSelf-organizationChannel capacityData managementBitMathematicsLevel (video gaming)Strategy gameRight angleImplementationWordStability theoryInstance (computer science)Software maintenanceTheoryParameter (computer programming)1 (number)ResultantOperator (mathematics)Computer programArithmetic meanMetre
18:34
Strategy gameDigital rights managementPlane (geometry)Computer configurationDialectProduct (business)Analytic continuationData miningProjective planeService (economics)Perfect groupObject (grammar)Self-organizationComplex (psychology)Strategy gameStability theoryInformationFlow separationData managementSoftwareScaling (geometry)CASE <Informatik>Software frameworkFeedbackException handlingLine (geometry)DigitizingSoftware developerInstance (computer science)Validity (statistics)MappingDiscounts and allowancesElectronic mailing listLevel (video gaming)Moving averageGame theoryRule of inferenceBridging (networking)Computer animation
27:36
Web pagePlane (geometry)PlastikkarteVector potentialProduct (business)Different (Kate Ryan album)Function (mathematics)Perspective (visual)Data managementAnalytic continuationKey (cryptography)Reading (process)Projective planeLevel (video gaming)Web pageComputer animation
29:08
Plane (geometry)Sinc functionUniform boundedness principleSelf-organizationDifferent (Kate Ryan album)Projective planeStrategy gameView (database)Point (geometry)Computer animation
30:58
Pointer (computer programming)Game theoryPower (physics)ResultantVideo gameFacebookSmartphoneTwitterMultiplication signNumberDemosceneSoftware developerInstance (computer science)MathematicsLimit (category theory)View (database)Internet forumProduct (business)Self-organizationDecision theorySystems integratorMetric systemTheoryGoodness of fitSet (mathematics)Software testingProjective planePoint (geometry)CASE <Informatik>Focus (optics)Game controllerStrategy gameData managementFrame problemCentralizer and normalizerMixed realityLecture/ConferenceMeeting/Interview
37:27
Point (geometry)QuicksortView (database)Product (business)SoftwareSelf-organizationComputing platformDifferent (Kate Ryan album)CodeProjective planeInstance (computer science)CASE <Informatik>BitHuman migrationMultiplication signCanadian Mathematical SocietyMathematicsLine (geometry)Strategy gameData managementValidity (statistics)Order (biology)Program slicingMusical ensembleSoftware frameworkClassical physicsMereologyWordFrame problemElement (mathematics)Beat (acoustics)HypothesisShift operatorUniverse (mathematics)Meeting/Interview
43:56
Plane (geometry)Point cloudExpert systemKolmogorov complexitySystem programmingAbstractionVideoconferencingMusical ensembleJSONXMLComputer animation
Transcript: English(auto-generated)
00:00
Thank you everybody for joining the speech. Today we are going to talk about the projects and in a while I will explain why I think that we can live
00:26
happily ever after without projects. So is it a talk about know something a tag sorry yes it is and I have to give a few comments Massimo introduced me
00:48
with several roles my current role is an agile and transformation coach sometime executive coach also for four years I work at the you know system integrator
01:01
and my daily routine was to work on projects and I was unhappy we have we had several problems that I will try to explain during this talk actually I'm a developer as I told to many of my friends I've born as a developer and as
01:27
any smoker a developer will die being a developer even if he doesn't code for a while or for years just like me so I am a developer inside and also an agile coach and I will die as a developer and I don't like projects I give you a
01:47
bit of context in 2011 Mark Anderson the founder of Netscape among other things said that software is eating the world what he meant was that any
02:02
company is a software company think of it car manufacturers are software companies think of Tesla Tesla is a huge hardware for running their software it's very expensive hardware banks run on softwares insurance any
02:25
company in 2020 is a software company software is running the world is not only it in the world and in this context as has been said by Steve
02:41
agile is eating the world you remember the agile manifesto said before the values and principles that we are uncovering and they say still uncovering better ways of developing software by doing by helping others doing it and it works because agile organization are the ones that faster
03:09
that are the fastest to adapt to a continuously changing world did you ever heard of you see a economy anyone who knows Buka Buka stands for volatile
03:29
uncertain complex and ambiguous our word as these characteristics and the ability to survive and thrive in this world is to adapt faster okay about
03:44
projects maybe my opinion is not as strong as the opinion of Martin Fowler that a little bit more than one year ago in the state of agile in Australia said that we have to get rid of software projects as a notion and we
04:07
have to switch to a product oriented the view of the world and organize product team around that things that are more lasting than a project okay so
04:22
what is the project by the way how many of you are project managers is there any okay how many of you works carry are currently working on a project okay a lot of you so why are you going I are you willing to leave
04:44
working with projects do you or do you like working on projects how many of you like working on projects free how many of you don't like okay how many of you don't care about working on projects just be to check if anyone
05:04
has answer okay thank you what is a project for the purpose of this discussion I think that we have to go to the most known definition the most known definition is given by the product management Institute who said
05:23
you can there is the screenshot of the page that you can find on the project management Institute website what is project management is defined that instead of what is a project a project is a temporary and behavior
05:41
undertaken to create a unique product service or result and then we have a problem here because software products are not temporary I would say that they are forever until you decide to dismiss them okay but you still treat
06:03
them with ephemeral things like projects and that's where we might go on on the definition because among the things that you can read on the PMI Institute is that when you start the project you assemble a brand new team of
06:23
people who potentially never work it together and start making the project and as soon as the project ends you dismiss the team well we will go back on this topic you know in a while now what is the no projects sorry I
06:44
no projects I would define it as deliberate deliberate act of continuous product management what I mean is that is more in is more interesting and important to focus on the product instead of the way we
07:05
build the product because the product will last much longer than the effort that we take to build the first release of the product and then the next release of the product and so it's continuous product management it's
07:21
not just we release the first version and then goodbye so the first step is to switch from a project to a product mindset by the way this is being advocated by many people also by at least the free of the signers of the
07:43
agile manifesto one is Martin Fowler the other one is my cone and the third is Jim I Smith that recently published the book in which tells the same things so how do we live projects I suggest to move in just like in a journey in four
08:05
stages okay so we welcome up sorry for the bad and drawing in which the first stage is to go to expert to value experiments over projects the
08:23
second stage is to focus on stable teams over temporary and heavier the first stage is to focus on outcomes instead of execution and the fourth and last stage is to focus on products instead of software this might be a bit
08:46
contradictory but we will see it in a way you know let's start from the first stage experiments over projects in the last years we had let me see the
09:05
focus I shifted on making quick experiments and having feedbacks shortening the feedback loop making experiments is much better than making projects because if you fail an experiment what you have is a learning
09:23
if you fail a project what you have is a failure okay so let's focus on experiments I would cite Richard Feynman who say that it doesn't matter how beautiful your theories it doesn't matter how smart you are if the
09:43
experiment doesn't agree with sorry if the assumption the theory doesn't agree with the experiment it is plainly wrong and we have to remember that when we make a project when we make a softer product the biggest assumption that we have to challenge to demonstrate is that the requirements the
10:03
feature that we are supposed to put in the software are the ones that our customer needs and want but when we make a project we definitely focus on the features on the requirements by the way requirements in means something
10:23
that is required that means all also mandatory okay so there is no negotiation or requirements if you stick on the words the approach is the that Eric Ries discussed in those two books the Lean startup and I prefer the
10:46
stop that way that is how organization that are not startup can leverage experimentation and quick feedback loops to gain a better results
11:02
with the market the second stage was about the stable teams hover temporary and ever I would refer to to something that is well known when you have a winning team you don't change the winning team you try to keep it this
11:21
is being described with a couple of curves that are very similar the first was made in the 60s when you put a group of people together the performance initially decrease and then after the team starts understanding
11:45
each other they reach the tipping point and then start to perform a different point of view has been given by Katzenberg as meter more recently and when you put people together it's not a team it's a working
12:02
group you have a team after a lot of time and so if you stick by the definition and actually it's what happens in many situation when you start the project you assemble a new team and this new team has to go down to
12:20
the valley of the performance and start reaching the performance level while they are approaching the end of the project that as soon as they reach the end of the project they are a performing team you dismiss them you dismiss the team it's crazy my opinion products over software sometimes
12:46
developers like me are more focused on technicalities of being cool in writing the new technologies new staff writing supposedly cool solutions
13:05
genius solution the it's a bit nerdy and so they are more focused on writing excellent code than on writing excellent products and this is a mistake the technical excellence to which the Jmanifest refers to in the
13:25
principles is not about writing the best software possible but writing the best software product possible okay so it writing a solution that the customer will use not to write in the best technical software that no one
13:41
will use by the way in Agile atelier there is a problem I say atelier instead of factory because a friend of mine said that factory means that we are industrializing software which is not okay there is a lot of craftsmanship in software so in Agile atelier a good PO should drive
14:05
should drive sorry the team to write software that someone will use the first stage is outcomes over execution execution in projects is focused on
14:21
outputs one of the problems is that when you make when you run a project you are focused on releasing outputs in the producing bits of software which out being sure that someone will like it there is no care for value
14:41
once you frozen the requirements even agile factories have the same problems then you focus on outputs and no more on what is really important that is outcomes that is the ability to change the behavior of our customer and user this is much more important that writing everything that was in the
15:05
backlog okay the first stage is not enough so I I think that it's useful to have also some guiding principles to help the rich in the no projects
15:27
situation project world first of all organizations should be able to found capacity instead of found in the scope when you when an organization needs
15:41
to make a new development a new product the first thing that they have to do is to list what is what is supposed to be included in the product writing a scope and then have the scope approved and the budget release it to that scope instead if you found capacity you let the team and the
16:07
organization free to adapt to changes and having a performing team that is able to switch from a product to another to change priorities to move to
16:20
new targets and goals of the organization okay the second principle which is somehow difficult to implement is that there is no better place to evolve and maintenance of the program product then in the team that
16:40
created it of course it is if someone wrote the software is the right people to give a look and solve the problems on the on the software but this is not always easy to do and because for instance one of the argument is
17:02
that maintenance is operational expenditures while development is capitalization expenditures but there are ways to manage these so the third thing is to bring the work to the team when you manage projects by the book what you
17:26
have is that you create work okay and then you assemble team and you bring team to the work so first you have to work to find the work and then you have to bring people to that work instead it's much better to keep team
17:44
stable as we said earlier and bring a new or upcoming work to the existing teams is much more effective and efficient to enable some of the guiding
18:03
guiding principles that we have stated so far we have to apply a lean portfolio management strategy which is not a project portfolio strategy it's a product portfolio strategy we have to slice our product initiatives in tiny
18:22
pieces that can be prioritized just like you do on the backlog but at the higher level and you have to review the project portfolio let's say at least once a month or once a quarter and then change and adapt your strategy
18:43
for the very same reason you have to be lean with budget if you discuss yearly budget you have a problem you are let me say chaining the organization for one year I would say even more than one year because when
19:03
you start making budgets it's three four five six months before and to gather information to prepare a budget request you have to work a few months earlier and make a lot of assumptions which are probably no more true when you
19:23
have the money to spend so you have to be more lean with budget this is of course a corollary of what we have discussed about teams and what Martin Fowler said we have to organize products around stable motivated
19:45
and accountable teams scaling a lot of people discuss about scaling there are a lot of scaling frameworks right now that are being discussed in the socials
20:01
I'm not going into the discussion of which is the best scaling framework scaling with probably the exception of Scrum at scale is mainly a matter of the size of the product you have to develop it's not a matter of the size of the organization many organizations start to scale just
20:21
because they are big they don't they have to scale if their products are big and probably not even in this case it's more interesting to focus on the scaling instead of scaling and since the scaling increase the complexity you have to scale just if and when needed when you decide to move to
20:50
a product initiative you have to ask is it worth making this product not how much it cost because when the question is how much it cost it's very easy for
21:08
CFO and project manager and business line managers to have the Black Friday syndrome okay it's cheap I'll buy it okay it's a huge discount I'll buy it and make it I make this product I make this but no one cares about is it
21:26
worth how many of you have useless things both on the Black Fridays staying at home maybe you recycle them at Santa's as a gift to your not so best friends okay keeping the feedback loop short is critical when you make a
21:49
product you have to validate your assumptions as soon as possible and so you have to not necessarily make continuous release but at least you have
22:05
you have to have a way to validate your assumption continuously through an approach that probably in the end could be continuous release one of the major problem even in agile atelier is that road maps are builds on
22:23
features when you make a roadmap if you follow let's say the use the story mapping approach whatever Jeff Martin Roman pitch layer approach is to build in a roadmap what you and what you will have to have is a list of feature
22:45
you expect for every milestone this is kind of waterfall I mean you are just saying that this feature will be available within a specific date what I suggest instead is to focus on defining which needs we want to address
23:09
by each of the milestone in the roadmap so let's see for instance that we are on the 31st of October by January 2020 we want to have people being able to
23:25
work with without projects in that organization this is a need is a desire maybe this is not the feature that enable this desire this give the teams the product teams which is not just the development team the freedom to
23:42
choose the best way to address those needs and to discuss with the customers and validate with the customers that the solution they are bringing on are the solution that the customer actually needs okay so what is in the
24:02
project once again is continuous product management okay it's I'm just checking okay it's okay we need to focus on products not on projects someone
24:28
argues that do you remember the definition of projects that I give at the beginning of the talk a project is a temporary endeavor to create a unique product so since you say that projects be the product you read also
24:45
on the contrary that products are built by projects but we don't need projects to build the software products a friend of mine recently switched to a different company and his role is to be service owner he has several products is a big
25:08
company with several brands and the products that my friends manage are customized for the different brands of the organization and he said you know
25:20
Dimitri I stopped making projects I just asked the budget for the whole year to found a team to manage the product because it was easier for us and you know what happened the CFO didn't have any objection to that and
25:41
I was quite surprised and most of all one of the brand changed the CEO just a couple of months after we switch to a product mindset and instead of following the projects approaching which the request for the former CEO would
26:00
have been approved in a project a budget allocated for this initiative and then we had to continue working on this project I could just switch to the new goals of the new CEO without asking anyone and I was able to give
26:22
him an answer in a couple of weeks instead of months that is he didn't know anything about new projects by the way and they say great Ciro this is new projects and Andy said what are you talking about but okay
26:44
Antoine de Saint-Exupéry once said that perfection is achieved when there is nothing more to take away instead of add we want to simplify the way
27:02
software products and digital services which are built on top of software products are built and so what I'm suggesting is to stop making projects and leave happily ever after we've have the pains of the projects
27:26
okay I give you a few references on this topic in 2018 three books have been written two by Alan Kelly project myopia and continuous digital because
27:46
one of the discussion that there has been on the social and it is still still active is about the use of the usage of no why are you saying no what is your proposal the proposal of Alan is continuous digital my proposal is
28:01
continuous product management we are pretty on the same page but we have something different she nasty and Ellen even a layburn wrote the book no projects which you can download on if you for for free or you can buy on Amazon also interesting readings also project to product the lean startup I
28:28
already discussed it on that beyond budgeting very interesting because it's one of the key to switch on the finance level from a project to a product
28:42
mindset Steve Denning the age of agile a different perspective on agility which is different from capital a agile outcomes over output is an interesting book which discuss almost the same of the I don't remember if
29:01
principle which is outcomes over execution okay and then the release candidate of my book you can take it on the limb pub and rented this book since February I'm working on this topic since one year and a half so if
29:21
you want to participate give him feedback on the talk or also on the that are written on this book you can you can and then questions okay I'm arriving hi so my question is simple as we see that most people don't like
29:55
project and it seems to be not that efficient why are we still using it in
30:00
the vast majority of company sorry can I repeat because I'm a little bit deaf and so I cannot hear you so why do we use project as a work strategy instead of those kind of strategy you have been describing since he's not to be satisfying is not to be efficient as well why do we stick with that
30:25
okay if I got your question I don't know why we are using project maybe because we are because we are used to to make projects maybe because we are I
30:40
I think I think you have to take these from different point of view big organization make projects because they have decided to outsource their IT capability they don't have the capability of to buy the capability and they don't want to risk to buy more capability than they need they still
31:01
prefer to have projects to keep things under control and this is a problem because many big organization became a project centric instead of product centric and so they are not able to satisfy their customer either internal or external customers because they don't focus on products we use projects
31:23
in some case because the CFO asked us for making projects and there is another situation in which projects are probably the only way to go if you are a system integrator what you are going to sell is a project which is kind of
31:41
weird because no one will buy a project actually I would buy the final result of the project but instead there is someone who sells me a project and I will buy the project not the product this is kind of problematic in my opinion this is a situation which cannot be solved easily but I worked
32:06
with a couple of system integrators that are starting selling the team instead of selling the individuals that are building the projects which is a minor change from central point of view because you are still selling a
32:23
project but it's a big change because you are selling the performance of a high performing team that is working continuously together on different projects during the time so we have different situation I have a discussion I had a discussion you can also find it on Twitter because it was a public
32:43
discussion for instance with someone who said that for compliance reason you have to have a project for accountancy reason you have to have a project I don't think so the CFO in Italy at least to which I discuss with which I
33:02
discuss the topic we are not in agreement with but maybe in other countries it can be an issue any other questions anybody else okay I have a question for you how people what are the people feelings
33:25
when you start to talk about experiments and know more about projects who depends it depends people as mixed feelings about this because experiments
33:44
are scenes just like okay let's do whatever you you think just waste our money and who cares about the result if it's if it succeeds it's okay if it
34:00
it's not okay but who cares we are we have founded an experiment so for us it's okay but making experiments especially when you have a product on the wide on the market it's not that easy I give you an example Candy Crush how many you know of Candy Crush Candy Crush saga okay it's a game on
34:24
smartphones and also on Facebook I think how a couple of months ago they make a change they made an experiment and this was declared in one of the support forum of Candy Crush Candy Crush gives you some limits on the
34:42
number of lives you have to play the game a new life is given you after half an hour so the experiment that was run by the development team was to give you a life every hour instead of half an hour that means that once you finish your life your life is instead of being able to start again in two
35:06
hours and a half you have to wait five hours and there was a huge complain by the many people's left forever Candy Crush they lost customers
35:21
they are not paying customers they are somewhat some of them buys in up gadgets many of them just see the advertisement but they lost customers because I wrongly made experiments making experience is just not it's not
35:40
doing whatever you want it's making something that is aimed at generating an impact on the customers I've changed behavior of our customers without with good reasons okay so you found on experiments with good reason another thing that is important in experiment is how you define an experiment you have
36:03
to set metrics KPI whatever you have to define how do you measure that your experiment is successful you have to fix a budget and also a time for a time frame in which you want the experiment to be completed once you run an
36:22
experiment after a while you have to decide the experiment confirmed my theory my experiment did not confirm my theory but confirm at the contrary or
36:40
were what the experiment was inconclusive and you have to take decision based on the result if the experiment is inconclusive it's just like the experiment has failed but still you learn something that you didn't know before starting the experiment so there is big value in making experiments instead of having large assumptions and test them after one year two years
37:09
doesn't work okay any other questions sorry one point on the ten principles
37:27
you say ugly and then portfolio management strategy what it means what is the what can you put in the real world okay the when I talk about the
37:41
portfolio management strategy in this case I cite one of the scaling frameworks probably the most hated one which is safe whichever which has some very complicated stuff but there's very good points the portfolio management strategy that is in safe is a good starting point in which you slice
38:06
your product strategy in sorry your products ideas in tiny slices you prioritize in order to have the fastest possible validation of a hypothesis and you prioritize prior by sorry you give the priority of the
38:25
product steps and the product parts that you want to define classical project portfolio management is different because is mainly focused on the managing what is currently under work what we are currently working so
38:43
you have a huge dashboard of all the projects that have been already started not about what will happen on the future I would focus on what will happen on the future what happened in the past is lessons learned but let's forget it and start again looking at the feature okay okay the last
39:01
question I have a short question about the difference for you between having a concrete product you sell as an company as an institution or on the other hand if you don't have anything concrete so you don't have a
39:22
portfolio element that you can sell but the only element you have is very very abstract so for example the universities they're selling knowledge that's the product they do and therefore product investing continues
39:41
into the product knowledge is totally different and projects tend to have a concrete time frame and that's also an advantage okay so I'm not sure what is the question actually the question is in a product world we have a concrete
40:11
thing you can go beyond the project okay where you go and continuous develop and redefine your product to get better but if you don't have a
40:25
product something that does not change or something changes okay I understand yes there are many software products which are not really products from a
40:45
different point of view there are situation in which making a project is probably the best situation we are in the plug conference so once you have set up the CMS for your customer what did you sell what does the
41:06
customer have Indian in as in his hands he has a product that you are not doing it's a blown community that is developing the product and probably you don't have to manage that product so in this case project is probably most
41:23
appropriate the same applies for instance for migrations when you have to migrate from one version or from one software legacy software to a new software the beats the piece of software the pieces of code that you write to migrate from the old platform to the new platform is a throw
41:43
away I mean that once you reach the goal of migration you don't care about this software anymore it's lost forever it's not useful anymore at the same time the principles that are behind the projects my view of no projects can
42:03
be applied because the team that realized that project can move to another project and at least try to keep some of the things that are important together just just like people okay but you I agree there are situation which projects are still appropriate and you have to decide in
42:26
many cases you can have a product point of view of the world also in large organization which have a lot of line of business software can be seen as a product but for instance one of the major problems that I saw in my
42:46
experience is for instance from for ERP okay ERP are a product from Microsoft SAP and whoever point of view but they are not products from the customer
43:02
point of view they are there is something in the middle because Microsoft and SAP doesn't sell the software to the end customer they sell the software to the partner which make the customization and the customization doesn't change so often but still you have probably to keep the
43:22
an eye on the product because even if it doesn't change so often it changes because the business changes because the company changes because the world surrounding the company changes so even in those case I think that in the coming years a shift to a product mindset is necessary for companies to
43:44
survive not for all of them but little by little it will happen okay thank you for sharing your experience thank you