Scrumteam zonder ervaring voor project in schijnwerper

[Boekensteun]

Mijn vraag
Weet niet helemaal zeker of dit de juiste plek is, in deze sectie staan wel de meeste scrum gerelateerde topics, vandaar dat ik hier begin.

Mijn manager wil een groot project, waarvoor ik projectleider ben en dat impact heeft voor alle gebruikers, gebruiken als "testcase" voor de introductie van scrum.
Er is een externe scrummaster van een andere afdeling, verder werkt niemand volgens de scrum methodiek of is daarin getraind.

Omdat er nare ervaringen uit het verleden zijn met de introductie van software die de hele organisatie moet omarmen en gebruiken, is bedacht dat dit project het ideale project is om volgens de scrum methodiek te implementeren. Het idee is dat mensen van andere afdelingen af en toe binnen het scrumteam kunnen deelnemen om zo het draagvlak in de organisatie te vergroten.

Ik heb geen ervaring met scrum, maar wil best volgens deze methodiek werken.
Toch heb ik ook wat weerstand. Dit wordt veroorzaakt doordat

• scrum kent geen projectleider. Wel de rol projectproductowner, maar volgens de info die ik heb gevondent zijn dat verschillende rollen. Het is mij niet duidelijk waar ik sta als projectleider
• Ik heb als projectleider het projectplan en deimplementie tot in detail uitgewerkt met de leverancier. Hoe verhoudt zich dat tot scrum
• niemand, behalve de scrummaster heeft ooit aan een scrumteam deelgenomen. In hoeverre is er dan positief succes te behalen. Als projectleider straalt het succes van de implementatie op mij af. Ik heb het gevoel dat ik nu wel verantwoordelijk ben, maar niet de touwtjes in handen heb.

Zie ik het scrummen te somber in, moet ik het gewoon maar over mij heen laten komen of zijn bovenstaande argumenten voldoende om mij hard te maken tegen scrum in dit geval, of misschien zelfs wel mijn rol als projectleider neer te leggen.

[ Voor 0% gewijzigd door Boekensteun op 01-10-2020 14:26 . Reden: aanpassing nav opmerking ]

[Kanarie]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:09:
Ik heb geen ervaring met scrum, maar wil best volgens deze methodiek werken.
Toch heb ik ook wat weerstand. Dit wordt veroorzaakt doordat
• scrum kent geen projectleider. Wel de rol projectowner, maar volgens de info die ik heb gevondent zijn dat verschillende rollen. Het is mij niet duidelijk waar ik sta als projectleider

Volgens mij bedoel je "product owner". Dat is iets heel anders dan een klassieke projectleider. Deze persoon moet iemand zijn die heel goed begrijpt wat de klant wil (het liefst zelf de klant is) en die hierin snel keuzes mag maken van wat er gebouwd wordt en wat de software uiteindelijk moet kunnen.

• Ik heb als projectleider het projectplan en deimplementie tot in detail uitgewerkt met de leverancier. Hoe verhoudt zich dat tot scrum

Even los van de discussie of het uberhaupt ooit een goed idee is om een software-product van tevoren tot in detail uit te werken, het iteratief werken in scrum staat op gespannen voet met een al geschreven, gedetailleerd, projectplan.

• niemand, behalve de scrummaster heeft ooit aan een scrumteam deelgenomen. In hoeverre is er dan positief succes te behalen. Als projectleider straalt het succes van de implementatie op mij af. Ik heb het gevoel dat ik nu wel verantwoordelijk ben, maar niet de touwtjes in handen heb.

Binnen een scrumteam is geen projectleider, dus die verantwoordelijkheid zou niet zo rechtstreeks op je af moeten stralen. Een korte cursus scrum voor het team lijkt me essentieel om het een kans van slagen te geven.

[Boekensteun]

@Kanarie, het betreft hier niet de ontwikkeling van een software product, maar de implementatie van een softwarepakket. Ivm een aanbestedingstraject heeft het eerste deel van het project (de aanschaf van het pakket) al een jaar gelopen. We zijn nu toe aan de implementatie. Omdat er tot een paar weken terug nog geen sprake van scrum was, is er al met het projectplan begonnen.

Jij geeft aan dat er binnen het scrumteam geen projectleider is, zo ver was ik ook. Dat weet straks het hele scrumteam van vier of vijf mensen. Maar de overige 500 mensen weten dat ik projectleider ben.
Als, om welke reden dan ook, de acceptatie van het pakket moeizaam gaat of als er andere tegenslag is, kent iedereen mijn naam.

Ik vraag me af of ik als "projectleider" die onderdeel uit maakt van een scrum team, maar geen projectleidersrol heeft, voldoende mogelijkheid heb om het project in goede banen te leiden. Kan ik die rol pakken, of is dat not-done binnen een scrum team.

Binnen een andere afdeling wordt ook volgens een soort scrum methodiek gewerkt zonder dat mensen getraind zijn. Volgens de scrum master is dat allemaal geen probleem.

[DaWin]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:38:
Jij geeft aan dat er binnen het scrumteam geen projectleider is, zo ver was ik ook. Dat weet straks het hele scrumteam van vier of vijf mensen. Maar de overige 500 mensen weten dat ik projectleider ben.
Als, om welke reden dan ook, de acceptatie van het pakket moeizaam gaat of als er andere tegenslag is, kent iedereen mijn naam.

Als Product Owner ga je het primaire aanspreekpunt zijn van dit pakket ja, dat is je rol. Hoe je daar precies aanvulling aan geeft is aan jou, maar tijdens een Sprint Review kunnen de eindgebruikers je feedback geven.

Ik vraag me af of ik als "projectleider" die onderdeel uit maakt van een scrum team, maar geen projectleidersrol heeft, voldoende mogelijkheid heb om het project in goede banen te leiden. Kan ik die rol pakken, of is dat not-done binnen een scrum team.

In principe bepaalt de Product Owner het wat en het team het hoe. Door de taken / backlog items te maken en te prioriteren kan je invloed uitoefenen, maar het idee van Scrum is dat het team zelf-sturend is, en er dus niet 1 persoon/rol is die even gaat zeggen wat de rest moet doen. De Product Owner is zeker onderdeel van het team, maar niet de leider.

Als ik jou was zou ik zeker de Scrum Guide doornemen en dat zou ik zeker ook adviseren aan de rest van het team.

[Hydra]

Uiteindelijk komt Scrum, zoals de meeste methodieken, neer op het opsplitsen van het werk in hapklare brokken, waarbij het proces zelf het bijsturen ervan faciliteert. Scrum ligt de focus op de uitvoering en het heeft heel erg geen mening over hoe je het proces daarvoor ingeregeld hebt. Als projectleider sta je in dit geval eigenlijk buiten het team; je bent stakeholder. Daarin zou je dus wel een product owner rol kunnen bekleden; je bepaalt dan samen met het team per sprint de prioriteiten. Je hebt dan eigenlijk twee petten op, wat overigens prima kan.

