[SCRUM] Werkgever wil team-lead ook product owner maken

[Anoniem: 741833]

Beste Tweakers,

Ik werk in een grote organisatie als software-ontwikkelaar, en we pretenderen dat met SCRUM te doen in een team van 7-9 man (al wat aan de grote kant volgens mij).

Nu probeer ik altijd zo veel mogelijk écht SCRUM toe te passen, maar soms is het lastig om dat in zo'n grote (logge) organisatie goed te implementeren.

Nu weer, want er zijn hardnekkige, dringende aanwijzingen dat de product owner naar een ander team gaat (krijg daar ook een andere rol), en dat de huidige lead developer daarnaast als product owner zal gaan functioneren.

Gevoelsmatig is dat echt het slechtste wat je qua rolverdeling in een SCRUM team kan doen.

Wat vinden mijn mede-SCRUMmers hier van? Kan dit? Of moet ik dit kosten wat het kost proberen te voorkomen?

[Juup]

SCRUM is als een religie: hoe strenger je in de leer bent hoe meer je vasthoudt aan de scrum methodieken.

Persoonlijk ben ik pragmatischer ingesteld: doe wat handig is.
Als deze persoon met 2 rollen er dan een zooitje van maakt kun je hem er op aanspreken.

[Laurens-R]

Van de technische team lead een product owner maken slaat nergens op. Los van of scrum wel/niet gebruiken, moet er gewoon een afgevaardigde vanuit de business zijn die de prioriteiten aangeeft, de fuctionele keuzes maakt, aftekent etc. Nu zit je alsnog in een situatie waarin het project team zelf de koers kan bepalen die mogelijk niet aansluit bij de wensen van de business. De business owner rol is juist bedacht zodat de business meer betrokken word en (nog belangrijker) het projectteam niet afgerekend kan worden op een keus die de business zelf maakt (in de vorm van de product owner).

Je introduceert de mogelijkheid dat het team weer iets over de schutting pleurt waar de business het maar mee moet doen. En dan ben je als team verantwoordelijk voor de gemaakte kosten en evt redesign, bugfixing, rebuild, etc etc etc.

[ Voor 17% gewijzigd door Laurens-R op 26-02-2016 18:47 ]

[koekiemonster]

Product owner is een rol voor de line / business. Ofwel daar waar de wens oorspronkelijk vandaan komt. Hij of zij vertegenwoordigt die zijde.

Het devteam kan nooit totale macht krijgen.

Edit: wat Laurens zegt.

[TI_Observer]

Op korte termijn werkt dat wel, maar je moet wel op zoek naar een (onafhankelijke) PO voor een goede/gezonde werking van scrum.

[Rutix]

Een PO moet mandaat hebben om beslissingen te nemen, dit zijn vaak beslissingen die op business niveau moeten worden genomen. Dit kan dus niet de lead developer zijn en dan wel om de redenen die Laurens-R al noemt. Stakeholder vertegenwoordiging is uitermate moeilijk als je ook in het dev team zit.

[Croga]

Juup schreef op vrijdag 26 februari 2016 @ 18:15:
SCRUM is als een religie: hoe strenger je in de leer bent hoe meer je vasthoudt aan de scrum methodieken.

Persoonlijk ben ik pragmatischer ingesteld: doe wat handig is.
Als deze persoon met 2 rollen er dan een zooitje van maakt kun je hem er op aanspreken.

Eensch én oneensch.....

"De product owner moet uit de business komen" is zo'n religieuze uitspraak. En ja, dat zou leuk zijn, ware het niet dat de meeste karakteristieken van een Product Owner nou eenmaal niet beschikbaar zijn bij "de business" (overigens; als je religieus wilt worden: Er bestaat geen business!! Het concept Business/IT heeft niets met Scrum te maken en stellen dat "de product owner uit de business moet komen" is dan ook een gigantisch Scrum Smell).
De Product Owner moet vooral heel goed in staat zijn om stakeholders te managen en prioriteiten te stellen. "Vroeger" werd dat door een Project Manager gedaan. Daarmee wil ik niet zeggen dat project managers persé goede POs zullen zijn maar de "oude" IT Project Manger is een stuk beter in staat om PO werk te doen dan iemand uit de "oude" business.
Zelfs als je geloofd dat er een scheiding tussen IT en Business is: De Product Owner is onderdeel van het Scrum team. Als de scheiding er is valt het Scrum team smack-bang in the middle van IT en is de PO dus ook expliciet een IT rol. Overigens ook niet heel raar; ook als de scheiding IT/Business bestaat is De Business geen homogeen geheel. De PO heeft stakeholders uit alle delen van "de business" en als hij zelf onderdeel is van één van deze delen is hij dus niet meer in staat om helder stakeholder management te doen.

Het probleem is echter wel; of die ene persoon er toe in staat is dit te doen zonder er een zootje van te maken ligt maar voor een minuscuul klein deel aan de persoon. Je wilt gewoon niet dat één persoon zowel beslissingen neemt over prioriteiten als een deel van het programmeer werk doet. Het gevolg gaat onherroepelijk zijn dat zijn mening in discussies de waarheid wordt waarmee je de creativiteit van het team in één klap dood slaat.
De invloed van de persoon hierop is slechts 5%. De invloed van het systeem waarin de persoon werkt is 80%. Door het systeem op de verkeerde manier aan te passen (in dit geval door de persoon 2 rollen te geven) gaat meer kapot maken dan de persoonlijkheid van deze persoon ooit goed kan maken.
(Het Systeem is in deze de manier waarop je organisatie in elkaar steekt)

Scrum stelt dat er drie rollen zijn:
- Scrum Master
- Product Owner
- Developer

Deze drie rollen zijn inherent oncombineerbaar. Combineren van deze rollen gaat je onherroepelijk problemen opleveren. Of je die problemen ziet of herkent is de grote vraag. Wat je er aan kunt doen is eenvoudig: Niet combineren.

[BarôZZa]

Volgens mij is het altijd belangrijk om te onthouden dat scrum geen doel op zich is, maar een middel om agile te blijven. Helaas zie je ook nog wel eens in de praktijk dat het agile gedeelte min of meer wegvalt doordat developers zich graag obsessief vastklampen aan structuur, procesjes en regelmaat.

Ik mis in deze situatie teveel informatie om iets zinnigs te zeggen.

Want met welk doel voor ogen willen ze hem project owner maken? Zien ze dat het er vooral zaken nog technisch verbeterd moeten worden en kiezen ze hem daarom? Is het iemand met ruggengraat of willen ze hem juist op die positie hebben zodat de stakeholders gemakkelijk hun issues erdoorheen kunnen fietsen?
Is het simpelweg diegene met de beste visie voor het project? Zo nee, is er iemand anders beschikbaar?
Is project owner bij jullie iets waar uberhaubt genoeg werk voor is om iemand fulltime op te zetten? Maak je kritieke systemen voor patiënten of banken of werk je aan een iOS app voor amtenaren waarin ze virtueel kunnen pennenlikken en de wens vooral is dat er zoveel mogelijk pennen inzitten?

Projectowners vanuit de businesskant heb ik ook rampzalige dingen zien doen. Lukraak zo snel mogelijk zoveel mogelijk features voor klanten inbouwen (waarbij de technische uitwerking ook bedacht werd door die klant) en eindigen met een brak traag buggy platform en developers die wegrennen.

Kortom, ik denk dat je het wat breder moet trekken en het niet alleen vanuit developersperspectief moet redeneren. Aan een prachtig perfect scrumproces heb je ook niet veel als dat betekent dat er een waardeloze project owner zit

[Hydra]

Ik vind het onnodig om te panisch te doen over wie exact de rol van PO moet hebben. In de praktijk is het belangrijkste gewoon dat die persoon goed de business snapt. Dit kan prima een lead developer zijn, mits hij ook echt de business vertegenwoordigd.

[Rutix]

BarôZZa schreef op zaterdag 27 februari 2016 @ 22:08:
Projectowners vanuit de businesskant heb ik ook rampzalige dingen zien doen. Lukraak zo snel mogelijk zoveel mogelijk features voor klanten inbouwen (waarbij de technische uitwerking ook bedacht werd door die klant) en eindigen met een brak traag buggy platform en developers die wegrennen.

Kortom, ik denk dat je het wat breder moet trekken en het niet alleen vanuit developersperspectief moet redeneren. Aan een prachtig perfect scrumproces heb je ook niet veel als dat betekent dat er een waardeloze project owner zit

