Traject na oplevering project

[De_Bastaard]

Wij zijn een projectclub van ~30 man die volgens Agile principe apps maken voor diverse klanten. Vaak is het een geval van x-weken met 3-4 man knallen, app opleveren en op naar de volgende.

In een deel van de gevallen blijft het bij de opgeleverde MVP omdat de klant daar blij mee is, in andere gevallen blijft het projectteam na oplevering van het MVP nog x-sprints aanwezig om de app verder uit te breiden.

In de gevallen waarbij de app vrij snel naar support wordt overgedragen, merk ik dat de verdere ontwikkeling van de app stagneert (er zijn bijv. vaak nog genoeg backlog items). Ook de oplossing voor sommige incidenten komen af en toe op de backlog te staan, wat natuurlijk de functionaliteit van de app niet ten goede komt. Wanneer er nieuwe versies van het framework uitkomen worden deze bijvoorbeeld niet automatisch toegepast op de app, terwijl er vaak wel weer nieuwe functionaliteiten bij zitten die voor deze klant handig kunnen zijn.

Op een gegeven moment neemt de klant dan weer eens een sprint af en maken we nieuwe features, oplossingen, e.d.

Waar ik eigenlijk naar toe wil is dat we wat gestructureerder om gaan met het traject ná oplevering om zo de dienstverlening te verbeteren en de app(s) beter te kunnen onderhouden. Een van de problemen waar we dan tegen aan lopen is dat de consultants opzoek zijn naar afwisseling door verschillende projecten te doen en dus niet 2 jaar lang aan dezelfde app willen werken. Een ander probleem is dat de klant soms geen budget heeft om 2-3 man daar te houden voor verdere ontwikkeling - maar misschien wel voor minder man (of tegen lager tarief).

Een van de mogelijkheden die ik aan het bekijken ben is DevOps, maar zoiets moet je als ik het goed begrijp eigenlijk al vanaf het begin introduceren. Je wilt zoveel mogelijk automatiseren (in ons geval het testen van functionaliteiten) om op die manier met zo veel mogelijk iteraties, snel nieuwe functionaliteiten toe te voegen. Een van de uitdagingen hier is dat onze support afdeling klein is (1- 2 man), dus we kunnen niet 'zomaar' een persoon voor x-periode ergens neerzetten zonder dat de support dienstverlening in het nauw komt.

Support heeft in deze dezelfde development skills als de consultants/developers en zijn absoluut niet de gevallen van 'heb je hem al uit- en aangezet'.

Nu zijn er vast tweakers die ook in een klein IT bedrijf werken waar vergelijkbare activiteiten gebeuren. Hoe pakken jullie dit aan? Gebeurt alles vanuit support? Hebben jullie aparte teams die na livegang de boel blijven onderhouden?

[P_Tingen]

Het gaat er natuurlijk ook om waar je klant voor wil betalen. Het is niet heel ingewikkeld om iets te bedenken in de trend van dat je x-uren tot je beschikking hebt per jaar voor onderhoud en dat je die tijd gebruikt om nieuwe frameworkversies te gaan gebruiken of om dingen van de backlog te halen.

Persoonlijk zie ik bij ons ook wel dat er vaak een afwachtende houding is tov klanten. Wij hebben dan meer applicaties ipv apps, maar het idee is hetzelfde. Je maakt een applicatie en gaat vervolgens in de wachtstand tot de klant weer wat roept, iets erbij wil hebben of een nieuwe module bedenkt. Ondertussen gaan al je concurrenten verder en maken een mooiere / betere applicatie dan jij hebt en na een jaar of 5 zegt je klant "ineens" het contract op, om over te gaan op het product van je concurrent. Ik vind dat dom omdat ik denk dat je best een beetje met je klant kan meedenken of eigen initiatieven kan nemen om je klant te prikkelen. Zo hou je jezelf, de klant én de applicatie bij de tijd. Maar zoals gezegd: het moet wel ergens van betaald worden en dat bepaalt hoeveel tijd je daarvoor kan vrijmaken.

[Garyu]

Betalen je klanten een maintenance fee of upgrade fee of iets dergelijks? Verwachten ze dergelijke features? Het is natuurlijk aan jullie om een aanbod te doen aan de klant waar deze mee tevreden is, en ook al vanaf het begin met hem mee te denken. Een klant denkt er meestal niet aan dat er nog een leven na de release is, jullie weten dat wel. In mijn branche is het niet ongewoon dat dergelijke kosten een significant onderdeel van de offerte zijn, zeg 15-20% van de initiele ontwikkelkosten, per jaar (!).

Ontwikkel je dus een applicatie voor zeg 100k€, dan wordt er vervolgens 20k€ per jaar betaald om upgrades, updates en support te ontvangen. Een deel van de kosten die we aan klanten doorberekenen zijn de kosten voor de centrale R&D die alle klanten ten goede komt.

Het is immers zo dat uiteindelijk toch iemand voor de gemaakte uren zal moeten betalen. Is het niet de klant, dan ben jij het (of je baas). En dat laatste schijnt op den duur niet heel goed voor je business model te zijn .

[De_Bastaard]

Bedankt voor de reacties tot dusver.

Momenteel betalen onze klanten een vaste bijdrage per maand op basis van aantal gebruikers om tickets aan te mogen melden, e.d. Vervolgens geldt er een apart tarief voor het oplossen van incidenten/changes - alles gaat op basis van uurtje/factuurtje.

Als ze een sprint willen doen met items van de backlog dan geldt hiervoor het normale consultancy tarief en dan komen er twee developers langs die een sprint uitvoeren.

Dat is vrij reactief en wacht je dus altijd tot de klant bij je aanklopt met feature requests.

Dat vaste (jaarlijks betaalde) bedrag is vele malen lager dan de 15-20% die @Garyu noemde, we moeten het daar echt hebben van de uren die we kunnen factureren.

Een hoger vast tarief zou inderdaad nog niet zo gek zijn want daarmee zou een klant misschien meer geneigd zijn om gebruik te maken van de uren die ze ter beschikking hebben (en al voor betaald hebben). Als je dat verkocht krijgt bij een klant zou je ook structureel meer resources vrij kunnen maken voor dit soort development aangelegenheden ...

[joke_name]

Ik zou eens denken aan een strippenkaart model.

Een klant neem een strippenkaart af voor consultancy dienstverlening.

Hierbij kunnen ze van alles inkopen.
Rapportages, Training, backlog items oplossen, nieuwe functies.

dit gaat allemaal af van de strippenkaart.

Het voordeel van dit systeem is.
1 keer akkoord van directie benodigd voor een X-aantal uur.

Daarna kan je heel kort schakelen.

[Tarkin]

Dus je maakt een app en smijt het dan (na de MVP) over de muur naar een ander team?