[Hydra]

DaWin schreef op donderdag 1 oktober 2020 @ 14:52:
In principe bepaalt de Product Owner het wat en het team het hoe.

Het team bepaalt dit samen. De product owner heeft natuurlijk een hele sterke stem, maar de product owner is gewoon gelijkwaardig aan de andere teamleden, en heeft geen automatisch veto recht. Aan de andere kant moet je er wel vanuit kunnen dat de rest van de teamleden gewoon het bedrijfsbelang prio geven natuurlijk, dus dit levert normaliter geen conflicten op.

Als je gewoon een 'baasje' hebt die taken maakt die de rest gewoon domweg uitvoert, dan heb je niks aan Scrum.

[Kanarie]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:38:
@Kanarie, het betreft hier niet de ontwikkeling van een software product, maar de implementatie van een softwarepakket. Ivm een aanbestedingstraject heeft het eerste deel van het project (de aanschaf van het pakket) al een jaar gelopen. We zijn nu toe aan de implementatie. Omdat er tot een paar weken terug nog geen sprake van scrum was, is er al met het projectplan begonnen.

Ah interessant, ik heb alleen ervaring met scrum binnen projecten voor softwareontwikkeling, daar is het volgens mij ook het meest geschikt voor. Het lijkt me lastiger toepasbaar in het proces wat jij beschrijft, zeker gezien er een projectplan en implementatie uitgewerkt is, dat schept verwachtingen bij de klant.

Een van de goede punten van scrum is dat je er gedurende het project samen met je klant achterkomt wat belangrijk is en vooral wat niet. Hier kan je gedurende het hele project op bijsturen en keuzes maken. Dan kun je ofwel binnen scope, ofwel binnen de gegeven tijd een bruikbaar product opleveren. Je liet het woord aanbesteding al vallen, dus ik gok dat dit ook lastig zal zijn.

Ik vraag me af of ik als "projectleider" die onderdeel uit maakt van een scrum team, maar geen projectleidersrol heeft, voldoende mogelijkheid heb om het project in goede banen te leiden. Kan ik die rol pakken, of is dat not-done binnen een scrum team.

Die rol is er niet binnen het scrum team. Je zou als projectleider een scrum master kunnen zijn (al is dat deze keer iemand anders), maar dan ben je vooral met het proces bezig, faciliterend. Je kan ook een soort van (proxy) product owner zijn, maar die rol is m.i. veel beter af bij de uiteindelijke klant indien mogelijk.

Binnen een andere afdeling wordt ook volgens een soort scrum methodiek gewerkt zonder dat mensen getraind zijn. Volgens de scrum master is dat allemaal geen probleem.

In mijn ervaring kan dat prima als je 1 of 2 projectleden hebt die niet eerder met scrum gewerkt hebben (het is allemaal niet zo moeilijk), maar bij jou is er maar 1 iemand met ervaring, dat lijkt me lastig. Een goede scrum master zal ook helpen het proces te volgen, wellicht is het voldoende.

[DexterDee]

Scrum teams zijn zelfsturend, een projectleider in de zin dat er iemand is die de voortgang bewaakt van de teamleden en de milestones in het project is er niet. Alle teamleden zijn zelf verantwoordelijk voor hun voortgang en worden geacht elkaar scherp te houden. Het team bepaalt ook zelf hoeveel werk ze op kunnen pakken en hierop geeft iedereen z'n commitment af. Van "taak X moet af op Y, zorg er maar voor" is in een scrum team géén sprake.

De product owner is expliciet géén projectleider, maar is eigenaar van de lijst van werk die gedaan moet worden. Hij is verantwoordelijk dat deze "backlog" gevuld is met concrete taken die de teamleden op kunnen pakken. De product owner bepaalt in welke volgorde welke taken opgepakt worden, dit doet hij/zij aan de hand van de business value. De hoogste business value taken (ofwel waar haalt het project/bedrijf het meeste profijt uit in de breedste zin van het woord) worden als eerste opgepakt. De product owner doet aan stakeholder management. Dit wil zoveel zeggen als het afwegen van de belangen van alle belanghebbenden. Dus de directie, de klant, leveranciers, consultants, ontwikkelaars, etc... Hierbij heeft hij/zij de absolute eindverantwoordelijkheid en heeft niemand, zelfs niet de directeur/directie van het bedrijf of de klant, mandaat om een beslissing door te drukken of iets naar voor of naar achteren te plaatsen. Uiteraard kan een specifieke wens wel leiden tot een hoge business value en op die manier bovenaan de lijst komen. Het eindoordeel ligt echter bij de product owner, deze heeft namelijk de beste overall view op het project.

In een Scrum traject is het niet mogelijk om in detail tegen de "klant" te zeggen wanneer iets af is. Dat vereist een detailniveau van uitwerking die niet past bij de werkwijze. Het scrumteam commit niet aan een deadline in de toekomst, maar commit zichzelf tot het telkens opleveren van "increments", deeloplossingen, die al in gebruik genomen kunnen worden. En dat op zo'n manier dat er telkens de meeste "business value" geleverd wordt. De klant krijgt hierdoor dus het meeste waar voor z'n geld, omdat er altijd aan de meest belangrijke dingen gewerkt wordt.

Een korte feedback loop en profiteren van voortschrijdend inzicht is cruciaal in een Scrum team. Daarom worden de werkpakketten (stories) niet al te ver van tevoren helemaal geanalyseerd en uitgeschreven. Door te "refinen", ofwel de werkpakketten uit te werken als ze nodig zijn en vlak daarvoor, profiteer je maximaal van wat je in het verleden geleerd hebt. De product owner kan dan ook constant nieuwe afwegingen maken in hoe belangrijk de individuele taken zijn en hierop sorteren. Elke sprint, ofwel vaste tijdsperiode van werk, wordt dan ook afgesloten met een "retrospective" meeting waarin het team evalueert wat er goed en fout ging en wat er verbeterd moet worden om in de volgende 'sprint" succesvoller te zijn.

Essentieel met scrum is het opleveren van increments (sprint deliverables) die "productieklaar" zijn, ofwel praktisch bruikbaar. Zo kun je zo vroeg mogelijk al profiteren van de resultaten van een lopend project. Om te garanderen dat iets goed genoeg is uitgewerkt om op te pakken spreekt het scrum team intern af waar een werkpakket (story) aan moet voldoen. Dit wordt de "definition of ready" genoemd. En om objectief te bepalen of een story ook écht klaar is, wordt een "definition of done" opgesteld. Hierin staat SMART omschreven wanneer een taak ook écht af is. Zo kun je denken aan de verplichting om een bepaalde feature ook op een test- of acceptatie omgeving uit te rollen of de beschikbaarheid van bepaalde uitrol automatisering.