Bedoel je met een Project owner, Product Owner ? Project owner ken ik niet binnen scrum . Zo ja dan is er al iets goed mis als de Product owner de technische uitwerking doet, dat mag volgens scrum helemaal niet. De Product Owner mag alleen de features prioriteren en de dev team moet dan zeggen hoe groot die feature is. Gebaseert daarop mag de Product Owner natuurlijk de prio aanpassen maar hij mag nooit bepalen hoeveel er in een sprint komt. Dat doet de dev team allemaal.

Hydra schreef op zondag 28 februari 2016 @ 16:00:
Ik vind het onnodig om te panisch te doen over wie exact de rol van PO moet hebben. In de praktijk is het belangrijkste gewoon dat die persoon goed de business snapt. Dit kan prima een lead developer zijn, mits hij ook echt de business vertegenwoordigd.

Dat zou prima een lead developer kunnen zijn mits hij ook stopt met developen. De meeste mensen kunnen niet twee petten op hebben en zich niet laten beïnvloeden bij 1 pet door de andere pet. Het kan natuurlijk zijn dat hij dat wel kan maar dat zou dan echt een uitzondering zijn.

[Hydra]

Rutix schreef op zondag 28 februari 2016 @ 19:03:
Dat zou prima een lead developer kunnen zijn mits hij ook stopt met developen. De meeste mensen kunnen niet twee petten op hebben en zich niet laten beïnvloeden bij 1 pet door de andere pet. Het kan natuurlijk zijn dat hij dat wel kan maar dat zou dan echt een uitzondering zijn.

Compleet niet me eens. Heb in een (tech) project gezeten waar dat helemaal prima werkte. Zo moeilijk is het niet om de snappen wat de business precies wil en dat voorop stellen. Genoeg devs die dat kunnen; we zijn niet allemaal dichtgetikte autisten

[Laurens-R]

Hydra schreef op zondag 28 februari 2016 @ 19:27:
[...]


Compleet niet me eens. Heb in een (tech) project gezeten waar dat helemaal prima werkte. Zo moeilijk is het niet om de snappen wat de business precies wil en dat voorop stellen. Genoeg devs die dat kunnen; we zijn niet allemaal dichtgetikte autisten

En iedereen is blij zolang dat goed gaat. En als het goed gaat krijg je ook een flinke pluim als dev team. Als het niet goed gaat draag je echter ook volledige verantwoordlijkheid als team. Het 'fijne' van een business PO vind ik juist dat deze de funtionele/business verantwoordelijkheid draagt. Dat reduceert de complexiteit van het stakeholdermanagement aanzienelijk. En als het fout gaat heeft de business direct invloed op de oplossing en sta je als team een stuk sterker in de schoenen, met een stuk minder blaming en shaming tot gevolg... En als ze dit alsnog proberen is het iig een stuk gemakkelijker te weerleggen. (Want de business was op elk moment in de gelegenheid om bij te sturen)

Heeft verder niets te maken met technische autisten die niet kunnen praten met de business, maar met verhogen van betrokkenheid en spreiding van verantwoordelijkheid en risicomanagement.

[ Voor 11% gewijzigd door Laurens-R op 28-02-2016 20:58 ]

[bonzz.netninja]

Puur theoretisch maakt het helemaal niet uit wie een PO is of wat zijn achtergrond is. Iemand vanuit de business kan, maar hoeft zeker niet. Zijn verantwoordelijkheid is om uiteindelijk er voor te zorgen dat de meeste waarde wordt geleverd. Dat is natuurlijk meestal een vertaling van de business behoeften en wensen. Als een Tech Lead dat toevallig heel goed kan is dat prachtig

Het wordt echter wel problematisch als iemand uit het ' developers team' tevens ook PO is. In SCRUM (en in de Guide) is dat eigenlijk niet echt goed mogelijk. Het scrumteam is immers de PO + devteam. En de PO is een ' sole person' met maar 1 verantwoordelijkheid. En dat kan natuurlijk niet als hij tegelijkertijd ook verantwoordelijkheid van het dev. team draagt.

[Rutix]

Hydra schreef op zondag 28 februari 2016 @ 19:27:
[...]


Compleet niet me eens. Heb in een (tech) project gezeten waar dat helemaal prima werkte. Zo moeilijk is het niet om de snappen wat de business precies wil en dat voorop stellen. Genoeg devs die dat kunnen; we zijn niet allemaal dichtgetikte autisten

Mooi dat in het project waar jij zat goed ging . Ik heb projecten meegemaakt waar dit ook gebeurde en waar het niet helemaal lekker liep en dan heb je echt een probleem met het aantonen dat je je niet hebt laten beïnvloeden. Scrum master rol kun je in sommige gevallen prima aan een member in het dev team beleggen (vooral als het al een poosje goed gaat) maar ik ben van mening dat de PO altijd iemand moet zijn die niet in het dev team zit. Of dat dan iemand is die uit de business komt, of dat hij ooit zelf lead developer is geweest of dat het een project manager is maakt niks uit zolang hij maar de mandaat heeft en de stakeholders goed managed (en de meeste waarde levert natuurlijk). Vooral in het geval van de TS waar ik hint uit krijg dat agile/scrum nog niet helemaal is omarmt in de organisatie is het slim om geen dingen te mengen.

[pedorus]

Croga schreef op zaterdag 27 februari 2016 @ 16:27:
Scrum stelt dat er drie rollen zijn:
- Scrum Master
- Product Owner
- Developer

Deze drie rollen zijn inherent oncombineerbaar. Combineren van deze rollen gaat je onherroepelijk problemen opleveren. Of je die problemen ziet of herkent is de grote vraag. Wat je er aan kunt doen is eenvoudig: Niet combineren.

bonzz.netninja schreef op zondag 28 februari 2016 @ 21:09:
Het wordt echter wel problematisch als iemand uit het ' developers team' tevens ook PO is. In SCRUM (en in de Guide) is dat eigenlijk niet echt goed mogelijk.

Stel dat dit klopt, kan iemand dan de volgende zin uitleggen onder Development Team Size?

quote: http://www.scrumguides.or...ide/v1/scrum-guide-us.pdf

The Product Owner and Scrum Master roles are not included in this count unless
they are also executing the work of the Sprint Backlog.

Ik zou vooral product owner en scrum master liever niet combineren, maar er staat echt nergens dat het niet zou kunnen. En als het er wel staat, laat dan maar zien waar het staat

Anoniem: 741833 schreef op vrijdag 26 februari 2016 @ 17:47:
de huidige lead developer

quote: http://www.scrumguides.or...ide/v1/scrum-guide-us.pdf

Scrum recognizes no titles for Development Team members other than Developer,
regardless of the work being performed by the person; there are no exceptions to this rule;

[Laurens-R]

pedorus schreef op zondag 28 februari 2016 @ 23:08:
[...]


[...]

Stel dat dit klopt, kan iemand dan de volgende zin uitleggen onder Development Team Size?

[...]

Ik zou vooral product owner en scrum master liever niet combineren, maar er staat echt nergens dat het niet zou kunnen. En als het er wel staat, laat dan maar zien waar het staat

[...]


[...]