Beginnen bij you build it, you maintain it? En per team x aantal projecten hebben. Niet 1 team die de coole nieuwe dingen maakt en dan andere teams die de troep moeten opruimen. Agility stopt niet na de MVP fase he


Hoe je dat doorfactureert aan een klant is een andere zaak.

[Croga]

Tarkin schreef op woensdag 18 april 2018 @ 14:49:
Dus je maakt een app en smijt het dan (na de MVP) over de muur naar een ander team?

Beginnen bij you build it, you maintain it? En per team x aantal projecten hebben. Niet 1 team die de coole nieuwe dingen maakt en dan andere teams die de troep moeten opruimen. Agility stopt niet na de MVP fase he

^^ Dit......

@De_Bastaard je begint je betoog met "volgens Agile principe" maar zodra je zaken over de muur naar "beheer" gooit zijn alle Agile principes al overboord en kun je dus niet meer beweren dat je iets Agile doet....

DevOps is slechts een naampje wat bedacht is omdat bedrijven/mensen Agile niet begrepen. DevOps is de defacto standaard van alles wat Agile is (/Scrum/Kanban/XP/etc.). Het feit dat jullie aparte "beheerders" hebben geeft aan dat Agile bij jullie niet aanwezig is.

In de perfecte wereld is het heel eenvoudig:
- Komt de klant een bug tegen dan hebben jullie iets fout gedaan en los je dit op. Uiteraard kostenloos. Dat is nog eens een incentive om foutloze software op te leveren!
- Heeft de klant een spoed-verzoek voor verandering dan gebruik je het patroon Illegitimus Non Interruptus om daar op in te kunnen spelen.
- Heeft de klant een non-spoed verzoek dan kun je dat inplannen in de sprint die alle stakeholders goed uit komt
- Dit alles wordt door de PO beoordeelt

Wat betreft ontwikkelaars die graag andere dingen willen doen: Óf je staat achter je product, óf je staat er niet achter. Wil je na oplevering zo snel mogelijk iets anders gaan doen dan sta je blijkbaar niet achter je product. Fix it!

En ja, dat betekend dat het goed is om te kijken naar test automatisering, continuous integration, continuous deployment, automated integration en deployment en al die andere moderne software ontwikkel technieken die ook buiten Agile/DevOps/Scrum gewoon heel erg belangrijk zijn.

[Tarkin]

Btw, "we ontwikkelen volgens de Agile principes". Wat bedoel je hiermee?

Je werkt in een Agile mindset en gebruikt Scrum/Kanban/LeSS/SAFe/... als framework? (ik neem aan Scrum?)

Agile is de mindset die je moet hebben, en in die mindset kan je dan ofwel je eigen ding ontwikkelen ofwel al een bestaand framework gebruiken om je complexe producten te ontwikkelen

[Tarkin]

Croga schreef op woensdag 18 april 2018 @ 15:00:
[...]

In de perfecte wereld is het heel eenvoudig:
- Komt de klant een bug tegen dan hebben jullie iets fout gedaan en los je dit op. Uiteraard kostenloos. Dat is nog eens een incentive om foutloze software op te leveren!
- Heeft de klant een spoed-verzoek voor verandering dan gebruik je het patroon Illegitimus Non Interruptus om daar op in te kunnen spelen.
- Heeft de klant een non-spoed verzoek dan kun je dat inplannen in de sprint die alle stakeholders goed uit komt
- Dit alles wordt door de PO beoordeelt

Ik denk dat je de laatste nieuwe versie van de Scrum guide toch nog eens moet doornemen Buffers beginnen plaatsen in een sprint en daar zeker niet overgaan klopt niet meer. Zeker niet aangezien de sprint backlog geen commitment is, je commit je enkel tot de sprint goal.

[ToolkiT]

joke_name schreef op woensdag 18 april 2018 @ 14:22:
Ik zou eens denken aan een strippenkaart model.

Een klant neem een strippenkaart af voor consultancy dienstverlening.

Hierbij kunnen ze van alles inkopen.
Rapportages, Training, backlog items oplossen, nieuwe functies.

dit gaat allemaal af van de strippenkaart.

Het voordeel van dit systeem is.
1 keer akkoord van directie benodigd voor een X-aantal uur.

Daarna kan je heel kort schakelen.

Een soortgelijke constructie gebruikte in bij mijn vorige baan ook. Mijn team (Support/Managed services) deed break-fix problemen en klanten konden een 'pool of days' kopen voor kleine enhancements. Als iets complexer werd (meer dan x dagen werk) dan werd er een project opgezet (dat los betaald werd).
Zoals je al zei is dit ideaal qua approval process en budgets etc.. want aan begin van het jaar heeft de klant al OK om werk te laten doen zonder dat voor elk wissewasje een approval van hogerop hoeft te komen..

[Croga]

Tarkin schreef op woensdag 18 april 2018 @ 15:08:
Ik denk dat je de laatste nieuwe versie van de Scrum guide toch nog eens moet doornemen Buffers beginnen plaatsen in een sprint en daar zeker niet overgaan klopt niet meer. Zeker niet aangezien de sprint backlog geen commitment is, je commit je enkel tot de sprint goal.

Tsja... als ik moet kiezen tussen luisteren naar de Scrum Guide of naar degenen die de Scrum Guide schrijven dan doe ik liever dat laatste..... Illegitimus Non Interruptus is specifiek door Jeff Sutherland geschreven en door 13 andere Scrum gurus van het eerste uur gereviewed. Wat heb je liever; de simpel version of degene die inhoudelijk voorzien is van visie, doel en details?

Overigens is de Sprint Backlog nooit een commitment geweest......

[ Voor 4% gewijzigd door Croga op 18-04-2018 15:15 ]

[De_Bastaard]

Oke, ik moet even een aantal zaken verduidelijken geloof ik :-)

Tarkin schreef op woensdag 18 april 2018 @ 15:04:
Btw, "we ontwikkelen volgens de Agile principes". Wat bedoel je hiermee?

Je werkt in een Agile mindset en gebruikt Scrum/Kanban/LeSS/SAFe/... als framework? (ik neem aan Scrum?)

Agile is de mindset die je moet hebben, en in die mindset kan je dan ofwel je eigen ding ontwikkelen ofwel al een bestaand framework gebruiken om je complexe producten te ontwikkelen

We gebruiken inderdaad SCRUM.

Croga schreef op woensdag 18 april 2018 @ 15:00:
[...]

^^ Dit......

@De_Bastaard je begint je betoog met "volgens Agile principe" maar zodra je zaken over de muur naar "beheer" gooit zijn alle Agile principes al overboord en kun je dus niet meer beweren dat je iets Agile doet....

DevOps is slechts een naampje wat bedacht is omdat bedrijven/mensen Agile niet begrepen. DevOps is de defacto standaard van alles wat Agile is (/Scrum/Kanban/XP/etc.). Het feit dat jullie aparte "beheerders" hebben geeft aan dat Agile bij jullie niet aanwezig is.