Er zijn twee gapende valkuilen met Scrum die ik telkens weer tegenkom:

1. Geen management / directie commitment op deze werkwijze. Scrum masters en product owners die hierdoor niet het juiste mandaat krijgen om hun werk fatsoenlijk te doen. Managers, directie (en soms klanten) die het team en de product owner dwingen om in te breken in lopende sprints om werk toe te voegen, te veranderen of teamleden totaal ongerelateerde werkzaamheden te laten verrichten.

2. Klanten die de scrum werkwijze niet accepteren en verplichten om met een lange termijn planning en een exact kostenplaatje te werken. Dit soort klanten vinden het vaak wel hip om met Scrum te werken, maar willen wel een fixed price project draaien ala waterval.

De PSM I en PSPO I trainingen zijn een erg handige eerste stap om de basisbeginselen van scrum onder de knie te krijgen.

[Basekid]

Mmm als ik het zo lees, rinkelen er twee alarmbellen:

Het idee is dat mensen van andere afdelingen af en toe binnen het scrumteam kunnen deelnemen om zo het draagvlak in de organisatie te vergroten.

Een elementair onderdeel van scrum is dat je een "self organised" team hebt, dat in princiepe in staat is de gevraagde situatie zelf op te lossen. Je doet dit (zoals hierboven heel goed beschreven is), door korte sprints te plannen. Als je veel beweging in het team hebt doordat mensen tijdelijk aansluiten, is het erg moeilijk goede sprintplannen te maken en echt als een eigen team aan een gezamelijk doel te werken.

Bij ons hebben ze ook geprobeerd een aantal personen half in het team te stoppen, en dat werkt voor geen meter. Zij werden steeds gevraagd "klassiek" werk neer te zetten voor hun andere opdrachten en dat loopt gewoon 100% in tegen je scrummethode.

Er is een externe scrummaster van een andere afdeling, verder werkt niemand volgens de scrum methodiek of is daarin getraind.

Als alleen jullie team zo werkt, moet je goed uitzoeken hoeveel support van andere partijen je hebt. Dit zijn niet alleen experts die je 1 of 2x nodig hebt, maar ook management. Je gaat (zoals beschreven) op een hele andere manier werken en de rest van de organisatie moet leren om niet zomaar dingen aan je te vragen of te verwachten. die komen op een backlog etc.

Ook daar hadden wij als team veel pijn. wij wilde wel graag met een backlog etc werken, maar de mensen die we nodig hadden, of dingen opgeleverd wilde, hadden hele andere planningsprocessen. Dat werke voor geen meter.

[Charly]

Ik heb bij mijn vorige werkgever de zelfde situatie meegemaakt, met het verschil dat ik zelf voorgesteld heb scrum toe te gaan passen. Twee dingen:

- Als projectleider heb je inhoudelijk in principe geen fuck meer te vertellen en mag je alleen maar faciliteren / dingen regelen voor het team. Dat is spannend, maar aan de andere kant draag je ook een deel van de verantwoordelijkheid over aan het team / de scrummaster. (Of dat in deze situatie kan is een 2e)

- Los van je eigen rol zie ik hier nog iets mis gaan. Namelijk dat er al vast lijkt te staan wat er opgeleverd moet zijn aan het eind van het project. Voor scrum om te werken moet de uitkomst in meer of mindere mate onderhandelbaar zijn. Als die ruimte er niet is moet je imo niet gaan scrummen.

De scrumguide is al genoemd, lees die zeker en ik zou adviseren ook de agile manifasto door te nemen. Als je die snapt helpt het je eventuele valkuilen in je organisatie / omgeving te zien.

In mijn optiek is de rol van "traditionele" projectleiders in IT een aflopende zaak, dus ik zou in mn achterhoofd houden dat je hier misschien je nek uitsteekt binnen de organisatie maar aan de andere kant ook hele waardevolle ervaring op kunt doen.

Maargoed ik ben een believer. Het vraagt wat van je mensen en organisatie (dat wordt vaak onderschat!), maar als je het voor elkaar krijgt is het voor iedereen leuker werken worden er betere producten opgeleverd.

[ Voor 10% gewijzigd door Charly op 01-10-2020 15:42 ]

[Woy]

Bij dit soort trajecten is het altijd erg belangrijk dat de organisatie ook echt open staat om SCRUM te faciliteren. Ik heb al meerdere keren gezien dat het vanaf bovenaf alleen gezien wordt als "het team geeft commitment af" waarbij dus verwacht wordt dat de deadlines gehaald worden zonder dat er geaccepteerd wordt dat de eisen ook aangepast worden aan de capaciteit en wisselende requirements.

Om het goed te doen moet het twee richting verkeer zijn. Het team doet alles om zoveel mogelijk value op te leveren en het bedrijf geeft daar ook ruimte voor, door het team ook de ruimte te geven om dat op de door hun gewenste manier te doen.

Ik heb vaak gezien dat er alsnog als een klassieke waterval methode gewerkt wordt, en boos naar het team gekeken werd omdat ze de sprint niet volledig afgerond hadden, terwijl ze daar verder zelf geen inspraak in gehad hebben.

[renegrunn]

Waarom wil je manager scrum introduceren? Wat zijn de verwachtingen?

[bomberboy]

De vraag van @renegrunn is eigenlijk de belangrijkste. Scrum is "maar" een methodologie/manier van werken, specifiek in de context van "Agile". En afhankelijk van wat je wil bereiken/de verwachtingen zijn een goede of slechte keuze.

In essentie zijn er wel een paar algemeenheden. In je rol van projectleider weet je goed dat er altijd 3 constraints zijn:

• tijd
• budget
• scope

En dat is bij scrum (of eender welke methodologie) niet anders. Het verschil is welke je "vast" zet. In "traditioneel" projectmanagment zijn typisch tijd en budget de assen die vastgezet worden met als gevolg dat het budget de enige variabele is. (Met soms slechte gevolgen zeker bij overheidsprojecten). In de Agile wereld wordt het meestal anders aangepakt en wordt de tijd vast gezet en scope en budget variabel. Als het puur over een software-project gaat is budget vaak ook gewoon tijd van mensen en is de facto budget dus ook vast.

Dit betekent dat scope dus nog overblijft. De hele agile manifesto is ook afkomstig van het feit dat scope van bij de start vastleggen niet noodzakelijk het beste is voor de eindklant want die is vooraf onvoldoende geïnformeerd en weet niet noodzakelijk perfect wat hij wil. Dus ga je 2-wekelijks aftoetsen of het nog altijd ok is om nare verrassingen op het einde te voorkomen. Het gevolg is dan in een aantal gevallen dat de nare verrassing op het einde dan is dat de tijds-as veel langer duurt en ook het budget veel hoger is. (kan ook omgekeerd). Budget/tijd kan wel vastgelegd worden en dan eindig je in theorie met de best mogelijke oplossing voor het beschikbare budget. In praktijk wordt dat niet altijd perfect gemanaged.