Aangezien scrum master een faciliterende rol is ter ondersteuning van het team (zorgen dat alles in place voor het team om goed z'n werk te kunnen doen, het is nl geen traditionele PM) zou ik dat niet eens het grootste probleem vinden (een scrum master kan prima een 'extern' iemand zijn). De PO bepaalt namelijk de prio's en de volgorde van implementatie op basis van het backlog. Dus in die zin is de rol van een scrum master en PO heel 'compatibel'. Al krijg je dan wel een gecombineerde rol die erg lijkt op een traditionele PM.

Misschien niet ideaal, maar als ik mocht kiezen tussen dat of een dev die PO is... Dan toch maar liever een scrum master met een dubbele rol.

[ Voor 12% gewijzigd door Laurens-R op 29-02-2016 00:11 ]

[Croga]

pedorus schreef op zondag 28 februari 2016 @ 23:08:
Ik zou vooral product owner en scrum master liever niet combineren, maar er staat echt nergens dat het niet zou kunnen. En als het er wel staat, laat dan maar zien waar het staat

Wat waar staat is helemaal niet interessant. We praten niet over een handleiding of een bijbel. We praten over hoe het in de praktijk werkt. En in de praktijk:

- Wil de Product Owner vooral dat het juiste gebouwd wordt
- Wil een ontwikkelaar vooral dat het juist gebouwd wordt
- Wil een Scrum Master vooral de feedback loop verkorten zodat we sneller kunnen reageen op veranderingen
(bron: Henrik Kniberg: Spotify Engineering Practices)

Laurens-R schreef op maandag 29 februari 2016 @ 00:07:
Misschien niet ideaal, maar als ik mocht kiezen tussen dat of een dev die PO is... Dan toch maar liever een scrum master met een dubbele rol.

Dus je wilt graag de PO en de SM combineren? Wat gebeurt er dan als er halverwege de sprint een belangrijke stakeholder tegen de PO zegt "Hey, neem deze ook nog even mee"? Juist, conflict of interest. Niet doen dus.

SM en Dev combineren? Wat gebeurt er dan als er halverwege de sprint een crisis situatie is? Ga je dan die crisis oplossen (als SM zijnde) of gewoon wat meer tijd in programmeren stoppen (als Dev zijnde)? Juist; conflict of interest

Het zijn drie rollen die niet gecombineerd kunnen worden vanwege het simpele feit dat ze werk doen wat met elkaar conflicteert. Één SM die zich over meerdere teams ontfermt is niet ideaal maar kan werken omdat veel impediments systematisch zijn en dus voor meerdere teams gelden. Één PO die zich over meerdere teams ontfermt is niet ideaal maar kan werken als die teams aan hetzelfde product werken. Als je dan toch wilt besparen op die rollen, doe het dan zo. Maar de rollen combineren is Een Slecht Idee (tm).

[bonzz.netninja]

Croga schreef op maandag 29 februari 2016 @ 05:47:
[...]

Wat waar staat is helemaal niet interessant. We praten niet over een handleiding of een bijbel. We praten over hoe het in de praktijk werkt. En in de praktijk:

[...]

Het is wel degelijk interessant. SCRUM werkt omdat de regels zo strikt zijn en de Guide is gewoon de spelhandleiding. Natuurlijk, blijf nadenken maar het is cruciaal dat iedereen volgens dezelfde geschreven spelregels mee blijft doen, anders ondermijn je de positie van je scrum master (en wordt je gewoon minder voorspelbaar omdat de regels blijkbaar niet bestaan/verschillend worden uitgelegd in je team).

In dit geval is natuurlijk beide interessant. Hoe de praktijk werkt (waar hier voornamelijk argumenten worden gegeven) maar ook zeker hoe de Guide hier over denkt.

[Croga]

bonzz.netninja schreef op maandag 29 februari 2016 @ 08:21:
SCRUM werkt omdat de regels zo strikt zijn

Pardon!? Vergeten wat de gouden regel is blijkbaar?
Inspect & Adapt!

De regels zijn een suggestie. De eenvoudige stelling is: Als de regels niet voldoen pas je ze aan. Ten allen tijde!

het is cruciaal dat iedereen volgens dezelfde geschreven spelregels mee blijft doen, anders ondermijn je de positie van je scrum master

Zodra dit het geval is heeft je hele werkwijze niets meer met Agile te maken. Het volgen van de regels kan nooit het doel zijn. Nog sterker; het volgen van de regels kan niet eens een middel zijn (okay, da's niet helemaal waar, afhankelijk van je plaats in en vorm van transformatie).

Scrum zit niet in regeltjes. Scrum zit in mindset. En mindset kun je alleen beperken en vernietigen met regeltjes.

Wat was de eerste regel van het Agile Manifesto ook alweer?......

INDIVIDUALS and INTERACTIONS over PROCESSES and tools.

De scrum processen zijn ten allen tijde ondergeschikt aan de interacties van de individuen en de kennis die dat oplevert.

In dit geval is natuurlijk beide interessant. Hoe de praktijk werkt (waar hier voornamelijk argumenten worden gegeven) maar ook zeker hoe de Guide hier over denkt.

En het mooie is dat de guide hier niets over zegt. De praktijk én de wetenschap achter Scrum, zeggen hier van alles over. De praktijk is het enige wat telt! Dat is namelijk de enige plaats waar je werkelijk te zien krijgt wat er gebeurt.

Scrum is een middel tot een doel. Scrum heeft een aantal patronen vast gelegd. Deze patronen kunnen helpen je eigen beste manier van werken te vinden. Zodra je die patronen tot De Waarheid bombardeert doe je geen Scrum meer maar ben je bezig met SINO. Please don't.

[Laurens-R]

Croga schreef op maandag 29 februari 2016 @ 05:47:
[...]

Wat waar staat is helemaal niet interessant. We praten niet over een handleiding of een bijbel. We praten over hoe het in de praktijk werkt. En in de praktijk:

- Wil de Product Owner vooral dat het juiste gebouwd wordt
- Wil een ontwikkelaar vooral dat het juist gebouwd wordt
- Wil een Scrum Master vooral de feedback loop verkorten zodat we sneller kunnen reageen op veranderingen
(bron: Henrik Kniberg: Spotify Engineering Practices)


[...]

Dus je wilt graag de PO en de SM combineren? Wat gebeurt er dan als er halverwege de sprint een belangrijke stakeholder tegen de PO zegt "Hey, neem deze ook nog even mee"? Juist, conflict of interest. Niet doen dus.

SM en Dev combineren? Wat gebeurt er dan als er halverwege de sprint een crisis situatie is? Ga je dan die crisis oplossen (als SM zijnde) of gewoon wat meer tijd in programmeren stoppen (als Dev zijnde)? Juist; conflict of interest

Het zijn drie rollen die niet gecombineerd kunnen worden vanwege het simpele feit dat ze werk doen wat met elkaar conflicteert. Één SM die zich over meerdere teams ontfermt is niet ideaal maar kan werken omdat veel impediments systematisch zijn en dus voor meerdere teams gelden. Één PO die zich over meerdere teams ontfermt is niet ideaal maar kan werken als die teams aan hetzelfde product werken. Als je dan toch wilt besparen op die rollen, doe het dan zo. Maar de rollen combineren is Een Slecht Idee (tm).

ik zie die conflict of interest niet. Het team lost het probleem op, niet de SM.

Je beschrijft het alsof de SM een PM is. En dat is hij niet als we heel strict naar scrum kijken. Een SM is strict gesproken niets meer dan een facilitator die inhoudelijk niets te zeggen heeft, want het dev team is self-organizing (volgens scrum)

Een dev een SM rol op zich laten nemen gaat prima vanuit dat oogpunt, want het hele team (dus alle devs) lossen de problemen samen op met de PO. De SM zorgt er alleen voor dat dit netjes gebeurd en dat de discussie niet ontspoort. De SM is geen single point of contact oid. Je daily scrum meetings zorgen en trouwens voor dat iedereen met iedereen praat, dus de PO praat per definitie al met iedereen.

[ Voor 5% gewijzigd door Laurens-R op 29-02-2016 08:40 ]

[bonzz.netninja]

Croga schreef op maandag 29 februari 2016 @ 08:30:
[...]

Nou nou...iets minder betweterig en aanvallend mag ook wel. Dat voegt niks toe en is eigenlijk gewoon best wel ongepast.

Je haalt er nu het Agile manifesto bij, maar volgens hadden we het over Scrum. Dat zijn verschillende dingen. Of zoals iemand anders ooit schreef:

Agile and SCRUM are related but distinct. Agile describes a set of guiding principles for building software through iterative development. Agile principles are best described in the Agile Manifesto. SCRUM is a specific set of rules to follow when practicing agile software development.

Daarbij interpreteer je mijn reactie ook niet helemaal zoals ik het bedoelde, dus ik probeer het opnieuw

Misschien moet ik het anders uitleggen maar in Scrum, wat uitgaat van beslissingen nemen op basis van empirisch resultaat, is het natuurlijk essentieel dat je continu werkt via hetzelfde stramien. Dat je blijft werken volgens het framework zodat je veel beter weet hoe het proces loopt en waar kan aan kan gaan sleutelen. Afwijken van het stramien (of afwijken van het framework) laat scrum niet toe. Daarbij worden er in Scrum niet voor niets gesproken over ' rules' en niet over bijvoorbeeld adviezen. Ik begrijp heus waar waar je op doelt en volgens mij zijn wij het helemaal niet oneens, maar stelde ik het iets te zwart wit en las jij dat ook op die manier.

Natuurlijk...we love change! In onze organisatie passen wij ons helemaal suf aan, maar toch zal ik als scrum master altijd waken dat we wel hetzelfde spel aan het spelen zijn, en vrij strikt in de scrum leer zijn. Ik zal er alles aan doen om ons scrum team doel, zelfsturend en zelflerend (op basis van emperisch resultaat), altijd daartoe in staat kunnen laten zijn. Met scrum hebben wij juist een goede manier gevonden om te kunnen reageren op change. (en is vooraf duidelijk en geaccepteerd hoe dan)

Het is trouwens immers niet voor niets dat de scrum.org assessments zo verschrikkelijk strikt zijn op de ' rules' .

[ Voor 34% gewijzigd door bonzz.netninja op 29-02-2016 08:54 ]

[Hydra]

bonzz.netninja schreef op maandag 29 februari 2016 @ 08:45:
Je haalt er nu het Agile manifesto bij, maar volgens hadden we het over Scrum. Dat zijn verschillende dingen. Of zoals iemand anders ooit schreef:

De manier waarop jij met "regels zijn regels" omgaat heb ik het idee dat je het idee achter agile (en dus SCRUM, het is / pretendeerd een agile implementatie te zijn!) niet helemaal begrijpt.

En dat geldt voor meer hier. Ik vind dat er een hoop geneuzeld wordt over theoretische verantwoordelijkheden van team leden. Als het voor je team goed werkt dat je PO ook een dev is (wat helemaal niet gek is als je devs je voornaamste klant zijn), prima. Als dat niet werkt; ook prima. Het allerbelangrijkste is gewoon dat je het proces schikt naar de behoeften van je team. Als je het andersom doet, doe je het per definitie verkeerd.

[Laurens-R]

Hydra schreef op maandag 29 februari 2016 @ 14:45:
[...]


De manier waarop jij met "regels zijn regels" omgaat heb ik het idee dat je het idee achter agile (en dus SCRUM, het is / pretendeerd een agile implementatie te zijn!) niet helemaal begrijpt.

En dat geldt voor meer hier. Ik vind dat er een hoop geneuzeld wordt over theoretische verantwoordelijkheden van team leden. Als het voor je team goed werkt dat je PO ook een dev is (wat helemaal niet gek is als je devs je voornaamste klant zijn), prima. Als dat niet werkt; ook prima. Het allerbelangrijkste is gewoon dat je het proces schikt naar de behoeften van je team. Als je het andersom doet, doe je het per definitie verkeerd.

De scrum guide zegt dat de omschrijving in dat document het minimum is om iets een scrum project te noemen. Dus om een scrum project te draaien moet je minimaal aan die regels voldoen. Het is prima als je dat niet doet, maar dan kan je het ook geen scrum noemen, maar gewoon agile. Half scrummig te werk gaan is gewoon geen scrum (volgens de founders), want dan doe je teveel consessies aan de gedachtegang achter scrum. Dus als de TS een scrum vraag stelt spiegelen we dat tegen de minimum 'regels' die in de scrum guide staan. Want we gaan er dan van uit dat ze het formeel willen spelen.

[ Voor 13% gewijzigd door Laurens-R op 29-02-2016 15:20 ]

[Rutix]

Laurens-R schreef op maandag 29 februari 2016 @ 15:17:
[...]


De scrum guide zegt dat de omschrijving in dat document het minimum is om iets een scrum project te noemen. Dus om een scrum project te draaien moet je minimaal aan die regels voldoen. Het is prima als je dat niet doet, maar dan kan je het ook geen scrum noemen, maar gewoon agile. Half scrummig te werk gaan is gewoon geen scrum (volgens de founders), want dan doe je teveel consessies aan de gedachtegang achter scrum. Dus als de TS een scrum vraag stelt spiegelen we dat tegen de minimum 'regels' die in de scrum guide staan. Want we gaan er dan van uit dat ze het formeel willen spelen.

Dit is zo. Maar nergens in de scrum guide staat dat de rollen niet gecombineerd mogen worden . Dat kun je alleen baseren op uitproberen of uit ervaring met andere scrum teams. Mijn mening is echter wel dat PO combineren met een developer niet echt handig is (maar ik ben dan ook teams gewent die echt high efficiënt proberen te werken) en dat vloeit uit mijn ervaring dat het niet makkelijk is om het te combineren . Ik denk wel dat we kunnen stellen dat we te weinig inzicht hebben in de organisatie en opbouw van TS zijn team.

[BarôZZa]

Rutix schreef op zondag 28 februari 2016 @ 19:03:
[...]

Bedoel je met een Project owner, Product Owner ? Project owner ken ik niet binnen scrum . Zo ja dan is er al iets goed mis als de Product owner de technische uitwerking doet, dat mag volgens scrum helemaal niet. De Product Owner mag alleen de features prioriteren en de dev team moet dan zeggen hoe groot die feature is. Gebaseert daarop mag de Product Owner natuurlijk de prio aanpassen maar hij mag nooit bepalen hoeveel er in een sprint komt. Dat doet de dev team allemaal.

Waar staat dat? Er staat naar mijn weten alleen dat de PO één persoon is. Niet dat diegene niks anders mag doen. Dat is waar veel mensen volgens mij de vergissing maken.
Voor de rest geef je aan waarom het juist geen probleem is. Zo lang de PO alleen de volgorde bepaalt en als team wordt bepaald hoeveel er in de sprint komt is het geen probleem. Diegene zal er juist geen belang bij hebben om teveel in een sprint te proppen, aangezien hij er zelf aan moet werken

SM en Dev combineren? Wat gebeurt er dan als er halverwege de sprint een crisis situatie is? Ga je dan die crisis oplossen (als SM zijnde) of gewoon wat meer tijd in programmeren stoppen (als Dev zijnde)? Juist; conflict of interest

Dat is geen conflict of interest, eerder een conflict of time. De belangen voor beiden zijn hetzelfde. Lijkt me verder ook niet al te lastig: PO heeft altijd de voorrang.

[Croga]

BarôZZa schreef op maandag 29 februari 2016 @ 18:14:
Waar staat dat? Er staat naar mijn weten alleen dat de PO één persoon is. Niet dat diegene niks anders mag doen. Dat is waar veel mensen volgens mij de vergissing maken.
Voor de rest geef je aan waarom het juist geen probleem is. Zo lang de PO alleen de volgorde bepaalt en als team wordt bepaald hoeveel er in de sprint komt is het geen probleem. Diegene zal er juist geen belang bij hebben om teveel in een sprint te proppen, aangezien hij er zelf aan moet werken

Zo werkt het niet. Als de PO ook de Lead Dev is, zal er bijvoorbeeld bij schattingen altijd naar hem gekeken worden. Aangezien zijn belang is dat er lage schattingen zijn zullen er lage schattingen zijn. Als hij vindt dat een bepaald item, vanuit zijn PO rol, wenselijk is zal de schatting dat laten zien, niet hoeveel werk het daadwerkelijk is.

Realiseer je goed dat de persoon daar in dit geval nauwelijks invloed op heeft. Als je PO en Dev combineert ben je het systeem aan het saboteren. Het systeem is verantwoordelijk voor 80% van wat er gebeurt, de persoon voor slechts 5%. Je kunt nog zo'n integer, slim, goed persoon hebben maar als je het systeem saboteerd zal die persoon ook zijn werk niet goed kunnen doen.

Dat is geen conflict of interest, eerder een conflict of time. De belangen voor beiden zijn hetzelfde. Lijkt me verder ook niet al te lastig: PO heeft altijd de voorrang.

errr... we hebben het over combineren van SM en Dev rol, hoezo heeft de PO daar voorrang?
Daarnaast is het wel degelijk een conflict of interest; de Dev heeft als belang om zo snel mogelijk de software weer werkend te hebben, de SM heeft als belang om zo snel mogelijk het proces op orde te hebben. Het feit dat er slechts beperkte tijd beschikbaar is maakt dat alleen nog maar erger.

En wat nu als er geen crisis is maar wel een impediment? Ga je dan die impediment oplossen? Kost moeite en tijd die je ook kunt besteden aan het creëeren van extra software...... Again; conflict of interest.

Realiseer je vooral heel erg goed dat dit allemaal ver voorbij het concept "rationeel" gaat en heel diep op het concept "psychologie". Je kunt nog zo hard zeggen "dan moet die persoon maar goed opletten", de wetenschap zegt (en bewijst) dat het zo niet werkt. Zodra je een dergelijk conflict introduceert zal dit het proces saboteren. Het kan zijn dat een sterk persoon daar iets langer over doet dan een zwak persoon maar het combineren van dit soort rollen gaat onherroepelijk het proces verstoren. Dat is geen vermoeden, dat is keer op keer bewezen.

[Rutix]

BarôZZa schreef op maandag 29 februari 2016 @ 18:14:
[...]

Waar staat dat? Er staat naar mijn weten alleen dat de PO één persoon is. Niet dat diegene niks anders mag doen. Dat is waar veel mensen volgens mij de vergissing maken.
Voor de rest geef je aan waarom het juist geen probleem is. Zo lang de PO alleen de volgorde bepaalt en als team wordt bepaald hoeveel er in de sprint komt is het geen probleem. Diegene zal er juist geen belang bij hebben om teveel in een sprint te proppen, aangezien hij er zelf aan moet werken

Waar staat wat? De rol PO mag nooit de technische uitwerking doen, nooooit. Dat doet het dev team, als iemand developer EN PO is dan mag hij nog steeds nooit met de PO pet op naar de technische uitwerking kijken. Verder ben ik het eens met Croga. Je kunt nog zo je best doen, elke persoon laat zich beinvloeden als er een conflict of interest is.

[BarôZZa]

Croga schreef op maandag 29 februari 2016 @ 18:30:
[...]

Zo werkt het niet. Als de PO ook de Lead Dev is, zal er bijvoorbeeld bij schattingen altijd naar hem gekeken worden. Aangezien zijn belang is dat er lage schattingen zijn zullen er lage schattingen zijn. Als hij vindt dat een bepaald item, vanuit zijn PO rol, wenselijk is zal de schatting dat laten zien, niet hoeveel werk het daadwerkelijk is.

Vanuit zijn rol als PO heeft hij dus totaal geen belang bij een planning die niet gehaald wordt. Overigens is dat de verantwoordelijkheid niet van de PO. De verantwoordelijkheid van de PO is de gekozen richting, niet over hoe ver je die richting ingaat.

errr... we hebben het over combineren van SM en Dev rol, hoezo heeft de PO daar voorrang?
Daarnaast is het wel degelijk een conflict of interest; de Dev heeft als belang om zo snel mogelijk de software weer werkend te hebben, de SM heeft als belang om zo snel mogelijk het proces op orde te hebben. Het feit dat er slechts beperkte tijd beschikbaar is maakt dat alleen nog maar erger.

En wat nu als er geen crisis is maar wel een impediment? Ga je dan die impediment oplossen? Kost moeite en tijd die je ook kunt besteden aan het creëeren van extra software...... Again; conflict of interest.

Realiseer je vooral heel erg goed dat dit allemaal ver voorbij het concept "rationeel" gaat en heel diep op het concept "psychologie". Je kunt nog zo hard zeggen "dan moet die persoon maar goed opletten", de wetenschap zegt (en bewijst) dat het zo niet werkt. Zodra je een dergelijk conflict introduceert zal dit het proces saboteren. Het kan zijn dat een sterk persoon daar iets langer over doet dan een zwak persoon maar het combineren van dit soort rollen gaat onherroepelijk het proces verstoren. Dat is geen vermoeden, dat is keer op keer bewezen.

SM is heel wat anders dan een lead dev. Lead dev bestaat niet binnen scrum en duidt meer op de meest ervaren programmeur met de meeste kennis. Scrum Master is puur iemand die het proces bewaakt. Dat is juist niet technisch. Dat is iemand die in de gaten houdt of er geen extra zaken in de sprint komen, dat de issues compleet zijn en blocking zaken weggenomen worden door vaak weer met andere partijen te communiceren ipv dat ze rechtstreeks de programmeur opbellen.

Bij de SM die programmeert is er dus duidelijk een conflict: als diegene programmeert houdt hij zich niet bezig met het ontlasten van het team. Dreigt een sprint niet gehaald te worden, dan heb je grote kans dat diegene meer gaat programmeren en zijn scrumtaken zal verwaarlozen.

Bij een PO is dat totaal niet het geval aangezien die zich niet in dat proces bevindt. Die bepaalt zoals gezegd puur de richting en communiceert deze naar alle partijen. Er is geen rechtstreekse relatie met development, geen verantwoordelijkheid voor of de sprints afkomen want daar heeft hij geen invloed op. Wat dat betreft zie ik geen probleem als diegene meehelpt met het oplossen van issues.

Kortom:
De PO is verantwoordelijk voor het uiteindelijke product en de SM voor het proces. In mijn optiek is het vaak beter om een technisch persoon als PO te hebben en een meer bedrijfskundige als SM. Helaas zie je meestal het omgekeerde waarbij een programmeur uitgroeit tot SM, waardoor je eindigt met een niet-techneut die beslissingen neemt over een vaak technisch product en een techneut die een bedrijfskundig proces aan het bewaken is. Dan heb je kans dat er onlogische/onverstandige keuzes/prioriteiten worden gemaakt op productniveau, dat het proces stroef verloopt en dat je bovendien ook nog eens de mogelijk beste programmeur geheel niet meer benut omdat diegene niet-technische zaken aan het managen is.

PO en SM combineren lijkt me daarentegen wel heel onverstandig en moeilijk uitvoerbaar. Ik heb het over een PO die daarnaast als dom werkpaard issues oplost door te programmeren

Rutix schreef op maandag 29 februari 2016 @ 23:44:
[...]

Waar staat wat? De rol PO mag nooit de technische uitwerking doen, nooooit. Dat doet het dev team, als iemand developer EN PO is dan mag hij nog steeds nooit met de PO pet op naar de technische uitwerking kijken. Verder ben ik het eens met Croga. Je kunt nog zo je best doen, elke persoon laat zich beinvloeden als er een conflict of interest is.

Dit klinkt als regeltjes stampen zonder precies te begrijpen wat er gezegd wordt. Dat gaat over op welk niveau de technische uitwerking wordt bedacht. Dus dat een PO niet in z'n eentje al een oplossing heeft bedacht voordat het dev team zich ermee heeft bemoeid. Wat vaak al helemaal een ramp is als je een niet-technische PO hebt die niet zijn wensen communiceert, maar een brakke uitwerking daarvan. Het gaat echter over de rol en niet over de persoon PO die in de rol van developer meehelpt met het oplossen van issues. De twee rollen raken elkaar normaal gesproken niet, ook hebben ze geen verantwoordelijkheden die met elkaar conflicteren. Zoals programmeurs met GIT/SVN weten ontstaan conflicten pas als zaken elkaar overlappen . Het kan uiteraard wel het proces verstoren vanwege de tijd (heel de sprint vol programmeren en op het laatst snel de volgorde van de issues bepalen), maar dat is een ander verhaal.

[ Voor 5% gewijzigd door BarôZZa op 01-03-2016 02:24 ]

[Hydra]

Croga schreef op maandag 29 februari 2016 @ 18:30:
[...]

Zo werkt het niet. Als de PO ook de Lead Dev is, zal er bijvoorbeeld bij schattingen altijd naar hem gekeken worden. Aangezien zijn belang is dat er lage schattingen zijn zullen er lage schattingen zijn.

Tja. Als je ter plekke van dit soort dingen gaat verzinnen en/of in disfunctionele teams hebt gezeten kan ik me voorstellen dat je een ordnung must sein instelling hebt. Ik heb nog nooit meegemaakt in een scrum team, dev-als-PO of niet, dat mensen gingen pushen om je inschatting bij te stellen. Maargoed; ik zit dan ook al een tijdje in 't vak dus misschien is dat iets wat meer bij meer junior devs gebeurt (hoewel mijn ervaring is dat die stelselmatig de doorlooptijd onderschatten).

Hoe dan ook vind ik dat hier vanuit een soort worst-case scenario geredeneerd wordt en actief gezocht wordt naar redenen waarom het niet werkt. Ik vind dat nogal een pessimistische instelling. Je kunt het ook gewoon als team proberen en als blijkt dat het niet werkt breng je dat naar voren in de retro en fix je het. Als dat "niet mogelijk" is heb je een groter probleem denk ik zo.

[Croga]

Hydra schreef op dinsdag 01 maart 2016 @ 07:56:
Tja. Als je ter plekke van dit soort dingen gaat verzinnen en/of in disfunctionele teams hebt gezeten kan ik me voorstellen dat je een ordnung must sein instelling hebt. Ik heb nog nooit meegemaakt in een scrum team, dev-als-PO of niet, dat mensen gingen pushen om je inschatting bij te stellen. Maargoed; ik zit dan ook al een tijdje in 't vak dus misschien is dat iets wat meer bij meer junior devs gebeurt (hoewel mijn ervaring is dat die stelselmatig de doorlooptijd onderschatten).

Er hoeft ook niemand te pushen. Als er al gesproken wordt over een Lead Dev dan betekend dat dat die persoon een bepaald aanzien geniet in het team en zijn mening standaard als meer waardevol gezien wordt dan die van de rest. De zogenaamde HIPPO (Highest Payed Persons Opinion). Als die persoon ook meteen PO is dan is dat zeker een probleem. Dat gaat niet over dingen verzinnen dat gaat over het toepassen van wetenschap.

Overigens is het concept "doorlooptijd onderschatten" natuurlijk een non-issue als je praat over welke Agile methode dan ook......

[mbarie]

In een kleine organisatie kan je het denk ik nog verantwoorden, het is niet ideaal, maar financieel is het op die manier te behappen. In een grote organisatie lijkt het me dat een PO sowieso een zelfstandige functie waard is. Het beheren van een backlog, managen van verwachtingen van stakeholders en het in kaart brengen van de wensen van stakeholders is wat mij betreft een taak die men niet dient te onderschatten.

Als je van mening bent dat de persoon in kwestie capabel genoeg is om zich niet te laten leiden door druk van stakeholders dan kan het best werken. Een PO met goede technische kennis zou dermate goed moeten kunnen prioriteren omdat hij over vergaande kennis beschikt van zowel de business als de businesslogica op applicatieniveau. Als ik zie wat hier soms tussen neus een lippen door gepoogd wordt mee te nemen in een sprint ben ik blij dat die rollen hier gescheiden zijn en dat ieder daarin zijn eigen belangen behartigd. De rol van devteam, PO en SM vullen elkaar goed aan en houden elkaar scherp.

[Hydra]

Croga schreef op dinsdag 01 maart 2016 @ 08:30:
Er hoeft ook niemand te pushen. Als er al gesproken wordt over een Lead Dev dan betekend dat dat die persoon een bepaald aanzien geniet in het team en zijn mening standaard als meer waardevol gezien wordt dan die van de rest.

Als dat het geval is, heb je sowieso een probleem.

De zogenaamde HIPPO (Highest Payed Persons Opinion). Als die persoon ook meteen PO is dan is dat zeker een probleem. Dat gaat niet over dingen verzinnen dat gaat over het toepassen van wetenschap.

Je hebt het over disfunctionele teams. Als door een tech lead niet naar de rest geluisterd wordt heb je een HELE HELE slechte tech lead.

Overigens is het concept "doorlooptijd onderschatten" natuurlijk een non-issue als je praat over welke Agile methode dan ook......

Want?

[Croga]

Hydra schreef op dinsdag 01 maart 2016 @ 11:13:
Als dat het geval is, heb je sowieso een probleem.

Je hebt het over disfunctionele teams. Als door een tech lead niet naar de rest geluisterd wordt heb je een HELE HELE slechte tech lead.

Nee, je hebt het over natuurlijk gedrag wat in de menselijke geest vast gepint zit. ALS er überhaupt iemand is met de titel "Lead Dev" DAN is er bij definitie een alpha en dus volggedrag.

Again; slechts 5% wordt bepaald door de persoon, zijn persoonlijkheid, wie hij is en hoe hij acteert.
80% wordt bepaald door het systeem.
Als het systeem zegt dat er een Lead Dev is, dan kun je voor 80% voorspellen wat er gaat gebeuren.

Ik ben het volledig met je eens dat dit een onwenselijke situatie is. Het concept Lead Dev zou niet mogen bestaan. Een team wat een "champion" heeft zal altijd slechter presteren dan een team van middelmatige mensen. Maar we spraken hier over een praktijk situatie. Deze praktijk situatie stelt dat er een Lead Dev is en dat gaat gevolgen hebben voor het hele verhaal hier.

Want?

Doorlooptijd wordt niet meer ingeschat. Je schat totale complexiteit in. En als er dus iemand is die dit structureel onderschat dan wordt dan automatisch onderdeel van je velocity, probleem opgelost.

[pedorus]

Croga schreef op dinsdag 01 maart 2016 @ 11:26:
Een team wat een "champion" heeft zal altijd slechter presteren dan een team van middelmatige mensen.

Komt deze claim ergens vandaan? Champion lijkt me in ieder geval niet het goede woord dan. Doet denken aan

quote: https://www.researchgate....f28a408ae199d47c00015.pdf

A well established finding in the innovation literature is that the presence of champions is positively related to product innovation succes

Om even weg te komen van definitiekwesties enzo een opiniestukje + discussie:
Implementing Scrum: How Does the Project Manager Fit In?

Het gaat erover dat rollen eventueel gecombineerd kunnen worden, en hoe deze het beste kunnen worden ingevuld hangt sterk af van de personen in kwestie. Desnoods kan het voorkomen dat iemand 3 rollen krijgt.

[ Voor 6% gewijzigd door pedorus op 02-03-2016 23:51 ]

[Laurens-R]

Ps... Ik vind een lead/champion rol wel prettig. Misschien dat het theoretisch niet wenselijk is, maar de praktijk wijst vaak uit dat er een aantal onervaren teamleden bij zitten waarvan de code best wat senior review kan gebruiken. Tuurlijk; we doen scrum en dat soort zaken kan je oppakken in de volgende sprint, maar in de real world word de klant toch echt geïrriteerd als dat voorbij bepaalde aantallen schiet. Dan zou ik maar wat blij zijn met een ervaren lead die de ergste zaken op voorhand er uit kan halen. Ik houd juist van een divers team, zowel onervaren als ervaren... Lead en geen lead. Een goede lead die scrum snapt is in mijn ervaring zich vaak ook goed bewust van zijn rol/plek. En misschien ligt dat aan m'n werkgever maar het zijn bij ons allemaal echte team players en geen loslopende ego'tjes.

[ Voor 4% gewijzigd door Laurens-R op 03-03-2016 01:08 ]

[Croga]

pedorus schreef op woensdag 02 maart 2016 @ 23:51:
Komt deze claim ergens vandaan? Champion lijkt me in ieder geval niet het goede woord dan. Doet denken aan

Er zit inderdaad een definitie verschil in. Wat er in die paper als "Champion" benoemd wordt zou in Scrum de Product Owner zijn; degene die het product draagt en uitdraagt. Wat ik bedoel is dat het mis gaat zodra er 1 persoon in het team gezien wordt als "de Guru". Innovatie wordt doodgeslagen in dat geval aangezien er nog maar 1 mening gebruikt wordt in plaats van de mening van het volledige team.

Laurens-R schreef op donderdag 03 maart 2016 @ 01:05:
Ps... Ik vind een lead/champion rol wel prettig. Misschien dat het theoretisch niet wenselijk is, maar de praktijk wijst vaak uit dat er een aantal onervaren teamleden bij zitten waarvan de code best wat senior review kan gebruiken. Tuurlijk; we doen scrum en dat soort zaken kan je oppakken in de volgende sprint, maar in de real world word de klant toch echt geïrriteerd als dat voorbij bepaalde aantallen schiet.

Welke dingen worden opgepakt in de volgende sprint? Als review nodig is, is dat onderdeel van de Definition of Done en gebeurt het dus. Als er zaken de sprint uit rollen waar de klant geïrriteerd van wordt ben je geen scrum aan het doen..... Daar heb je geen lead voor nodig, dat is gewoon standaard scrum.

Dan zou ik maar wat blij zijn met een ervaren lead die de ergste zaken op voorhand er uit kan halen. Ik houd juist van een divers team, zowel onervaren als ervaren... Lead en geen lead. Een goede lead die scrum snapt is in mijn ervaring zich vaak ook goed bewust van zijn rol/plek. En misschien ligt dat aan m'n werkgever maar het zijn bij ons allemaal echte team players en geen loslopende ego'tjes.

Ik ben het volledig met je eens dat de mix van ervaren en onervaren enorm nuttig is (ik heb een team gehad waarbij een schoolverlater gekoppeld werd aan iemand met 25 jaar ervaring; nog nooit zo'n productief team gezien! Perfecte combo van "Dit ding heb ik al 1000 keer gebouwd dus dat schud ik in 3 minuten uit m'n mouw" en "Hey, is er niet een nieuwe library die zorgt dat we dit in 2 minuten kunnen doen?").
Het probleem zit voor een deel inderdaad in egos en die moeten door het team buitengezet worden. Maar voor een deel zit het ook in titels. Zodra iemand een titel aangewezen krijgt die hiërarchie impliceerd krijg je het HIPPO effect. En dat is de killer.

[Tarkin]

Even een oud topic uit de sloot halen aangezien ik dit wel een interessant topic vind

Croga schreef op donderdag 3 maart 2016 @ 05:24:
[...]

Er zit inderdaad een definitie verschil in. Wat er in die paper als "Champion" benoemd wordt zou in Scrum de Product Owner zijn; degene die het product draagt en uitdraagt. Wat ik bedoel is dat het mis gaat zodra er 1 persoon in het team gezien wordt als "de Guru". Innovatie wordt doodgeslagen in dat geval aangezien er nog maar 1 mening gebruikt wordt in plaats van de mening van het volledige team.

Waarom zou je een developer PO maken? Beslist de developer (of het development team) wat de belangrijkste nieuwe features zijn voor de klant? Hakt hij de zware knopen door wat eerst moet gebeuren (en wat er misschien wegmoet?)

Dit is geen taak voor het scrum team, maar voor de "klant". Dit kan een andere interne dienst zijn waarvoor je software schrijft of echt een externe klant. Zij betalen, dus zij bepalen ook welke features ze willen.

van zodra de backlog gepriotiseerd is, kan je (adhv velocity) bepalen wat je wel en niet kan doen in de Sprint.


Verder wordt het wel meer gedaan om een analistenrol te combineren met scrummaster of een developer die 50/50 scrummaster is. Een PO die developer is ben ik nog niet tegengekomen (en wordt overal afgeraden, ook in de literatuur hierover). Het zijn 2 uiteenlopende petten die je niet snel op hetzelfde hoofd zult zien.

[Croga]

Tarkin schreef op donderdag 22 juni 2017 @ 14:22:
Even een oud topic uit de sloot halen aangezien ik dit wel een interessant topic vind
Waarom zou je een developer PO maken? Beslist de developer (of het development team) wat de belangrijkste nieuwe features zijn voor de klant? Hakt hij de zware knopen door wat eerst moet gebeuren (en wat er misschien wegmoet?)

Dit is geen taak voor het scrum team, maar voor de "klant". Dit kan een andere interne dienst zijn waarvoor je software schrijft of echt een externe klant. Zij betalen, dus zij bepalen ook welke features ze willen.

Eerst zeg je dat PO een taak voor de klant is, dan zeg je dat het geen taak voor het Scrum team is. Het Scrum team bestaat echter, per definitie, uit developers, een Scrum Master en.... jawel... De Product Owner. (http://www.scrumguides.org/scrum-guide.html#team)

Het concept "de business" is een artificieel artefact wat geen plaats heeft in Agile. We stellen dat iedereen die verantwoordelijkheid over het product draagt dagelijks met elkaar samen werkt. Of dat nu "de business" of "IT" is. Het is één team. Mijn ervaring met "business" POs zijn in ieder geval een stuk slechter dan met POs die dichter bij het team staan, qua organisatie. Die laatste categorie kan over het algemeen makkelijker en meer tijd vrij maken om het team te ondersteunen dan die eerste.


Overigens heb ik ook al eerder in deze thread gesteld dat:
- De PO nooit een developer moet zijn.
- Het idee dat de PO uit de business moet komen niet zo zwart/wit is.


Waar ik met mijn referentie naar Guru op doelde was dat als het Development team één "Guru" heeft, de innovatie in de implementatie beperkt wordt. Dat staat dus los van de Product Owner. Er werd een stuk gequote wat zegt dat het succes van een product afhankelijk is van één persoon die als kampioen optreedt en dat werd gerelateerd aan een Senior Developer; dat stuk heb ik tegen gesproken.


Ook het concept "Zij betalen dus zij bepalen" is niet evident. Degenen die betalen hebben over het algemeen geen flauw benul van wat iets kost of wat iets oplevert. Degenen die betalen moeten het vertrouwen hebben dat het team datgene bouwt wat de hoogste waarde oplevert op lange termijn. Is dat vertrouwen er niet dan is het niet slim om überhaupt over Agile na te denken.

van zodra de backlog gepriotiseerd is, kan je (adhv velocity) bepalen wat je wel en niet kan doen in de Sprint.

Je velocity bepaalt niet wat je kunt doen in een sprint. Je inzicht in hoeveel werk een taak is bepaald dat. Velocity is slechts een handige sanity check daar op. Het gebruik van Velocity als enige planning middel is een goed begin. Laten we zeggen "level 1 scrum" Maar het beperkt de noodzaak van inzicht in het werk. Vandaar dat Sprint Planning bestaat uit twee delen waar we in het tweede deel het werk ontleden en kijken aan de hand van die ontleding of het realistisch is om dat werk inderdaad in één sprint te doen, onafhankelijk van velocity. Je nauwkeurigheid in sprint planning gaat exponentieel omhoog wanneer je velocity als planningstool laat vallen.
(een mooie beschrijving van dit concept is te vinden in de NoEstimates beweging: http://ronjeffries.com/xp...the-noestimates-movement/)

Verder wordt het wel meer gedaan om een analistenrol te combineren met scrummaster of een developer die 50/50 scrummaster is.

Overigens is ook SM en Dev combineren een patent slecht idee. Er ligt één grote impediment en één groot stuk programmeer werk. Een SM/Dev pakt dat stuk programmeer werk op, leert de praktijk. Dat is nú mischien een goed idee maar zorgt op de lange termijn voor minder verbetering in de manier van werken.

Ik heb nog *nergens* een succesvolle combinatie gezien van welke van de drie rollen dan ook. Het zijn afzonderlijke rollen met een afzonderlijk doel die haaks op elkaar staan. En nee, mensen zijn niet in staat om het hogere doel te zien, niet in crunch-time.

Een PO die developer is ben ik nog niet tegengekomen (en wordt overal afgeraden, ook in de literatuur hierover). Het zijn 2 uiteenlopende petten die je niet snel op hetzelfde hoofd zult zien.

Precies wat ik al een aantal keer in deze thread gezegd heb. 3 rollen, niet combineren want dat leidt tot conflicten voor die persoon.

[Tarkin]

Croga schreef op donderdag 22 juni 2017 @ 14:50:

Eerst zeg je dat PO een taak voor de klant is, dan zeg je dat het geen taak voor het Scrum team is. Het Scrum team bestaat echter, per definitie, uit developers, een Scrum Master en.... jawel... De Product Owner. (http://www.scrumguides.org/scrum-guide.html#team)

Het concept "de business" is een artificieel artefact wat geen plaats heeft in Agile. We stellen dat iedereen die verantwoordelijkheid over het product draagt dagelijks met elkaar samen werkt. Of dat nu "de business" of "IT" is. Het is één team. Mijn ervaring met "business" POs zijn in ieder geval een stuk slechter dan met POs die dichter bij het team staan, qua organisatie. Die laatste categorie kan over het algemeen makkelijker en meer tijd vrij maken om het team te ondersteunen dan die eerste.

True dat het in de guide staat. Het is een puntje waar ik het niet echt eens ben met de scrum guide . Een PO kan je op niveau van het team bezien maar dan zit je altijd met (at best) half time rollen. je gaat niemand hebben die 100% van zijn tijd besteedt aan PO taken voor 1 team. Daarom heb ik het altijd zinvoller gevonden om 1PO te hebben voor meerdere teams. Daardoor wordt dit wel een full time taak en is het gemakkelijker af te zonderen voor 1 persoon. Dit is ook de weg die we hier opgaan dmv LeSS (large scale scrum).

verder moet je business in mijn contect zien als de "customer". Kan interne business zijn, kan een echte klant zijn.

Ik heb ook al met interne PO's gewerkt. Heb er goede gezien, heb er heel slechte gezien ("alle issues gaan we qua points halveren, want anders willen ze er niet voor betalen!!!). Heb momenteel een PO vanuit business en die doet dat goed. Het is niet zo zwart wit op dat vlak dus

Waar ik met mijn referentie naar Guru op doelde was dat als het Development team één "Guru" heeft, de innovatie in de implementatie beperkt wordt. Dat staat dus los van de Product Owner. Er werd een stuk gequote wat zegt dat het succes van een product afhankelijk is van één persoon die als kampioen optreedt en dat werd gerelateerd aan een Senior Developer; dat stuk heb ik tegen gesproken.

Deel ik je mening volledig in. Guru's kunnen nuttig zijn, maar zijn vooral bus factor 1 en niet wenselijk in een agile/scrum organisatie. Kennis moet zoveel mogelijk verspreidt zijn (niet dat ik tegen specialisten ben, maar ze moeten ook nog andere zaken kunnen)

Ook het concept "Zij betalen dus zij bepalen" is niet evident. Degenen die betalen hebben over het algemeen geen flauw benul van wat iets kost of wat iets oplevert. Degenen die betalen moeten het vertrouwen hebben dat het team datgene bouwt wat de hoogste waarde oplevert op lange termijn. Is dat vertrouwen er niet dan is het niet slim om überhaupt over Agile na te denken.

Daarom dat je een backlog hebt met high level inschattingen. Op basis daarvan kunnen ze wel bepalen of ze feature a tegen (geschatte) kost x wel of niet zien zitten.

Je velocity bepaalt niet wat je kunt doen in een sprint. Je inzicht in hoeveel werk een taak is bepaald dat. Velocity is slechts een handige sanity check daar op. Het gebruik van Velocity als enige planning middel is een goed begin. Laten we zeggen "level 1 scrum" Maar het beperkt de noodzaak van inzicht in het werk.

A.d.h.v. je historische velocity heb je een goede leidraad hoeveel storypoints je kan opleveren tijdens je sprint. Als je de afgelopen 5 sprints niet meer dan 20 storypoints hebt opgeleverd (bij gelijke bezetting en gelijk aantal dagen) dan kan je in sprint 6 niet ineens 40 storypoints opnemen.
Daarbij is het niet het enige planningmiddel

Vandaar dat Sprint Planning bestaat uit twee delen waar we in het tweede deel het werk ontleden en kijken aan de hand van die ontleding of het realistisch is om dat werk inderdaad in één sprint te doen, onafhankelijk van velocity. Je nauwkeurigheid in sprint planning gaat exponentieel omhoog wanneer je velocity als planningstool laat vallen.
(een mooie beschrijving van dit concept is te vinden in de NoEstimates beweging: http://ronjeffries.com/xp...the-noestimates-movement/)

Het inschatten in storyponts (= complexiteit) inschatten heeft niets te maken met je velocity. Normaal gezien heb je dat voor je sprintplanning al gedaan in een backlog grooming. Tijdens de sprintplanning is het dan heel eenvoudig. Je hebt bv 20punten en de top x backlog items zijn 5-8-2-8-5. Je kan dan beslissen om story 1; 2, 3 en 5 te doen (en zo aan je 20 punten te komen) of om story 4 toch op te splitsen zodat je hem wel kan meenmen (iets wat niet zoveel gebeurt).

Overigens is ook SM en Dev combineren een patent slecht idee. Er ligt één grote impediment en één groot stuk programmeer werk. Een SM/Dev pakt dat stuk programmeer werk op, leert de praktijk. Dat is nú mischien een goed idee maar zorgt op de lange termijn voor minder verbetering in de manier van werken.

Ik heb nog *nergens* een succesvolle combinatie gezien van welke van de drie rollen dan ook. Het zijn afzonderlijke rollen met een afzonderlijk doel die haaks op elkaar staan. En nee, mensen zijn niet in staat om het hogere doel te zien, niet in crunch-time.

Precies wat ik al een aantal keer in deze thread gezegd heb. 3 rollen, niet combineren want dat leidt tot conflicten voor die persoon.

En ik heb nog nergens anders gewerkt dan dat de SM rol een parttime rol was, en die dus altijd gecombineerd is geweest met ofwel een analistenjob ofwel een developent job . In je voorbeeld ga je ervanuit dat de SM altijd de laatste grote stukken programmeerwerk op zich neemt. is niet altijd waar.

De reden waarom een SM dan niet standaard 2 teams op zich neemt? Meestal overlappen de standups en andere meetings van de teams. Een SM kan zich niet opsplitsen in 2.

Ik deel wel de mening dat het een risico is. Maar zolang het team zich hiervan bewust is is er geen probleem m.i. Mocht het wel een probleem worden dan wordt er wel bijgestuurd op de retro.

[Croga]

Tarkin schreef op donderdag 22 juni 2017 @ 15:15:
True dat het in de guide staat. Het is een puntje waar ik het niet echt eens ben met de scrum guide . Een PO kan je op niveau van het team bezien maar dan zit je altijd met (at best) half time rollen. je gaat niemand hebben die 100% van zijn tijd besteedt aan PO taken voor 1 team. Daarom heb ik het altijd zinvoller gevonden om 1PO te hebben voor meerdere teams. Daardoor wordt dit wel een full time taak en is het gemakkelijker af te zonderen voor 1 persoon. Dit is ook de weg die we hier opgaan dmv LeSS (large scale scrum).

Waar heb je mij horen zeggen, of waar zegt de Scrum Guide, dat de PO niet PO kan zijn voor meerdere teams?

En wat LeSS betreft; je weet wat Craig Larman (één van de twee uitvinder van LeSS) zegt over LeSS?
De eerste woorden in iedere presentatie die hij geeft zijn steevast:
"Want to do Scrum at scale? Don't. Ever. Never ever do Scrum with multiple teams. It's bad. Just don't do it. But if you have to......"
Ook Larmann en Vodde zeggen dat één PO helpt één team en doet niets anders dan dat team helpen. Maar als het echt niet anders kan.......

Ik heb ook al met interne PO's gewerkt. Heb er goede gezien, heb er heel slechte gezien ("alle issues gaan we qua points halveren, want anders willen ze er niet voor betalen!!!). Heb momenteel een PO vanuit business en die doet dat goed. Het is niet zo zwart wit op dat vlak dus

POs die dat soort dingen zeggen werken in een systeem wat een probleem veroorzaakt. Pak het systeem aan, niet de PO. Je hebt hier niet te maken met een slechte PO, je hebt te maken met een bedrijf wat helemaal niet snapt hoe Agile werkt.
(overigens geeft dit ook aan dat er een prijs per story point afgesproken is; als je een team én een product kapot wilt maken dan is dát de beste manier)

Daarom dat je een backlog hebt met high level inschattingen. Op basis daarvan kunnen ze wel bepalen of ze feature a tegen (geschatte) kost x wel of niet zien zitten.

Dat zegt nogsteeds niet of de feature het waard is of niet.......

Het inschatten in storyponts (= complexiteit) inschatten heeft niets te maken met je velocity. Normaal gezien heb je dat voor je sprintplanning al gedaan in een backlog grooming. Tijdens de sprintplanning is het dan heel eenvoudig. Je hebt bv 20punten en de top x backlog items zijn 5-8-2-8-5. Je kan dan beslissen om story 1; 2, 3 en 5 te doen (en zo aan je 20 punten te komen) of om story 4 toch op te splitsen zodat je hem wel kan meenmen (iets wat niet zoveel gebeurt).

Waar het mis gaat is dat teamleden niet gelijk zijn. Het getalletje zegt dus helemaal niets over hoe lang degene die het gaat oppakken er mee bezig is. Dat betekend dus dat als je lukraak de bovenste 20 punten van de backlog pakt, er een kans is dat dat allemaal in het specialisme van één persoon valt waardoor je alsnog het niet gaat halen.
Daarnaast zorgt het er voor dat het team niet hard genoeg nadenkt over wat ze nou eigenlijk moeten doen in de sprint. Vandaar ook dat Sprint Planning 2 is toegevoegd aan de guide; waar het team het werk voor de komende sprint helemaal uit pluist en serieus kijkt naar wat er nou eigenlijk gedaan moet worden. Dáár wordt commitment op gegeven (oh, wacht, dat woord mag niet meer gebruikt worden..... Forecast heet dat tegenwoordig) want daarvan weten we dat de kans groot is dat het haalbaar is.

En ik ben het met je eens; velocity is een manier om te schatten en als je een heel volwassen team hebt dan is dat ook genoeg. Maar die teams ben ik nog niet tegen gekomen in 10 jaar Scrum. En een team wat zo volwassen is zou ik heel sterk aanraden naar #NoEstimates te kijken, scheelt je een hele berg boekhouding.

En ik heb nog nergens anders gewerkt dan dat de SM rol een parttime rol was, en die dus altijd gecombineerd is geweest met ofwel een analistenjob ofwel een developent job . In je voorbeeld ga je ervanuit dat de SM altijd de laatste grote stukken programmeerwerk op zich neemt. is niet altijd waar.

Ur? Waar heb ik "altijd" gezegd? Ik heb gezegd dat het gaat gebeuren. En dat is een feit. De situatie waar een SM/Dev moet kiezen tussen zijn twee rollen gaat gebeuren en de Mens is nou eenmaal niet in staat om dan voor de lange termijn te kiezen.

De reden waarom een SM dan niet standaard 2 teams op zich neemt? Meestal overlappen de standups en andere meetings van de teams. Een SM kan zich niet opsplitsen in 2.

Waarom zouden de standups overlappen? En waarom zou dat niet heel eenvoudig aan te passen zijn? Het is maar 15 minuten op een dag hoor.
Daarnaast; sinds wanneer moet een Scrum Master bij de standup aanwezig zijn? De standup is bedoelt om het werk te plannen; werk waar de Scrum Master geen rol in heeft. De Scrum guide zegt dit ook letterlijk; de Daily Standup is voor het Development Team. Het Development Team bestaat uit alle leden van het Scrum team die het product daadwerkelijk ontwikkelen.
Daarnaast is dat juist wél weer iets wat economy of size oplevert; impediments komen bijna nooit voor maar één team....

Overigens zie je mij ook nergens zeggen dat een SM twee teams op zich zou moeten nemen. Bij de meeste teams is SM gewoon een volledige dagtaak. Er zijn altijd meer impediments op te ruimen!