In de perfecte wereld is het heel eenvoudig:
- Komt de klant een bug tegen dan hebben jullie iets fout gedaan en los je dit op. Uiteraard kostenloos. Dat is nog eens een incentive om foutloze software op te leveren!
- Heeft de klant een spoed-verzoek voor verandering dan gebruik je het patroon Illegitimus Non Interruptus om daar op in te kunnen spelen.
- Heeft de klant een non-spoed verzoek dan kun je dat inplannen in de sprint die alle stakeholders goed uit komt
- Dit alles wordt door de PO beoordeelt

Wat betreft ontwikkelaars die graag andere dingen willen doen: Óf je staat achter je product, óf je staat er niet achter. Wil je na oplevering zo snel mogelijk iets anders gaan doen dan sta je blijkbaar niet achter je product. Fix it!

En ja, dat betekend dat het goed is om te kijken naar test automatisering, continuous integration, continuous deployment, automated integration en deployment en al die andere moderne software ontwikkel technieken die ook buiten Agile/DevOps/Scrum gewoon heel erg belangrijk zijn.

We werken wel volgens SCRUM. Misschien was het in mijn OP niet helemaal duidelijk, maar we maken voor elke klant andere software. Geen enkele van onze klanten heeft een app die lijkt op die van een andere klant. Elk app die we doen wordt gedaan volgens SCRUM.

We komen in contact met klant X die een bepaalde app wilt. Wij maken die app met een klein team en zodra de app live staat en/of de klant tevreden is gaan we door naar de volgende klant. Op dat moment houdt het SCRUM team dat op dat moment aanwezig was ook op te bestaan. De consultant(s) kunnen weer in een ander SCRUM team terecht komen bij een totaal andere klant.

Je blijft als consultant/developer toch niet altijd het aanspreekpunt voor een project 'lang' geleden is afgerond - of begrijp ik het nu verkeerd?

[Croga]

De_Bastaard schreef op woensdag 18 april 2018 @ 20:43:
We werken wel volgens SCRUM. Misschien was het in mijn OP niet helemaal duidelijk, maar we maken voor elke klant andere software. Geen enkele van onze klanten heeft een app die lijkt op die van een andere klant. Elk app die we doen wordt gedaan volgens SCRUM.

We komen in contact met klant X die een bepaalde app wilt. Wij maken die app met een klein team en zodra de app live staat en/of de klant tevreden is gaan we door naar de volgende klant. Op dat moment houdt het SCRUM team dat op dat moment aanwezig was ook op te bestaan. De consultant(s) kunnen weer in een ander SCRUM team terecht komen bij een totaal andere klant.

Je blijft als consultant/developer toch niet altijd het aanspreekpunt voor een project 'lang' geleden is afgerond - of begrijp ik het nu verkeerd?

Jullie geruiken duidelijk niet het Scrum (1 hoofdletter) framework. 1 van de basis regels in Scrum is dat je in een langdurig stabiel team werkt, dat doen jullie niet. Een andere is dat dat team verantwoordelijk blijft voor het product totdat het product niet meer gebruikt wordt. Ook dat doen jullie niet.

Ik ken hele goede manieren om jullie bedrijf veel succesvoller te maken maar een forum is daar veel te beperkt voor. Je gaat je probleem dus ook niet kunnen oplossen zolang je niet echt met Scrum aan de slag gaat. Je kunt lapmiddeltjes er op plakken maar dat gaat je erg weinig opleveren.

Tip:
- Stop met het uurtje/factuurtje
- Ga echt klantwaarde leveren in plaats van handjes
- Profit! (maar dan echt)

[Yucon]

De_Bastaard schreef op woensdag 18 april 2018 @ 20:43:
We werken wel volgens SCRUM. Misschien was het in mijn OP niet helemaal duidelijk, maar we maken voor elke klant andere software. Geen enkele van onze klanten heeft een app die lijkt op die van een andere klant. Elk app die we doen wordt gedaan volgens SCRUM.

We komen in contact met klant X die een bepaalde app wilt. Wij maken die app met een klein team en zodra de app live staat en/of de klant tevreden is gaan we door naar de volgende klant. Op dat moment houdt het SCRUM team dat op dat moment aanwezig was ook op te bestaan. De consultant(s) kunnen weer in een ander SCRUM team terecht komen bij een totaal andere klant.

Je blijft als consultant/developer toch niet altijd het aanspreekpunt voor een project 'lang' geleden is afgerond - of begrijp ik het nu verkeerd?

Hebben jullie als bedrijf functioneel verstand van de apps in kwestie?

[De_Bastaard]

Croga schreef op woensdag 18 april 2018 @ 22:14:
[...]

Jullie geruiken duidelijk niet het Scrum (1 hoofdletter) framework. 1 van de basis regels in Scrum is dat je in een langdurig stabiel team werkt, dat doen jullie niet. Een andere is dat dat team verantwoordelijk blijft voor het product totdat het product niet meer gebruikt wordt. Ook dat doen jullie niet.

Ik ken hele goede manieren om jullie bedrijf veel succesvoller te maken maar een forum is daar veel te beperkt voor. Je gaat je probleem dus ook niet kunnen oplossen zolang je niet echt met Scrum aan de slag gaat. Je kunt lapmiddeltjes er op plakken maar dat gaat je erg weinig opleveren.

Tip:
- Stop met het uurtje/factuurtje
- Ga echt klantwaarde leveren in plaats van handjes
- Profit! (maar dan echt)

Nou, gedurende het project is het team stabiel en vast. Zijn er toch wisselingen, dan worden er die sprint minder punten opgepakt.

Op een gegeven moment is de app klaar of zijn de sprints 'op'. Dan houdt het team toch ook op te bestaan? Idealiter kan het in dezelfde samenstelling nog eens samenkomen wanneer er een of meerdere sprints gedaan moeten worden.

Als ik het goed begrijp hoort er dus helemaal geen aparte support afdeling te zijn, maar dan ga je er van uit dat de klant jarenlang een team inhuurt terwijl er niet genoeg werk ligt?

[Croga]

De_Bastaard schreef op woensdag 18 april 2018 @ 23:59:
Nou, gedurende het project is het team stabiel en vast. Zijn er toch wisselingen, dan worden er die sprint minder punten opgepakt.

Op een gegeven moment is de app klaar of zijn de sprints 'op'. Dan houdt het team toch ook op te bestaan? Idealiter kan het in dezelfde samenstelling nog eens samenkomen wanneer er een of meerdere sprints gedaan moeten worden.

Wat jullie hier gedaan hebben is de klassieke project structuur voorzien van een Scrum sausje. Je hebt de "bouw" phase in Prince2 in sprints ingedeelt en dat Scrum genoemd. Maar zo werkt het niet....