Uit je posts lijkt echter naar voor te komen dat scope en tijd nu al duidelijk vastgelegd zijn. En waarschijnlijk budget ook. Het traditionele dilemma van de projectmanager.

Zoals eerder ook al aangehaald. SCRUM gaat in principe uit van stabiele teams zodat je echt in een soort van "kadans" terecht komt voor de ontwikkeling met dat vast team en dit een goed geoliede machine wordt. De verwachting dat er dan at random wat mensen bij aansluiten is "apart".
Wat wel kan (aangezien het over een implementatieproject gaat) dat er een soort gefaseerde uitrol is en dat voor iedere afdeling enz er een domein-expert/key-user bij betrokken wordt die op dat moment valideert of de implementatie goed gedaan is voor zijn noden en daar dingen kan bijsturen. Dus een soort van assistent product-owner rol in scrum terminologie. En bv met de opdracht dat gedurende 3 sprints het voor zijn deel van de organisatie moet opgezet geraken. Zijn zijn wensen niet realistisch, dan is het aan die persoon om te kiezen wat weg kan vallen en binnen die 3 sprints wel gerealiseerd kan worden. En hij moet het team geloven als iets niet kan binnen een bepaalde tijd en dat hij echt keuzes moet maken.

Wat is nu het belangrijkste in heel het agile verhaal is dat de rollen en verantwoordelijkheden "anders" zijn dan in een "traditioneel" project. In die zin dat in een traditioneel project de projectmanager typisch de kop van jut is als er iets mis loopt. Want hij moest het opvolgen toch? Eigenlijk klopt dat ook niet en heeft iedereen zijn eigen verantwoordelijkheid om te rapporteren aan die projectmanager, maar vaak loopt het wel heel hierarchisch.
Agile/Scrum maakt het wel explicieter dat iedereen in dat team problemen naar voor kan brengen en het team die dan samen oplost. Als het mis gaat is het dus de schuld van het team en niet van één arme projectmanager. Ook hier loopt het in praktijk vaak mis, zeker bij een opstart. En zijn de klanten dan ontevreden omdat ze geen "controle" hebben over het "project".

Maar goed, tot zover deze rant, de belangrijkste vraag is inderdaad wat de verwachtingen zijn van "scrum".
Zoals ook al aangegeven moet de "klant" ook bereid zijn om op die manier te werken en die verantwoordelijkheid op te nemen. (bv als die domeinexpert blijft eisen dat de kleur van de applicatie roze moet zijn en dat prioritair is op het effectief bruikbaar zijn, dan mag hij na 6 weken niet klagen dat het wel roze is maar voor de rest niet werkt). En dat moet ook gemanaged worden.

(Excuses voor het excessief gebruik van aanhalingstekens, maar dat zijn een aantal van de (buzz)woorden die afhankelijk van met wie je spreekt plots een andere betekenis krijgen of totaal anders ingevuld worden. Let dus altijd op wanneer deze gebruikt worden, zeker bij de introductie van een nieuwe methodiek, de verwachtingen kunnen heel anders.)

[Gomez12]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:09:
• Ik heb als projectleider het projectplan en deimplementie tot in detail uitgewerkt met de leverancier. Hoe verhoudt zich dat tot scrum

De grote vraag is waarom zou je scrum willen doen als er al een waterval implementatie op papier staat?

Is dat omdat de klant erom vraagt?
Of halen jullie het huidige plan niet of wat?

Want dit klinkt mij in de oren als een redelijk rampenplan als de klant er niet zelf om gevraagd heeft.

Je moet goed begrijpen dat als je gaat scrummen dat elke deadline het raam uitgaat, het hele projectplan wordt aan de kant geschoven.
Verkopers willen het graag brengen als dat de klant meer zelf kan kiezen en meer invloed heeft, alleen verkopers laten vaak achterwege dat daardoor de deadline het raam uit is gegaan.

Simpel gezegd, als er een deadline is van 1 jan 2022 en de klant vanwege scrum 4 weken extra aandacht aan onderwerp x wil besteden, dan moet er of minder tijd aan andere dingen besteed worden, of de opleverdatum is nu minimaal 1 feb 2022.

Mijn ervaring met dit soort dingen is dat het niet goed uitgelegd wordt aan de klant waardoor de klant in juni 2022 zit te zeiken dat de deadline een half jaar geleden was. En ja, hij had wel wat extra wensjes maar die konden toch gewoon binnen scrum...

Normaliter in mijn ervaring loopt dit soort wijzigingen (zeker als het niet vanuit de klant gevraagd is) uit op teleurstellingen, omdat de klant flexibeler kan handelen, maar dit praktisch gezien maar 1 kant op werkt (extra functionaliteit).

Of hoe ik het ook wel eens anders gezegd heb :
- Hier hebben we een projectplan/implementatie op tafel liggen wat in wezen geen vet bevat en al bestaat uit het minimale.
- Nu wil jij het gaan omgooien dat er op kleine onderdelen dingen aan toegevoegd kunnen worden.
Best, alleen omdat het projectplan al minimaal is gaat er daar niets vanaf, en veel kleine onderdelen komt toch neer op veel tijdsoverschrijding.

Scrum wil je introduceren op een nieuw project waar nog geen deadline aan hangt en de klant er ook geen deadline aan hoeft te hangen.

[Ernemmer]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:09:
Mijn vraag
Weet niet helemaal zeker of dit de juiste plek is, in deze sectie staan wel de meeste scrum gerelateerde topics, vandaar dat ik hier begin.

Mijn manager wil een groot project, waarvoor ik projectleider ben en dat impact heeft voor alle gebruikers, gebruiken als "testcase" voor de introductie van scrum.
Er is een externe scrummaster van een andere afdeling, verder werkt niemand volgens de scrum methodiek of is daarin getraind.

Omdat er nare ervaringen uit het verleden zijn met de introductie van software die de hele organisatie moet omarmen en gebruiken, is bedacht dat dit project het ideale project is om volgens de scrum methodiek te implementeren. Het idee is dat mensen van andere afdelingen af en toe binnen het scrumteam kunnen deelnemen om zo het draagvlak in de organisatie te vergroten.

Ik heb geen ervaring met scrum, maar wil best volgens deze methodiek werken.
Toch heb ik ook wat weerstand. Dit wordt veroorzaakt doordat