Stel je even de vraag: Hoe lang duurt zo'n "project" bij jullie? En dan de vraag: Hoe lang doet een team er over om de "Performing" fase van het Tuckmann model te bereiken? Die laatste kan ik wel voor je beantwoorden; over het algemeen 6 maanden. Iedere keer dat je het team verandert beginnen die 6 maanden van voor af aan (ik weet; dat is een versimpeling maar uitgebreidere analyses vergen meer dan een forum). Dat betekend dus dat je nooit tot een high-performing team komt omdat je continue opnieuw aan het stormen bent in plaats van te performen.

En "later samen komen" heeft daar ook weer geen effect op; het team is opgebroken geweest en begint dus weer opnieuw.

Als ik het goed begrijp hoort er dus helemaal geen aparte support afdeling te zijn, maar dan ga je er van uit dat de klant jarenlang een team inhuurt terwijl er niet genoeg werk ligt?

Ook hier zie je weer het Prince2 model terug komen. Het concept "Build" vs. "Run" is veroudert. Er bestaat geen "support", er is alleen het werk wat er aan een product gedaan moet worden. Dus nee, er bestaat geen support afdeling, er is alleen maar je product. En dat wordt door een team verzorgd. Er staat nergens dat het team niet ook andere producten kan verzorgen.....

Als je echt de Agile mindset wilt toepassen moet heel je business model op de schop. De Agile basis is hier al niet goed. Denken in producten, werken als aparte "build" en "run", de mensen naar het werk brengen in plaats van andersom.....

[Tarkin]

De_Bastaard schreef op woensdag 18 april 2018 @ 23:59:
[...]


Nou, gedurende het project is het team stabiel en vast. Zijn er toch wisselingen, dan worden er die sprint minder punten opgepakt.

Op een gegeven moment is de app klaar of zijn de sprints 'op'. Dan houdt het team toch ook op te bestaan? Idealiter kan het in dezelfde samenstelling nog eens samenkomen wanneer er een of meerdere sprints gedaan moeten worden.

Als ik het goed begrijp hoort er dus helemaal geen aparte support afdeling te zijn, maar dan ga je er van uit dat de klant jarenlang een team inhuurt terwijl er niet genoeg werk ligt?

Je geeft projecten aan stabiele teams (= teams die idealiter jaren bijeen zijn). Je bouwt geen teams rond projecten.

Het is niet erg om een team 7 verschillende maintenance projectjes te geven en dat ze dan tussen door nog een greenfield erbij opnemen. Van die 7 maintenance weten ze op dat moment ook heel goed wat er belangrijk is om snel te fixen en wat niet. Dat zal veel sneller gaan dan iedere keer je project in maintenance modus gaat het aan een ander team assigneren en dan zelf iets nieuws opstarten.

Bij een oud project van me was het zelfs zo erg dat het maintenance team op een gegeven moment een sterfhuis was. Iedereen die naar daar "verbannen" werd was weg na ong een half jaar.Het was ook niet raar te vinden als je van het "sterrenteam" (waar alle latest and greatest zaken gedaan worden) naar het "kneusjesteam" verzet werd. Meestal ook nog eens zonder inspraak of zonder communicatie.

Ik zou zeggen focus daar eerst eens op en je gaat merken dat je al verbetering krijgt, er zijn nog heel wat andere domeinen natuurlijk maar zoals croga zegt, beter een goede coach zoeken die een tijdje meedraait daar.

Wat betreft de andere discussie, er zijn ook al wat gevallen bekend van signing members die nu zeggen "boy I was wrong there", zelfs met halve boeken die ze toen geschreven hebben. Iets met voortschrijdend inzicht en continuous learning . Dus nee, voor mij zijn die drie woorden latijn die je geeft niet iets wat ik nog zou willen gebruiken/implementeren als dit is de waarheid. Maar dat is een andere discussie die niet in dit topic hoort

[Ryangr0]

Misschien begrijp ik het niet goed, maar als je businessmodel gebaseerd is op software schrijven op projectbasis voor verschillende klanten, en je niet per project een nieuw team aanneemt, kun je die projecten toch niet maar altijd blijven supporten zoals je natuurlijk wel zou doen met een SaaS model zoals hier door sommigen geschetst wordt? Dan ben je binnen de kortste keren klaar omdat je geen capaciteit meer in kan zetten op nieuwe projecten (waar je je geld vandaan haalt).

Scrum leent zich m.i. per definitie niet voor dit soort app fabrieken, dus het verbaast me ook niet dat de OP niet volledig aan het framework voldoet.

[rvrbtcpt]

De_Bastaard schreef op woensdag 18 april 2018 @ 23:59:
[...]


Nou, gedurende het project is het team stabiel en vast. Zijn er toch wisselingen, dan worden er die sprint minder punten opgepakt.

Op een gegeven moment is de app klaar of zijn de sprints 'op'. Dan houdt het team toch ook op te bestaan? Idealiter kan het in dezelfde samenstelling nog eens samenkomen wanneer er een of meerdere sprints gedaan moeten worden.

Als ik het goed begrijp hoort er dus helemaal geen aparte support afdeling te zijn, maar dan ga je er van uit dat de klant jarenlang een team inhuurt terwijl er niet genoeg werk ligt?

Volgens mij mist er een nuance en jij of iemand anders gaf dat ook al aan in een andere post.
De klant gebruikt je product x aantal jaren en dan gaan ze naar de concurrent.
Tevens hebben ze geen geld voor een heel team.
Maar wie zegt dat beiden gerelateerd zijn? Je klant wil misschien support en tevens op de hoogte gehouden worden van nieuwe ontwikkelingen, mogelijkheden en een advies van een expert in de markt zodat nieuwe kansen zichtbaar worden. En dan heb je ook weer een businessmodel voor een nieuwe investering.
Dat zou een consultant kunnen doen in een rol waarbij hij toch regelmatig klant contact heeft maar niet perse om de bestaande app aan te passen. Je wil je klant toch houden en zodat je er na een tijdje weer een nieuw project kan doen.

[ Voor 3% gewijzigd door rvrbtcpt op 19-04-2018 09:02 ]

[Garyu]

Ryangr0 schreef op donderdag 19 april 2018 @ 08:44:
Misschien begrijp ik het niet goed, maar als je businessmodel gebaseerd is op software schrijven op projectbasis voor verschillende klanten, en je niet per project een nieuw team aanneemt, kun je die projecten toch niet maar altijd blijven supporten zoals je natuurlijk wel zou doen met een SaaS model zoals hier door sommigen geschetst wordt? Dan ben je binnen de kortste keren klaar omdat je geen capaciteit meer in kan zetten op nieuwe projecten (waar je je geld vandaan haalt).