• scrum kent geen projectleider. Wel de rol projectproductowner, maar volgens de info die ik heb gevondent zijn dat verschillende rollen. Het is mij niet duidelijk waar ik sta als projectleider
• Ik heb als projectleider het projectplan en deimplementie tot in detail uitgewerkt met de leverancier. Hoe verhoudt zich dat tot scrum
• niemand, behalve de scrummaster heeft ooit aan een scrumteam deelgenomen. In hoeverre is er dan positief succes te behalen. Als projectleider straalt het succes van de implementatie op mij af. Ik heb het gevoel dat ik nu wel verantwoordelijk ben, maar niet de touwtjes in handen heb.

Zie ik het scrummen te somber in, moet ik het gewoon maar over mij heen laten komen of zijn bovenstaande argumenten voldoende om mij hard te maken tegen scrum in dit geval, of misschien zelfs wel mijn rol als projectleider neer te leggen.

Ik zou asap op een snelcursus scrum gaan, zodat in ieder geval de projectleider weet hoe het het werkt.

[Verwijderd]

Ernemmer schreef op vrijdag 2 oktober 2020 @ 11:48:
[...]


Ik zou asap op een snelcursus scrum gaan, zodat in ieder geval de projectleider weet hoe het het werkt.

Yep en dan kan je manager met de trainer in discussie gaan over de werkelijke implementatie van scrum binnen jullie team.

[Yucon]

bomberboy schreef op vrijdag 2 oktober 2020 @ 10:26:
Uit je posts lijkt echter naar voor te komen dat scope en tijd nu al duidelijk vastgelegd zijn. En waarschijnlijk budget ook. Het traditionele dilemma van de projectmanager.

De rek moet je in dit soort gevallen in de scope zoeken. Dit is echter vaak meer een kwestie van willen dan van kunnen.

Aan de uitleg van TS te zien zal het best een ingewikkeld pakket zijn. Dat wil zeggen dat je daarbinnen vrijwel zeker inrichtingkeuzes hebt die stuk voor stuk een bepaalde mate van gemak of voordeel met zich meebrengen, maar waarbij de minder optimale optie in principe toch wel voldoet. Als je nu de situatie hebt dat je ergens een enorm koppige key user of architect hebt zitten die de detailinrichting al in z'n hoofd heeft zitten en bij voorbaat weigert daarvan af te wijken kom je er niet uit. Als je met wat meer pragmatische mensen in het team zit die er samen uit willen komen en die begrijpen dat je af en toe wel eens een veer moet laten kom je er wel uit.

Als projectleider zul je dan wel moeten accepteren dat je wat meer buiten spel staat. Je faciliteert en administreert dan, en ingrijpen op het proces is vrij beperkt. Vooral binnen sprints rommelen met de scope van die sprint wordt als enorm not done opgevat.

Het helpt als het team vooraf de opdracht 'geen gouden randjes' meekrijgt. Het is onvermijdelijk dat het soms wel die kant opgaat maar door zo'n duidelijke boodschap geef je de rest van het team een handvat om tegengas te geven.

[ Voor 7% gewijzigd door Yucon op 02-10-2020 11:57 ]

[Gomez12]

Yucon schreef op vrijdag 2 oktober 2020 @ 11:54:
Het helpt als het team vooraf de opdracht 'geen gouden randjes' meekrijgt. Het is onvermijdelijk dat het soms wel die kant opgaat maar door zo'n duidelijke boodschap geef je de rest van het team een handvat om tegengas te geven.

Het is over het algemeen zo dat het project plan (wat er nu dus al ligt) al geen gouden randjes kent, waardoor je er niets uit kan laten vallen en elke wijziging enkel extra werk is.

[Yucon]

Gomez12 schreef op vrijdag 2 oktober 2020 @ 12:04:
[...]

Het is over het algemeen zo dat het project plan (wat er nu dus al ligt) al geen gouden randjes kent, waardoor je er niets uit kan laten vallen en elke wijziging enkel extra werk is.

Dat is meestal een niveau hoger. Projectplan: wk 27, inrichten logistiek proces.

De discussie in wk 27: "ja, het is eigenlijk toch wel handig als die ontvangststickers er automatisch uitkomen zonder dat we op de ok knop moeten drukken"

[mcDavid]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:38:
@Kanarie, het betreft hier niet de ontwikkeling van een software product, maar de implementatie van een softwarepakket. Ivm een aanbestedingstraject heeft het eerste deel van het project (de aanschaf van het pakket) al een jaar gelopen. We zijn nu toe aan de implementatie. Omdat er tot een paar weken terug nog geen sprake van scrum was, is er al met het projectplan begonnen.

Ik zou eerst eens met de scrum master om de tafel gaan om uit te zoeken of scrum wel de geëigende methode is voor dit project. Scrum werkt voor sommige projecten (software-ontwikkeling is daar vaak een voorbeeld van) heel goed, maar voor veel meer projecten juist heel slecht. Als een project duidelijk te plannen is, is een duidelijke planning maken bijna altijd een beter idee. Zoek de "stacey matrix" even op, en bepaal eerst (samen) of scrum uberhaupt de juiste aanpak is.

Jij geeft aan dat er binnen het scrumteam geen projectleider is, zo ver was ik ook. Dat weet straks het hele scrumteam van vier of vijf mensen. Maar de overige 500 mensen weten dat ik projectleider ben.
Als, om welke reden dan ook, de acceptatie van het pakket moeizaam gaat of als er andere tegenslag is, kent iedereen mijn naam.

Ik vraag me af of ik als "projectleider" die onderdeel uit maakt van een scrum team, maar geen projectleidersrol heeft, voldoende mogelijkheid heb om het project in goede banen te leiden. Kan ik die rol pakken, of is dat not-done binnen een scrum team.

De basis van scrum is dat er een hoge mate van vertrouwen is in de capaciteiten van het scrum-team. Als je dat vertrouwen niet hebt (en ook niet op kunt brengen), dan gaat het bij voorbaat niets worden.

Als Product-owner is je taak om de prioriteiten te sturen. Je overlegt met de stakeholders welke issues de meeste waarde opleveren, met het team wat realistiche tijdspaden zijn, en zo bepaal je welke issues er als eerste opgepakt gaan worden. Maar de uitvoering is volledig de verantwoordelijkheid van het ontwikkelteam zelf. Je daarin mengen is idd "not done" en een complete ondermijning van het scrum-principe. Als je dit toch doet of probeert, zal de scrum-master je daarin tegenhouden (als die zijn taak goed doet).

[inbedrijf]

Uiteindelijk is wat @DexterDee omschreef is ultieme wat je wilt bereiken!

Maar voordat je daar bent hebt je een aantal tussen fases nodig waarin je een transitie ingaat van jullie huidige processen naar het volledige Agile werken.

Het is heel belangerijk dat als jullie de stap willen maken er voor zorgen dat jullie mensen hebben die deze transitie al een keer hebben gedaan of ervoor zorgen dat jullie een adviseur/ begeleider vinden die jullie in dit traject kan ondersteunen en begeleiden.