Scrum leent zich m.i. per definitie niet voor dit soort app fabrieken, dus het verbaast me ook niet dat de OP niet volledig aan het framework voldoet.

Hoewel de apps allemaal custom software is, betekent dat niet automatisch dat je intern geen "basis framework" o.i.d. op zet. Hetzelfde geldt voor een test framework, etc. Allemaal interne tools die je gebruikt en ontwikkelt om uiteindelijk naar de klant voor een goede prijs een goed product te kunnen leveren.

Wij gebruiken agile bijvoorbeeld eigenlijk alleen maar voor dit soort onderdelen binnen het bedrijf - de projecten voor klanten zijn niet of nauwelijks op een dergelijke manier te doen. Maar goed, dat is dan weer branche-specifiek (embedded / transport).

[De_Bastaard]

Frijns.Net schreef op donderdag 19 april 2018 @ 09:01:
[...]


Volgens mij mist er een nuance en jij of iemand anders gaf dat ook al aan in een andere post.
De klant gebruikt je product x aantal jaren en dan gaan ze naar de concurrent.
Tevens hebben ze geen geld voor een heel team.
Maar wie zegt dat beiden gerelateerd zijn? Je klant wil misschien support en tevens op de hoogte gehouden worden van nieuwe ontwikkelingen, mogelijkheden en een advies van een expert in de markt zodat nieuwe kansen zichtbaar worden. En dan heb je ook weer een businessmodel voor een nieuwe investering.
Dat zou een consultant kunnen doen in een rol waarbij hij toch regelmatig klant contact heeft maar niet perse om de bestaande app aan te passen. Je wil je klant toch houden en zodat je er na een tijdje weer een nieuw project kan doen.

Ja, dat willen we zeker. De klant loopt overigens bij ons niet weg na x-jaar omdat ze niets van ons horen, dat speelde bij een andere tweaker die in dit topic reageerde. Klanten zijn tevreden en komen ook bij ons terug voor nieuw werk, maar we merken dat er vaak meer te halen zou zijn voor ons én voor de klant om bestaande applicaties gestructureerder te onderhouden. Zowel voor bugfixes als voor het introduceren van nieuwe features.

Aangezien we geen filantropische instelling zijn krijgen we hier gewoon voor betaald, maar gebeurt het vaker in losse sprints gedurende het jaar of zelfs met een nog grotere interval (eens per jaar ofzo). Imo kan dat gestructureerder (als extra dienst?), maar ik zie even niet hoe.

Voor wat betreft het framework, ja er wordt gebruik gemaakt van diverse modules. Deze worden echter niet centraal onderhouden omdat de ene klant de app in de cloud draait en de ander deze op locatie draait. We kunnen niet remote updates pushen. Hierdoor zit in elke afgeleverde app wel een andere versie van die module(s). Zaken als geautomatiseerd testen kunnen we wel wat mee, dit zou de doorlooptijd van bugfixes én nieuwe features toevoegen aanzienlijk verkorten.

[ Voor 3% gewijzigd door De_Bastaard op 19-04-2018 09:24 ]

[redfox314]

joke_name schreef op woensdag 18 april 2018 @ 14:22:
Ik zou eens denken aan een strippenkaart model.

Een klant neem een strippenkaart af voor consultancy dienstverlening.

Hierbij kunnen ze van alles inkopen.
Rapportages, Training, backlog items oplossen, nieuwe functies.

dit gaat allemaal af van de strippenkaart.

Het voordeel van dit systeem is.
1 keer akkoord van directie benodigd voor een X-aantal uur.

Daarna kan je heel kort schakelen.

In deze constructie heb ik zelf al gewerkt bij een van mijn vorige werkgevers. Daar heette het credit en kwam een credit overeen met een tijd. Het grote nadeel is dat je wel met een vooruitbetaling zit. Dit is in de boekhouding/jaarcijfers niet zo evident. De credits moeten niet onbeperkt geldig blijven zodat ze ook effectief gepresteerd worden. De prijs van een credit moet wel voldoende zijn om voor de geldigheidsperiode de kosten te coveren. (Inflatie op de salarisen etc). Wij hadden ook verschillende toeslagen in credits bijvoorbeeld om meer prioriteit te krijgen in de planning. Daarnaast is het ook belangrijk om de tijd dat je verliest wanneer de klant steggelt over het aantal credits en de tijd dat het duurt om estimates te maken aan of in te rekenen. Zeker op kleine features voor kleine klanten eet deze communicatie in de marge die je op dat inkomen hebt.

[Widow]

Interessant onderwerp om mee aan de slag te gaan. Als ik mijn centjes bij mag dragen:

Stop met de term "projecten". Een project is iets dat je tijdelijk doet, terwijl je software niet tijdelijk gebruikt wordt. Dat wordt jaren gebruikt door een klant. Je software heeft een levenscyclus: een klant wilt een proces ondersteunen met een app (strategisch), je schrijft een ontwerp (design), gaat dat bouwen en uitrollen (implementatie) en een klant gaat het gebruiken (operatie). Je hebt dus sowieso al vier fasen die je applicatie meemaakt. Het lijkt nu alsof de focus op fase 2 en 3 ligt (design en implementatie) en dat fase 4 buiten de boot valt. Als je dat vanuit klantperspectief bekijkt, denk ik dat je meerwaarde ook zou kunnen zitten in het leveren van ondersteuning in de operatie (fase 4). Dat als er wat is, dat je klant jou kan bellen. Maar bedenk dat developers en consultants dit niet "cool" vinden, beheer van een applicatie vinden ze meestal duf. Dus als je die taak zomaar naar je devs schuift gaan ze je niet aardig vinden. Maar de kennis zit wel bij die mensen. Zou je iets kunnen doen met een roulatiesysteem?

Daarnaast ben ik benieuwd naar je architectuur. Als ik het zo hoor, zit je overal met verschillende versies van modules. Ik weet niet hoeveel versies het exact zijn, maar er komt een punt waarop versiebeheer van je modules je gaat nekken omdat er teveel variatie zit bij al je klanten. Elke klant krijg zn eigen bugfixes specifiek gericht op de versie van de module. Architectuur zou je kunnen helpen om te werken met een basisset generieke bouwstenen waar je alles mee bouwt. Ondanks dat het voor verschillende klanten is, weet ik zeker dat er generieke bouwstenen te onderkennen moeten zijn in wat je nu levert. Daarnaast kan architectuur je ook helpen om strategische belangen te borgen. Als je alleen prioriteert op basis van urgentie (klant X wil dit want het werkt niet, voor klant Y moet dat volgende week pas af zijn) kan het zijn dat je alleen brandjes blijft blussen in plaats van structurele zaken op te lossen. We hebben hier in user stories niet alleen de urgentie opgenomen, maar ook het strategisch belang van iets. Dan ben je niet alleen brandjes aan het blussen, maar kom je ook toe aan zaken vervangen voor brandwerende materialen, zodat er geen brandjes meer kunnen ontstaan.

Als laatste, het hele verhaal valt of staat bij het volwassenheidsniveau waar je in zit. Als ik de reacties zo een beetje lees klinkt het als een fabriek waar we lekker apps in elkaar stampen en niet bijzonder hoog scoren op volwassenheidsniveau. Bovenstaande punten kunnen van belang voor je zijn, maar realiseer je wel dat het ook een verhoging van volwassenheidsniveau vereist. Wilt men dat wel, staat de grote baas daar open voor? Als die alles goed vind zoals het is, en niks wilt veranderen (zoals levenscyclusbenadering vs projecten, architectuur om strategische belangen te borgen ipv alles op basis van urgentie) gaat er weinig van de grond komen.

[De_Bastaard]

Widow schreef op donderdag 19 april 2018 @ 09:52:
Interessant onderwerp om mee aan de slag te gaan. Als ik mijn centjes bij mag dragen:

Stop met de term "projecten". Een project is iets dat je tijdelijk doet, terwijl je software niet tijdelijk gebruikt wordt. Dat wordt jaren gebruikt door een klant. Je software heeft een levenscyclus: een klant wilt een proces ondersteunen met een app (strategisch), je schrijft een ontwerp (design), gaat dat bouwen en uitrollen (implementatie) en een klant gaat het gebruiken (operatie). Je hebt dus sowieso al vier fasen die je applicatie meemaakt. Het lijkt nu alsof de focus op fase 2 en 3 ligt (design en implementatie) en dat fase 4 buiten de boot valt. Als je dat vanuit klantperspectief bekijkt, denk ik dat je meerwaarde ook zou kunnen zitten in het leveren van ondersteuning in de operatie (fase 4). Dat als er wat is, dat je klant jou kan bellen. Maar bedenk dat developers en consultants dit niet "cool" vinden, beheer van een applicatie vinden ze meestal duf. Dus als je die taak zomaar naar je devs schuift gaan ze je niet aardig vinden. Maar de kennis zit wel bij die mensen. Zou je iets kunnen doen met een roulatiesysteem?

Daarnaast ben ik benieuwd naar je architectuur. Als ik het zo hoor, zit je overal met verschillende versies van modules. Ik weet niet hoeveel versies het exact zijn, maar er komt een punt waarop versiebeheer van je modules je gaat nekken omdat er teveel variatie zit bij al je klanten. Elke klant krijg zn eigen bugfixes specifiek gericht op de versie van de module. Architectuur zou je kunnen helpen om te werken met een basisset generieke bouwstenen waar je alles mee bouwt. Ondanks dat het voor verschillende klanten is, weet ik zeker dat er generieke bouwstenen te onderkennen moeten zijn in wat je nu levert. Daarnaast kan architectuur je ook helpen om strategische belangen te borgen. Als je alleen prioriteert op basis van urgentie (klant X wil dit want het werkt niet, voor klant Y moet dat volgende week pas af zijn) kan het zijn dat je alleen brandjes blijft blussen in plaats van structurele zaken op te lossen. We hebben hier in user stories niet alleen de urgentie opgenomen, maar ook het strategisch belang van iets. Dan ben je niet alleen brandjes aan het blussen, maar kom je ook toe aan zaken vervangen voor brandwerende materialen, zodat er geen brandjes meer kunnen ontstaan.

Als laatste, het hele verhaal valt of staat bij het volwassenheidsniveau waar je in zit. Als ik de reacties zo een beetje lees klinkt het als een fabriek waar we lekker apps in elkaar stampen en niet bijzonder hoog scoren op volwassenheidsniveau. Bovenstaande punten kunnen van belang voor je zijn, maar realiseer je wel dat het ook een verhoging van volwassenheidsniveau vereist. Wilt men dat wel, staat de grote baas daar open voor? Als die alles goed vind zoals het is, en niks wilt veranderen (zoals levenscyclusbenadering vs projecten, architectuur om strategische belangen te borgen ipv alles op basis van urgentie) gaat er weinig van de grond komen.

Hier moet ik wellicht ook nog wat meer duidelijkheid over verschaffen :-).

We gebruiken een applicatie van een leverancier om deze apps mee te ontwikkelen. Elke app bestaat nagenoeg compleet uit maatwerk, maar om het leven wat makkelijker te maken zijn er voor een aantal zaken standaard modules te verkrijgen. Modules worden niet altijd door ons zelf gemaakt/beheerd, wij zijn dan ook niet eigenaar van die modules - laat staan over de versionering ervan.

Het nadeel van die modules is dat elke module een eigen versionering heeft, en dat die niet downwards compatible zijn met oudere versies van de gebruikte applicatie. Een versie die pas is opgeleverd voor Module A, gemaakt in Versie 99 van de gebruikte applicatie/framework, is niet te gebruiken in versie 90. Veel klanten hebben echter niet altijd de laatste versie, omdat bij een update veel komt kijken. Updaten van de app is iets wat ik juist structureler wil aanpakken en vandaar dit topic.

Bugfixes vinden bijna altijd plaats op het maatwerk - niet op de modules. Uiteraard zitten er bugs in de modules, maar zoals ik hierboven al aangaf zijn die over het algemeen niet van ons.

Een roulatiesysteem zou kunnen, alleen is dat (begrijpelijk) voor onze planning naar klanten toe weer een uitdaging. We leggen een commitment vast van x-sprints, waarin we dus niet echt kunnen rouleren met andere apps (laat staan bij andere klanten).

En ja de baas staat hier voor open. We zijn opzoek naar het verhogen van het volwassenheidsniveau en daar zullen we wat voor moeten aanpassen. Vandaar dat ik ook dit topic opende om te achterhalen hoe dat bij andere bedrijven gaat

[KarmaPolice]

Ik werk niet dagelijks in een Agile team en heb eigenlijk überhaupt weinig praktijkervaring met Agile. Ik werk wel al een tijdje in de IT en heb best wat gelezen over dit onderwerp. Ik denk dat de meeste antwoorden op je vragen in bovenstaande reacties te vinden zijn. Het beste advies is in de reactie van Widow te lezen. Een custom (maatwerk) product voor iedere klant is op den duur niet meer te beheren. Het maakt niet zoveel uit wie dit gaat beheren al vind ik dev's inzetten op beheerwerkzaamheden wel een beetje weggegooide capaciteit. Iedereen moet tenslotte het werk doen waar ze het beste in zijn en het liefst ook waar ze voldoening uit halen. Om te kijken naar DevOps/ is helemaal niet zo'n slecht idee en richt zich juist op de beheer kant van je product. Het nadeel is dat je dan met symptoombestrijding bezig bent i.p.v. het probleem bij de wortel aanpakken. Die antwoorden zijn meer te vinden zoals je zelf al aangeeft in je releasemanagement in combinatie met alle tips die Widow geeft. Het doel moet zijn dat je een standaard (volwassen) framework gaat uitrollen naar je klanten die je het liefst remote centraal kan updaten en testen. Je moet een gulden middenweg vinden waarmee je door customisation van je modules toch kunt voldoen aan de functionele wensen van je klant en er tegelijk voor zorgen dat het beheer beheersbaar blijft.