Als jullie dit traject ingaan zonder echt gedegen kennis van de materie, is de kans dat het slaagt klein. Met alle gevolgen van dien, zoals je zelf aangeeft waar jij het risico ziet voor jou rol als projectleider.

Daarbij heb je teams kennis laten maken met scrum maar niet zoals scrum hoort te zijn. En dat zul je daarna allemaal weer moet corrigeren.

De eerste stap is altijd moeilijk, sta open voor verandering, maar zorg wel dat je weet wat je aan het doen bent.

Wij zijn als organisatie nu 4 jaar bezig met Agile/ Scrum en dat is gegaan met vallen en opstaan, bijschaven en luisteren naar alle collega's. En elk kwartaal vinden we iets wat we kunnen verbeteren of iets waar we beter mee kunnen stoppen.

Succes!

DexterDee schreef op donderdag 1 oktober 2020 @ 15:21:
Scrum teams zijn zelfsturend, een projectleider in de zin dat er iemand is die de voortgang bewaakt van de teamleden en de milestones in het project is er niet. Alle teamleden zijn zelf verantwoordelijk voor hun voortgang en worden geacht elkaar scherp te houden. Het team bepaalt ook zelf hoeveel werk ze op kunnen pakken en hierop geeft iedereen z'n commitment af. Van "taak X moet af op Y, zorg er maar voor" is in een scrum team géén sprake.

De product owner is expliciet géén projectleider, maar is eigenaar van de lijst van werk die gedaan moet worden. Hij is verantwoordelijk dat deze "backlog" gevuld is met concrete taken die de teamleden op kunnen pakken. De product owner bepaalt in welke volgorde welke taken opgepakt worden, dit doet hij/zij aan de hand van de business value. De hoogste business value taken (ofwel waar haalt het project/bedrijf het meeste profijt uit in de breedste zin van het woord) worden als eerste opgepakt. De product owner doet aan stakeholder management. Dit wil zoveel zeggen als het afwegen van de belangen van alle belanghebbenden. Dus de directie, de klant, leveranciers, consultants, ontwikkelaars, etc... Hierbij heeft hij/zij de absolute eindverantwoordelijkheid en heeft niemand, zelfs niet de directeur/directie van het bedrijf of de klant, mandaat om een beslissing door te drukken of iets naar voor of naar achteren te plaatsen. Uiteraard kan een specifieke wens wel leiden tot een hoge business value en op die manier bovenaan de lijst komen. Het eindoordeel ligt echter bij de product owner, deze heeft namelijk de beste overall view op het project.

In een Scrum traject is het niet mogelijk om in detail tegen de "klant" te zeggen wanneer iets af is. Dat vereist een detailniveau van uitwerking die niet past bij de werkwijze. Het scrumteam commit niet aan een deadline in de toekomst, maar commit zichzelf tot het telkens opleveren van "increments", deeloplossingen, die al in gebruik genomen kunnen worden. En dat op zo'n manier dat er telkens de meeste "business value" geleverd wordt. De klant krijgt hierdoor dus het meeste waar voor z'n geld, omdat er altijd aan de meest belangrijke dingen gewerkt wordt.

Een korte feedback loop en profiteren van voortschrijdend inzicht is cruciaal in een Scrum team. Daarom worden de werkpakketten (stories) niet al te ver van tevoren helemaal geanalyseerd en uitgeschreven. Door te "refinen", ofwel de werkpakketten uit te werken als ze nodig zijn en vlak daarvoor, profiteer je maximaal van wat je in het verleden geleerd hebt. De product owner kan dan ook constant nieuwe afwegingen maken in hoe belangrijk de individuele taken zijn en hierop sorteren. Elke sprint, ofwel vaste tijdsperiode van werk, wordt dan ook afgesloten met een "retrospective" meeting waarin het team evalueert wat er goed en fout ging en wat er verbeterd moet worden om in de volgende 'sprint" succesvoller te zijn.

Essentieel met scrum is het opleveren van increments (sprint deliverables) die "productieklaar" zijn, ofwel praktisch bruikbaar. Zo kun je zo vroeg mogelijk al profiteren van de resultaten van een lopend project. Om te garanderen dat iets goed genoeg is uitgewerkt om op te pakken spreekt het scrum team intern af waar een werkpakket (story) aan moet voldoen. Dit wordt de "definition of ready" genoemd. En om objectief te bepalen of een story ook écht klaar is, wordt een "definition of done" opgesteld. Hierin staat SMART omschreven wanneer een taak ook écht af is. Zo kun je denken aan de verplichting om een bepaalde feature ook op een test- of acceptatie omgeving uit te rollen of de beschikbaarheid van bepaalde uitrol automatisering.

Er zijn twee gapende valkuilen met Scrum die ik telkens weer tegenkom:

1. Geen management / directie commitment op deze werkwijze. Scrum masters en product owners die hierdoor niet het juiste mandaat krijgen om hun werk fatsoenlijk te doen. Managers, directie (en soms klanten) die het team en de product owner dwingen om in te breken in lopende sprints om werk toe te voegen, te veranderen of teamleden totaal ongerelateerde werkzaamheden te laten verrichten.

2. Klanten die de scrum werkwijze niet accepteren en verplichten om met een lange termijn planning en een exact kostenplaatje te werken. Dit soort klanten vinden het vaak wel hip om met Scrum te werken, maar willen wel een fixed price project draaien ala waterval.

De PSM I en PSPO I trainingen zijn een erg handige eerste stap om de basisbeginselen van scrum onder de knie te krijgen.

[Cereal]

Er staan al heel wat wijze dingen hierboven, ik wil daar nog even wat over training/certificering aan toevoegen:

In mijn ervaring is het noodzakelijk dat iedereen die betrokken is een basiskennis van scrum heeft, en hetzelfde vocabulair heeft. Dus het is niet vreemd iedereen een PSM I of PSD training te geven. Daarnaast heb ik in m'n PSM II training geleerd welke issues je tegen kunt komen in de bredere context en hoe je hiermee om kunt gaan; wat de Scrum waardes écht betekenen en hoe je hier aan kunt werken. (Courage, Focus, Respect, Openness, Commitment).

Zo ben ik er achter gekomen dat na de eerste stappen van scrum het belangrijkste is om aan de cultuur te werken, zowel binnen het team als in de directe context, er zijn zoveel zaken die normaal lijken, die niet kunnen in scrum (managers die binnenlopen om 'even' iets aan een developer te vragen om uit te zoeken, of een klant die binnen een dag iets moet hebben ipv op de afgesproken sprintreview).

Verder is het concept 'het team commit aan de sprint backlog' vervangen door het team forecast op basis van resultaten in het verleden dat men x aantal stories gedaan krijgt binnen de sprint. Dit haalt de 'projectmanagement druk' van de ketel en maakt het een stuk realistischer.

Als overall advies zou ik zeggen: fijn dat je in een omgeving zit waar je de kans krijgt, binnen agile is het een groot goed om te experimenteren, te evalueren en bij te stellen, dus spring in het diepe, stuur bij en zie het als een stap op een reis die je een hoop flexibiliteit en waarde kan leveren.

[jan390]

Herkenbaar dit. Problemen met implementaties en Scrum moet het gaan oplossen.Mission Impossible.

Ik zou de volgende stappen nemen:
1) ga naar je manager en vraag wat je rol is. Zodra hij aangeeft dat je PM bent geeft je aan dat die er niet is in Scrum. Geef aan dat rollen en verantwoordelijkheden veranderen en dat een cursus (ook voor je manager) een must is om te starten. Van je scrum master die aangeeft dat training niet nodig is, heb ik (onder hem te kunnen) nu al geen goede indruk.

2) Stem met je manager af wat je rol gaat worden: De product owner is inhoudelijk verantwoordelijk, de scrum master faciliteert ht team en de PO. Voor beide moet je je anders gaan gedragen. Het team wordt zelfsturend (in je 1e project gaat dit hoogstwaarschijnlijk nog niet lukken). Stem dit ook duidelijk af met je manager. "men" gaat anders naar het project moeten kijken en krijgt ook andere informatie van mensen die nieuwe rollen invullen.

3) Van waterval naar Scrum is een cultuurverandering. Dat ga je niet met 1 project redden. Geef aan dat je wilt experimenten en elementen hier van wilt implementeren die jullie organisatie de meeste winst opleveren.

4) Het probleem wat jullie (als ik het goed lees) willen oplossen is draagvlak vergroten. Hier kun je demo's voor gebruiken na een sprint (aanwezigheid verplichten!). Hier kunnen de gebruikers zien welke kant het opgaat, krijgen gevoel wat er gebeurt en kunnen opmerkingen plaatsen. Deze neemt de PO altijd mee en plaatst die op de Product Backlog. Afhankelijk van de "added Value" komt hij hier hoger of lager op te staan.

Mijn indruk is dat dit is waar jullie naar opzoek zijn (stakeholders willen op de hoogte gehouden worden en invloed kunnen uitoefenen). Mogelijk helpt hier (ongeacht de projectaanpak) verandering van afstemming en communicatie ook bij. Neem ze mee in het traject, informeer ze en neem alle voorstellen en wijzigingen mee. Daar is de Product Backlog echt een supermiddel voor.

Sterkte met het project

[TheGhostInc]

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:09:
Er is een externe scrummaster van een andere afdeling, verder werkt niemand volgens de scrum methodiek of is daarin getraind.

Kansloos, mijn persoonlijke ervaring is dat het een paar jaar kan duren voordat de hele organisatie 'het snapt', als je binnen 6 maanden alles redelijk hebt draaien, mag je in je handjes knijpen.

Heel af en toe zie je een succesje, maar dat zijn vaak kleine projectjes, weinig risico en met een jong team, waarbij je nog kunt afvragen of er echt gescrumd is, of dat er gewoon een specsheet is afgewerkt in 2 wekelijkse etappes.

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:09:

• Ik heb als projectleider het projectplan en deimplementie tot in detail uitgewerkt met de leverancier. Hoe verhoudt zich dat tot scrum

De leverancier gaat volledig met jullie mee scrummen, toch?

Boekensteun schreef op donderdag 1 oktober 2020 @ 14:09:
Zie ik het scrummen te somber in, moet ik het gewoon maar over mij heen laten komen of zijn bovenstaande argumenten voldoende om mij hard te maken tegen scrum in dit geval, of misschien zelfs wel mijn rol als projectleider neer te leggen.

Zoals gezegd, een projectleider bestaat niet in scrum, dus dan sta je al 1-0 achter.

Tip, verzin een leuk sausje, noem dat scrum en betrek de verschillende afdelingen in een 2 wekelijkse cycle en vier af en toe een milestone. Het wordt dan een soort show die je opvoert en iedereen is blij. Met de scrummaster ga je brainstormen welke elementen van scum 'leuk' zijn om te gebruiken en welke je niet meeneemt.

Alternatief is dat je daadwerkelijk gaat scrummen en dat je binnen 2 maanden een gesprek hebt met je baas dat het toch niet zo'n succes is en de organisatie er nog niet klaar voor is.

[supersnathan94]

Oke ik hoor hier allerlei verhalen over hoe het zou moeten, en die mensen hebben helemaal gelijk. echter zie ik in de praktijk toch vaak wel andere dingen gebeuren. Als ProductOwner Ben je namelijk wel politiek verantwoordelijk voor wat er wanneer af is en in welke hoedanigheid. Als jij het als PO niet eens bent met de implementatie, omdat het functioneel niet bied wat jij zoekt dan is dat nog steeds jouw verantwoordelijkheid.

Een scrum team is zelfsturend, maar dat betekent niet dat er geen leiding nodig is. Scrum is met name een methodiek om transparantie te bieden aan alle partijen involved. Zo helpt het om de ontwikkelaars mee te nemen in alle fases van ontwerp en uitwerkingen daarvan, want zij kunnen jou ook goed helpen om eventuele bottlenecks en impediments al te zien voordat het werk gedaan moet gaan worden.

"Hee deze story hier, die clasht een beetje met deze functionele eis hier" ,of "Hee als we dit gaan doen moeten we ff vragen bij die en die, want dat team is toen hier en hier tegenaan gelopen"

Zoals gezegd, een projectleider bestaat niet in scrum, dus dan sta je al 1-0 achter.

Mwah dat denk ik niet. uiteindelijk is het stiekem een andere invulling van de rol en niet heel veel anders. als projectleider ben je er verantwoordelijk voor dat afspraken nagekomen worden. Als Product Owner ook. In beide gevallen ben je politiek verantwoordelijk, maar heb je eigenlijk niks met dagelijks werkzaamheden te maken. als projectleider ben je misschien meer direct verantwoordelijk voor planning dan als product owner, maar ik denk dat de de rolverdeling best wel logisch ligt.

Tip, verzin een leuk sausje, noem dat scrum en betrek de verschillende afdelingen in een 2 wekelijkse cycle en vier af en toe een milestone. Het wordt dan een soort show die je opvoert en iedereen is blij. Met de scrummaster ga je brainstormen welke elementen van scum 'leuk' zijn om te gebruiken en welke je niet meeneemt.

Hier ben ik het wel mee eens. Probeer vooral geen scrum te doen omdat scrum, maar kijk welke processen vanuit scrum interessant zijn om te doen. Denk dan aan 2 wekelijkse sprints, retrospectives, refinements en Stand-ups (hoewel dat niet per se scrum hoeft te zijn). pokersessies en vooral bucket estimations zijn ook handig om te gebruiken vanuit het oudere projectleidersschap, klopt mijn planning ongeveer met wat het team inschat. Dan kun je namelijk op zijn scrums nog gaan bijsturen.