Het kan best zijn dat inderdaad je hele architectuur herijkt moet worden om te bekijken of dit mogelijk is.

Je geeft zelf al aan dat een deel van je klanten een on-premise installatie van de app heeft. Ga eens bekijken of je deze kan gaan migreren naar de cloud variant als dit meer mogelijken bied om centraal updates te pushen. Je time to market(delivery) kan je hiermee ook aanzienlijk verkorten waardoor je de organisatie in staat stelt om al je klanten te voorzien van de laatste toevoegingen snufjes functionaliteit van je product.

[ Voor 12% gewijzigd door KarmaPolice op 19-04-2018 11:38 ]

[Tsurany]

Ryangr0 schreef op donderdag 19 april 2018 @ 08:44:
Misschien begrijp ik het niet goed, maar als je businessmodel gebaseerd is op software schrijven op projectbasis voor verschillende klanten, en je niet per project een nieuw team aanneemt, kun je die projecten toch niet maar altijd blijven supporten zoals je natuurlijk wel zou doen met een SaaS model zoals hier door sommigen geschetst wordt? Dan ben je binnen de kortste keren klaar omdat je geen capaciteit meer in kan zetten op nieuwe projecten (waar je je geld vandaan haalt).

Scrum leent zich m.i. per definitie niet voor dit soort app fabrieken, dus het verbaast me ook niet dat de OP niet volledig aan het framework voldoet.

Dat kan prima, alles valt of staat met een goede product owner. Een scrum team kan aan een nieuwe applicaties werken en tegelijkertijd userstories oppakken voor het onderhouden of verbeteren van bestaande applicaties. De uitdaging ligt bij de product owner, die moet de prioriteit gaan bepalen. En als blijkt dat er meer werk ligt dan volgens de velocity uitgevoerd kan worden kan het nodig zijn het team uit te breiden of een extra team naast het huidige team te zetten.

Maar aangeven dat Scrum per definitie niet werkt in dit soort gevallen komt naar mijn idee vaak door een te beperkte ervaring of een te beperkte visie. Vaak wordt krampachtig geprobeerd de werkwijze niet te veranderen en Scrum maar aan te passen zodat het binnen de huidige werkwijze valt. Dat kan maar zal verre van optimaal resultaat geven.

[De_Bastaard]

Tsurany schreef op donderdag 19 april 2018 @ 14:38:
[...]

Dat kan prima, alles valt of staat met een goede product owner. Een scrum team kan aan een nieuwe applicaties werken en tegelijkertijd userstories oppakken voor het onderhouden of verbeteren van bestaande applicaties. De uitdaging ligt bij de product owner, die moet de prioriteit gaan bepalen. En als blijkt dat er meer werk ligt dan volgens de velocity uitgevoerd kan worden kan het nodig zijn het team uit te breiden of een extra team naast het huidige team te zetten.

Maar aangeven dat Scrum per definitie niet werkt in dit soort gevallen komt naar mijn idee vaak door een te beperkte ervaring of een te beperkte visie. Vaak wordt krampachtig geprobeerd de werkwijze niet te veranderen en Scrum maar aan te passen zodat het binnen de huidige werkwijze valt. Dat kan maar zal verre van optimaal resultaat geven.