Oh houd daarbij rekening dat storypoints niet staan voor tijd, maar voor complexiteit. Complexiteit schaalt niet lineair met tijd en velocity neemt toe in de tijd naarmate het team elkaar en de materie beter begrijpt. Neem dat dus mee in je voorspelling.

Ga vooral lekker sparren met de scrummaster om tot een leuke opzet te komen. Dit is een kans om iets nieuws te leren. Pak die.

[bomberboy]

supersnathan94 schreef op vrijdag 2 oktober 2020 @ 13:59:
Hier ben ik het wel mee eens. Probeer vooral geen scrum te doen omdat scrum, maar kijk welke processen vanuit scrum interessant zijn om te doen. Denk dan aan 2 wekelijkse sprints, retrospectives, refinements en Stand-ups (hoewel dat niet per se scrum hoeft te zijn). pokersessies en vooral bucket estimations zijn ook handig om te gebruiken vanuit het oudere projectleidersschap, klopt mijn planning ongeveer met wat het team inschat. Dan kun je namelijk op zijn scrums nog gaan bijsturen.

Volledig eens met bovenstaande. Ook wij hebben hier een soort van hybride gedefinieerd sterk in lijn met bovenstaande. (Want je klant of management wil soms geen scrum). En scrum is ook niet altijd de oplossing zoals door een aantal mensen al aangehaald. Een hybride vorm kan zeker een meerwaarde zijn.

Eén aandachtspuntje daarbij: zorg wel dat de rollen en verantwoordelijkheden duidelijk zijn voor iedereen. Dat geldt voor een traditioneel project, voor een volledig scrum team, maar zeker ook voor een hybride oplossing. Doordat er soms verschillen zijn is er altijd een kans dat een aantal mensen zullen zeggen: "volgens scrum zit dat bij rol X" en iemand anders "in een project zit dat bij rol Y". En dan heb je 2 mogelijke gevolgen. Of niemand neemt de verantwoordelijkheid, of meerdere proberen het te doen op een conflicterende wijze. En je wil doorgaans geen van beiden

[michielRB]

Probeer vooral geen scrum te doen omdat scrum,

Het hele verhaal komt bij mij sterk over dat dit de hoofdreden is dat dit vanaf boven opgelegd wordt. IMO gedoemd te mislukken en gaat tegen heel veel schenen schoppen, inclusief de TS, die zijn rol als PL volledig onderuit ziet gaan, maar straks achteraf wel verantwoordelijk wordt gehouden voor een mislukte implementatie.

[BCC]

Je kan gelukkig ook een beetje waterval en een beetje scrum doen , het is niet alles of niets. bjjvoorbeeld in korte iteraties je projectplan uitvoeren en na een iteratie je plannen bijstellen voor de volgende iteraties. Maar dit Project scrummen voelt idd wel een beetje als mosterd na de maaltijd

[supersnathan94]

michielRB schreef op vrijdag 2 oktober 2020 @ 14:55:
[...]

Het hele verhaal komt bij mij sterk over dat dit de hoofdreden is dat dit vanaf boven opgelegd wordt. IMO gedoemd te mislukken en gaat tegen heel veel schenen schoppen, inclusief de TS, die zijn rol als PL volledig onderuit ziet gaan, maar straks achteraf wel verantwoordelijk wordt gehouden voor een mislukte implementatie.

Daar ben ik het niet helemaal mee eens. Project lead en product owner zijn in de basis dezelfde rol, maar dan anders ingevuld. Politieke verantwoordelijkheid ligt nog steeds bij die rol. Globale planning en afstemming ligt nog steeds bij die rol. Aanspreekpunt is nog steeds die persoon. Het is een andere term voor de invulling van leiderschap.

Als dit een proeftuin wordt voor SCRUM dan is dit een kans om daar ervaring mee op te doen. Ik denk namelijk dat dit heel goed iteratief kan. Scrum an sich moet alleen niet het doel zijn. Als management denkt dat bepaalde facetten van scrum hier in een toevoeging kan zijn dan is het op zijn minst de moeite waard om dit eens uit te zoeken en als ik de TS bekijk staan OP daar redelijk neutraal in met terechte vragen hoe het werkt

[TheGhostInc]

supersnathan94 schreef op vrijdag 2 oktober 2020 @ 15:34:
Daar ben ik het niet helemaal mee eens. Project lead en product owner zijn in de basis dezelfde rol, maar dan anders ingevuld. Politieke verantwoordelijkheid ligt nog steeds bij die rol. Globale planning en afstemming ligt nog steeds bij die rol. Aanspreekpunt is nog steeds die persoon. Het is een andere term voor de invulling van leiderschap.

Alleen in hiërarchische organisaties kom je hier (soms) op.
Maar juist wanneer de PO die (volledige) verantwoordelijkheid niet krijg/neemt zie je dat scrum veel beter werkt. In de beleving van management moet 'iemand de baas' zijn. Terwijl juist het hele idee is dat je dat deelt.

Uiteindelijk is het veel meer een cirkel, van business, via PO, naar team en dan weer terug (oplevering).

Zodra een PO naar eindverantwoordelijkheid gaat, dan zie je dat hij/zij ineens een mening begint te krijgen over complexiteit, technical dept, architectuur en dat je al snel een team krijgt dat 'maar gewoon doet wat er opgedragen wordt'. Weg ownership, weg winst.
Er zijn dagen dat ik echt bij een PO aankom met: "Wil je rood, of wil je blauw" en dan mag hij/zij kiezen (of de business), maar meestal is dat een volledig organisch process, waarbij iedereen vanuit zijn expertise zijn steentje bijdraagt. Dit is heel veel ontwikkelwerk, maar dit is wel makkelijk te testen, of deze shortcut levert ons heel veel rework op als je ooit nog een extra optie wil, de business wil echt maar 2 opties of juist nog 10 opties in de toekomst etc. etc.
Maar als mijn PO niet 'meewerkt' heb ik hem ook binnen een sprint buitenspel. Verdubbel ik de schattingen en ga ik gewoon lekker mijn eigen gang. En bij een PL is dat niet anders, gewoon uurtjes schrijven en als het niet af is? Dan mag de PL gewoon meer uren gaan regelen.

Ik heb genoeg projecten gedraaid waarbij je creatief moest boekhouden met uren of sprints waarbij we de sprint haalde, maar de helft van het werk niet op het bord stond. Maar zodra de boekhouding uit beeld verdween en we met z'n allen 1 doel hadden, dan kregen we vleugels en het halen was dan gewoon 'kicken'.