Is de eerste alinea niet vanuit het standpunt dat de PO('s) binnen dezelfde organisatie werken en dat de applicaties waar aan gewerkt wordt allemaal voor dezelfde organisatie zijn?

[Tsurany]

De_Bastaard schreef op donderdag 19 april 2018 @ 14:50:
[...]


Is de eerste alinea niet vanuit het standpunt dat de PO('s) binnen dezelfde organisatie werken en dat de applicaties waar aan gewerkt wordt allemaal voor dezelfde organisatie zijn?

Een team heeft een enkele product owner, die product owner kan wel verantwoordelijk zijn voor meerdere applicaties. Wie de klant is maakt voor het proces niet uit, die is enkel een stakeholder die zijn wensen bij de product owner neer legt.

[De_Bastaard]

Tsurany schreef op donderdag 19 april 2018 @ 14:54:
[...]

Een team heeft een enkele product owner, die product owner kan wel verantwoordelijk zijn voor meerdere applicaties. Wie de klant is maakt voor het proces niet uit, die is enkel een stakeholder die zijn wensen bij de product owner neer legt.

In ons geval wordt de PO geleverd door de klant omdat zij over meer inhoudelijke kennis beschikken dan wij.

@Ryangr0 legt het wel redelijk goed uit. Je kunt toch niet zomaar in een sprint als team weer aan een 'vorig' product gaan werken? Vertel dat maar eens aan de klant waar je op dat moment voor aan het werk ben.

Nogmaals, ik begrijp inmiddels dat een team pas op zou houden te bestaan wanneer de applicatie end of life is en dat we het voor een klant goedkoper kunnen maken door meer te automatiseren, maar bij complete maatwerk software is dat makkelijker gezegd dan gedaan. Klanten hebben geen budget om een product te laten ontwikkelen en dit door een/hetzelfde team te laten ondersteunen tot het niet meer gebruikt gaat worden.

[Tsurany]

De_Bastaard schreef op donderdag 19 april 2018 @ 15:15:
[...]


In ons geval wordt de PO geleverd door de klant omdat zij over meer inhoudelijke kennis beschikken dan wij.

@Ryangr0 legt het wel redelijk goed uit. Je kunt toch niet zomaar in een sprint als team weer aan een 'vorig' product gaan werken? Vertel dat maar eens aan de klant waar je op dat moment voor aan het werk ben.

Daarom wil je dus geen externe PO. Dan ligt het bepalen van prioriteit volledig bij de klant en kunnen jullie als bedrijf daar geen enkele invloed op uitoefenen. Jullie zijn op deze manier gewoon een detacheerder.

Nogmaals, ik begrijp inmiddels dat een team pas op zou houden te bestaan wanneer de applicatie end of life is en dat we het voor een klant goedkoper kunnen maken door meer te automatiseren, maar bij complete maatwerk software is dat makkelijker gezegd dan gedaan. Klanten hebben geen budget om een product te laten ontwikkelen en dit door een/hetzelfde team te laten ondersteunen tot het niet meer gebruikt gaat worden.

Je zet natuurlijk niet je volledige capaciteit in ter ondersteuning. Een team kan prima een handjevol applicaties ondersteunen en tegelijkertijd werken aan een nieuwe applicatie. Ik zie niet in waarom dit ook maar enige impact op de kosten moet hebben.

Nogmaals, jullie proberen Scrum aan te passen aan jullie werkwijze in plaats van jullie werkwijze aan te passen aan Scrum. Dan ga je gewoon geen succes boeken.

[Tarkin]

De_Bastaard schreef op donderdag 19 april 2018 @ 15:15:
[...]


In ons geval wordt de PO geleverd door de klant omdat zij over meer inhoudelijke kennis beschikken dan wij.

@Ryangr0 legt het wel redelijk goed uit. Je kunt toch niet zomaar in een sprint als team weer aan een 'vorig' product gaan werken?

Waarom niet? Het voordeel (in mijn ogen) van Scrum tov bv Kanban is dat je aan het begin van elke iteratie wel ongeveer weet waar je aan gaat werken. Kan 100% voor klant 1 zijn maar ook 50-50 bv. Of een andere combinatie.

Vertel dat maar eens aan de klant waar je op dat moment voor aan het werk ben.

Gezien je een product owner hebt van de klant betekent dit dat je dan elke sprint een andere product owner hebt? Anders is dit gewoon de product owner die overlegt met zijn stakeholders. In dit geval is de klant één van die stakeholders.

Misschien toch ook eens kijken voor interne PO's te maken. Zo blijft je team langer samen

Nogmaals, ik begrijp inmiddels dat een team pas op zou houden te bestaan wanneer de applicatie end of life is

Als het goed is houdt een performing team nooit op met te bestaan, je zorgt er gewoon voor dat er altijd genoeg werk is. Dit kan betekenen dat sprint 1 voor klant 1 is, sprint 2 voor klant 1&2 sprint 3 voor nog een andere klant. Voor je team maakt het in principe niet uit voor welke klant ze aan het werken zijn, zolang er maar (interessant) werk is dat ze kunnen doen met de competenties die ze hebben in het team, maakt al de rest voor hen niet uit.

Het grote nut van een een team samen te houden is dat je inderdaad niet iedere keer door die stappen moet gaan om tot een succesvol team te gaan. Kroga heeft het Tuckman model hier al gezet. Van zodra je iedere keer een nieuw team maakt, verplicht je eigenlijk je team opnieuw om die conflicten te hebben, om met elkaar te leren samenwerken; En (assumptie) gezien de duur van jullie projecten denk ik niet dat jullie ooit verder geraken dan de storming fase. Een goed team opbouwen duurt jaren.

Ik weet dat dit raar klinkt in onze contreien waar iedereen voor elke scheet weer naar een ander team/werkgever gaat. Maar teams die langere tijd samen zijn daar zie je echt wel verschil in.

[Ryangr0]

Er zijn een paar dingen waar ik moeite mee heb in dit verhaal. Een Product Owner is (athans, in het bedrijf waar ik werk) de eindverantwoordelijke voor een product. Zijn/haar hoofdverantwoordelijkheid ligt in het zorgen dat de punten met de hoogste waarde voor het product bovenaan de backlog staan.

Als er volgens de hierboven geschetste situatie gewerkt wordt, dus dat er 1 product owner is voor meerdere producten is dat mijn inziens belangenverstrengeling. Hoe gaat deze PO bepalen dat punt 1 van product A belangrijker is dan punt 3 van product B? De stakeholders (lees: klant) die Product A afneemt zal zich behoorlijk belazerd voelen. Dé persoon die is aangesteld om verantwoordelijkheid te dragen voor "hun" product bij de aannemer heeft klaarblijkelijk andere prioriteiten. Daarbij is het erg handig en zelfs vanzelfsprekend dat de PO over vergaande domeinkennis moet beschikken. Een interne PO ligt dus niet altijd voor de hand.

Daar komt bij dat het inderdaad prima kan om "oude" producten te ondersteunen, maar niet voor eeuwig.

Je zegt:
"Een scrum team kan aan een nieuwe applicaties werken en tegelijkertijd userstories oppakken voor het onderhouden of verbeteren van bestaande applicaties."
Dat kan, maar tot op een zekere hoogte. Als je nu nog tijd aan het steken bent in allerlei producten die tien jaar geleden tot vorige maand zijn opgeleverd als app fabriek dan zou ik nog eens goed nadenken over wat je core business precies is. Dat kan natuurlijk nooit de bedoeling zijn. Dat zou betekenen dat hoe meer opdrachten je aanneemt hoe minder capaciteit (en dus omzet) je op termijn overhebt voor nieuwe projecten. Het hele punt van zo'n organisatie is app maken -> opleveren -> misschien nog wat aftercare -> volgende. Daar ligt het grote geld.

[Tsurany]

@Ryangr0 als de PO dat niet bepaald, wie dan wel? Uiteindelijk zal iemand die prioriteit moeten bepalen, je hebt maar beperkte capaciteit als bedrijf.
En als een applicatie end of life is dan steek je er geen tijd meer in, het maakt niet uit of je nu Scrum werkt of welke methode dan ook.

[Tarkin]

Ryangr0 schreef op donderdag 19 april 2018 @ 19:13:


Als er volgens de hierboven geschetste situatie gewerkt wordt, dus dat er 1 product owner is voor meerdere producten is dat mijn inziens belangenverstrengeling. Hoe gaat deze PO bepalen dat punt 1 van product A belangrijker is dan punt 3 van product B? De stakeholders (lees: klant) die Product A afneemt zal zich behoorlijk belazerd voelen. Dé persoon die is aangesteld om verantwoordelijkheid te dragen voor "hun" product bij de aannemer heeft klaarblijkelijk andere prioriteiten. Daarbij is het erg handig en zelfs vanzelfsprekend dat de PO over vergaande domeinkennis moet beschikken. Een interne PO ligt dus niet altijd voor de hand.

Een PO opereert ook niet in het vacuum he. Die gaat niet als een zonnekoning beslissen wat wel en niet goed is voor het development team. Als het goed is kan de PO terugvallen op een team van stakeholders. In zijn geval dus de verschillende klanten o.a. Die kunnen dan aangeven wat de prio's zijn en in samenspraak zal de PO dan de backlog bepalen.

Als je als team meerdere projecten aankunt, betekent dat ook dat er maar eentje is die actief ontwikkelt wordt en x aantal andere in maintenance waar eigenlijk heel weinig aan moet gebeuren. Van zodra er meerdere projecten full time actief zijn, kom je waarschijnlijk met 1 scrum team niet meer toe. Dan lost dat probleem zich normaliter ook gewoon op doordat je ofwel een project dan doorgeeft aan een ander team ofwel je prio's in de backlog zo zijn dat het duidelijk is waar eerst aan gewerkt moet wroden.