Overstap van software engineer naar project manager

[Anoniem: 832815]

Binnenkort ga ik aan de slag als project manager na jarenlang (20+) als software engineer / architect werkzaam te zijn geweest. Ik krijg dus allerlei 'nieuwe' taken en verantwoordelijkheden en wil me daar uiteraard goed op voorbereiden. Nu ben ik op zoek naar geschikte boeken (of wellicht udemy / pluralsight video cursussen) die geschikt zijn als 'basis / introductie' voor deze nieuwe functie. Wat zijn echte aanraders?

Verder ben ik ook wel erg benieuwd naar de ervaringen van anderen die deze 'stap' ook gemaakt hebben; viel het mee / tegen, was het wat je er van verwacht had, ben je weer gillend teruggegaan naar het reguliere ontwikkelwerk?

[Bastiaan]

Ik sta ook op het punt de stap naar projectmanagement te maken. Daar zitten ook ongetwijfeld dingen voor mij bij waarin ik niet of beperkt eerder te maken mee heb gehad, maar ik ben aangenomen om mijn kennis, kunde, persoonlijkheid en ervaringen tot nu toe. Ook heb ik me voor de sollicitatie ook zo goed mogelijk ingelezen en gevraagd wat van mij verwacht wordt. Waar het dus om gaat: met dat totaalplaatje aan informatie heb ik gesolliciteerd, ben ik aangenomen en kunnen zowel mijn nieuwe werkgever als ikzelf verder ontwikkelen.

Nu is het natuurlijk zo dat geen achtergrond hetzelfde is en juich ik je die voorbereiding die je wilt doen toe, maar verlies niet uit het oog dat ook jij bent aangenomen van jouw ervaringen tot op het moment van je nieuwe contractondertekening. Je komt nu op me over als graag willen en er daardoor enthousiast doch hard van stapel gaat, maar bereid je wel voor op de goede dingen in plaats van de (lijkend) lukrake cursussen en boeken. Vraag bijvoorbeeld documentatie of traingen van je nieuwe bedrijf waarop je je vast kunt inlezen; dat lijkt me een stuk zinvoller en een betere voorbereiding dan dat kun je op moment niet hebben.

Los van dat alles: heel veel succes!

[Anoniem: 832815]

Bastiaan schreef op woensdag 28 februari 2018 @ 15:28:
Ik sta ook op het punt de stap naar projectmanagement te maken. Daar zitten ook ongetwijfeld dingen voor mij bij waarin ik niet of beperkt eerder te maken mee heb gehad, maar ik ben aangenomen om mijn kennis, kunde, persoonlijkheid en ervaringen tot nu toe. Ook heb ik me voor de sollicitatie ook zo goed mogelijk ingelezen en gevraagd wat van mij verwacht wordt. Waar het dus om gaat: met dat totaalplaatje aan informatie heb ik gesolliciteerd, ben ik aangenomen en kunnen zowel mijn nieuwe werkgever als ikzelf verder ontwikkelen.

Nu is het natuurlijk zo dat geen achtergrond hetzelfde is en juich ik je die voorbereiding die je wilt doen toe, maar verlies niet uit het oog dat ook jij bent aangenomen van jouw ervaringen tot op het moment van je nieuwe contractondertekening. Je komt nu op me over als graag willen en er daardoor enthousiast doch hard van stapel gaat, maar bereid je wel voor op de goede dingen in plaats van de (lijkend) lukrake cursussen en boeken. Vraag bijvoorbeeld documentatie of traingen van je nieuwe bedrijf waarop je je vast kunt inlezen; dat lijkt me een stuk zinvoller en een betere voorbereiding dan dat kun je op moment niet hebben.

Los van dat alles: heel veel succes!

Dank voor je reactie! Uiteraard ga ik niet 'lukraak' allerlei informatie tot mij nemen maar wil ik gewoon kennis nemen van de 'basis' en ben ik op zoek naar goede bronnen hiervoor. Daarnaast had ik misschien iets duidelijker moeten maken dat het me dan niet om het proces 'in theorie' gaat maar wat is nu de praktijk; wat zijn veelvoorkomende valkuilen waar nagenoeg iedere (beginnende) project manager in trapt, hoe te handelen in bepaalde situaties (b.v. een projectmedewerker die er met de pet naar gooit (of lijkt te gooien)).

Hopelijk komen er nog reacties van mensen die ook eenzelfde stap gemaakt hebben; ben erg benieuwd naar hun ervaringen...

[Anoniem: 224360]

Mijn ervaring met project management is er een waar de werkgever dusdanig slecht met het vakgebied omging dat zelfs ervaren project managers niet uit de verf kwamen. Laat staan junior mensen of beginnelingen in het vak. Oftewel zelfs als jij straks heel goed blijkt te zijn, je bent ook enorm afhankelijk van de organisatie en bijbehorende inrichting.

[wm1234]

Het ligt eraan wat je gaat managen maar basis opleidingen die niet moeten ontbreken zijn toch wel Prince2 foundations en ITIL foundations. In die hoek heb je nog veel meer opleidingen (IMPA, Governance etc.).

Verder vooral niet als een techneut overal mee bemoeien maar de techneuten zelf met oplossingen / voorstellen laten komen. Maar vervolgens wel goed op de cijfertjes en structuur blijven letten (urenschattingen & administratie).

Als je nog geen achtergrond in de business hebt, zou ik daar ook nog kennis in vergaren (gesprekstechnieken, onderhandelen, finance, business structuren, klantwensen etc.). maar ik mag hopen dat je als architect op strategisch niveau die kennis wel hebt.

Ik acteer als ontwikkelaar en projectmanagement op een groot project. Het zijn toch wel twee hele aparte takken van sport met verschillende type soort mensen. Technische mensen zie je eigenlijk niet zo vaak in het projectmanagement en visa versa. Het moet je dus wel liggen. Technische mensen willen vaak niet de hele dag met 'management geneuzel en administratie bezig zijn' en vooral lekker dingen maken. Projectmanagers vinden de hele dag in de techniek weer niets en willen graag met mensen bezig zijn / doelen bereiken. Als je een brug kan vormen tussen die twee werelden en alles in begrijpbare mensen taal kan uitleggen plus binnen budget en doelstelling blijven, dan kan het niet anders dan een succes worden.

[ Voor 34% gewijzigd door wm1234 op 01-03-2018 00:12 ]

[pirke]

Ik heb de stap ook ooit gemaakt, daarna weer teruggegaan, voornamelijk omdat ik het excelsheet management wat in dat bedrijf de norm was echt helemaal niks vond. Ook het constante getouwtrek over resources (ook wel warme lijven genoemd), planningen, deadlines, etc was ik vrij snel beu, maar ja, elk kwartaal begon het feestje weer van voor af aan. En ik trapte constant in de (voor mij) belangrijkste valkuil: ik wilde me nog steeds inhoudelijk met de zaken bemoeien, moet je niet doen.

Een latere combinatierol management+architectuur lag me beter, zelf aan het stuur blijven en het grote plaatje bewaken, zowel inhoudelijk als niet inhoudelijk. Wel uitkijken dat je dan geen dictator wordt omdat je op elk vlak beslissingsbevoegd bent

[Widow]

Misschien is de topicstart een beetje kort, maar ik begrijp het niet helemaal

Als je 20 jaar in het vak zit, en als software engineer / architect hebt gewerkt, hoe kan het dan zijn dat je op zoek bent naar de basics van projectmanagement? Ik bedoel, heb je die mensen nooit aan het werk gezien, of gevraagd hoe ze bezig waren met projectmanagement? Of waar ze tegenaan liepen?

[Douwe63]

Oeps, verkeerde account

[ Voor 98% gewijzigd door Douwe63 op 02-03-2018 18:40 ]

[Anoniem: 832815]

wm1234 schreef op donderdag 1 maart 2018 @ 00:08:
Het ligt eraan wat je gaat managen maar basis opleidingen die niet moeten ontbreken zijn toch wel Prince2 foundations en ITIL foundations. In die hoek heb je nog veel meer opleidingen (IMPA, Governance etc.).

Verder vooral niet als een techneut overal mee bemoeien maar de techneuten zelf met oplossingen / voorstellen laten komen. Maar vervolgens wel goed op de cijfertjes en structuur blijven letten (urenschattingen & administratie).

Als je nog geen achtergrond in de business hebt, zou ik daar ook nog kennis in vergaren (gesprekstechnieken, onderhandelen, finance, business structuren, klantwensen etc.). maar ik mag hopen dat je als architect op strategisch niveau die kennis wel hebt.

Ik acteer als ontwikkelaar en projectmanagement op een groot project. Het zijn toch wel twee hele aparte takken van sport met verschillende type soort mensen. Technische mensen zie je eigenlijk niet zo vaak in het projectmanagement en visa versa. Het moet je dus wel liggen. Technische mensen willen vaak niet de hele dag met 'management geneuzel en administratie bezig zijn' en vooral lekker dingen maken. Projectmanagers vinden de hele dag in de techniek weer niets en willen graag met mensen bezig zijn / doelen bereiken. Als je een brug kan vormen tussen die twee werelden en alles in begrijpbare mensen taal kan uitleggen plus binnen budget en doelstelling blijven, dan kan het niet anders dan een succes worden.

Dank voor je uitgebreide antwoord! Ik ga werken bij een bedrijf dat zich voornamelijk richt op het ontwikkelen van apps en websites. Mijn taken worden het communiceren met klanten, het verzamelen en uitwerken van de requirements, planning, administratie en het aansturen van de ontwikkelteams.

Goede tip van die Prince2 en ITIL foundations trouwens, dat is inderdaad wel iets om mee te beginnen (om eerlijk te zijn kende ik die termen van heeeel lang geleden maar ze zijn blijkbaar nog steeds relevant).

Ik ben van oorsprong wel een echte techneut (dus ik moet uitkijken voor die valkuil om me overal mee te bemoeien) maar merkte dat ik daar eigenlijk wel op uitgekeken was en 'verder' wilde. Nu kreeg ik een aanbod van dit bedrijf (puur op persoonlijkheid en technische achtergrond) om die stap daar te gaan maken en dan wil ik natuurlijk wel goed beslagen ten ijs komen, vandaar dit draadje.

[orf]

Wordt Princ2 en ITL nog gebruikt bij de ontwikkeling van websites en apps? Is dat niet allemaal over naar Scrum? Scrum is "easy to learn, difficult to master". Ik vind het een veel betere methode, omdat je met Prince2 een soort valse zekerheid hebt. Je plant het helemaal, werkt het uit en komt bij de ontwikkeling (of oplevering!) dat wat je bedacht had toch niet helemaal was hoe het werkt. Dan kun je changes door gaan voeren met eventueel meerwerk, maar je kunt beter een proces hebben dat er al vanuit gaat dat je niet kunt voorspellen hoe het loopt. Websites/Apps/Software ontwikkelen is een complex proces. Dat kun je niet van te voren uitdenken.

Als techneut kun je je kracht gebruiken: Je weet alles van de inhoud. Je kunt dus steeds inhoudelijk meekijken en voor jezelf bepalen waar het team staat. Ik wil zelf door de website heen kunnen klikken als er een sprint opgeleverd wordt. Ik wil zelf voelen hoe het werkt. Heb ik het idee dat het traag is, heb ik het idee dat de UX niet helemaal lekker is, etc.

Projecten managen is wat mij betreft veel meters maken. Je moet tegen bepaalde dingen aanlopen om er de volgende keer op voorbereid te zijn. Dat neem je dan vanzelf mee.

[Anoniem: 832815]

pirke schreef op donderdag 1 maart 2018 @ 01:17:
Ik heb de stap ook ooit gemaakt, daarna weer teruggegaan, voornamelijk omdat ik het excelsheet management wat in dat bedrijf de norm was echt helemaal niks vond. Ook het constante getouwtrek over resources (ook wel warme lijven genoemd), planningen, deadlines, etc was ik vrij snel beu, maar ja, elk kwartaal begon het feestje weer van voor af aan. En ik trapte constant in de (voor mij) belangrijkste valkuil: ik wilde me nog steeds inhoudelijk met de zaken bemoeien, moet je niet doen.

Een latere combinatierol management+architectuur lag me beter, zelf aan het stuur blijven en het grote plaatje bewaken, zowel inhoudelijk als niet inhoudelijk. Wel uitkijken dat je dan geen dictator wordt omdat je op elk vlak beslissingsbevoegd bent

Dat grote plaatje (management + globale architectuur) is inderdaad precies de bedoeling. Net zoals wm1234 al aangaf zijn de typische 'ontwikkelaars' heel anders dan de typische 'project managers' en blijkbaar is het lastig om een project manager te vinden die ook het gewenste technisch inhoudelijk niveau heeft om goed met de engineers te kunnen communiceren en begrijpt wat er allemaal komt kijken bij software ontwikkeling.

Dank voor je feedback trouwens!

[Anoniem: 832815]

Widow schreef op vrijdag 2 maart 2018 @ 09:37:
Misschien is de topicstart een beetje kort, maar ik begrijp het niet helemaal

Als je 20 jaar in het vak zit, en als software engineer / architect hebt gewerkt, hoe kan het dan zijn dat je op zoek bent naar de basics van projectmanagement? Ik bedoel, heb je die mensen nooit aan het werk gezien, of gevraagd hoe ze bezig waren met projectmanagement? Of waar ze tegenaan liepen?

Ik heb eigenlijk nooit gewerkt gewerkt in omgevingen waarin de opdrachtgever een enkele (externe klant) was.

De traditionele project leiders waar ik toen mee te maken had vervulden dus ook niet de rol die nu wel van mij verwacht gaat worden (buiten het feit dat we vaker last van ze hadden dan gemak dus ik heb wel enig gevoel van wat ik niet moet gaan doen ).

[wm1234]

Ik ben het wel eens dat Scrum in opkomst is (of varianten ervan). Ik heb zelf ook PSM1 van Scrum.org + van de bedenkers les gehad.

Je moet zelf kijken wat past in de organisatie.In grote logge organisaties is Scrum een enorme cultuuromslag + het werkt vaak slecht omdat er op verschillende niveau's moet worden besloten over budget en richting. De meeste managers willen hun eigen baantje beschermen. Als je in een kleinere onderneming werkt (en dat vermoed ik) omdat je zelf requirements helder gaat proberen te krijgen, werkt het misschien wel goed.

Kijk gewoon wat er het beste past en kijk wat werkt. Gezond boeren verstand en structureel werken is vaak de beste oplossing.

[Anoniem: 832815]

orf schreef op vrijdag 2 maart 2018 @ 18:50:
Wordt Princ2 en ITL nog gebruikt bij de ontwikkeling van websites en apps? Is dat niet allemaal over naar Scrum? Scrum is "easy to learn, difficult to master". Ik vind het een veel betere methode, omdat je met Prince2 een soort valse zekerheid hebt.

Volgens mij kun je Prince2 en Agile niet op die manier met elkaar vergelijken; Agile wordt gebruikt bij het ontwikkelen van de software en Prince2 is meer een project-management methode (communicatie met de klant, managen van resources, issues en risico's, planning, rapportage etc.).

[The Eagle]

Prince2 en scrum zijn beide manieren om projecten mee te managen. Verschil is dat prince veel meer waterval georienteerd is en scrum totaal niet (werkt met sprints, naja ga ik niet uitleggen).

Maar beiden zijn goed om te kennen en toe te kunnen passen, want lang niet ieder bedrijf is er al aan toe om agile te werken (vrijwel randvoorwaardelijk voor scrum). Dan leer je ook meteen dat beiden frameworks zijn die je naar eigen inzicht inzet. In prince2 ga je bijvoorbeeld in afwijking als je een projectfase niet af kunt ronden, met diverse documenten van dien. Leuk, maar dr is geen hond die naar dat soort documenten kraait. Project moet gewoon on time on budget af, dus vertel de stuurgroep maar hoe je verder gaat

Noot: zelf voornamelijk engineer maar zowel PSM I (scrum.org) als Prince2 practitioner gedaan. Wellicht maak ik nog eens de overstap naar PM. Maar het is een vak apart en vooralsnog vind ik de techniek te leuk

Succes iig

[BCC]

Kijk vooral deze even: YouTube: So You Want to be an Ops Manager - Velocity Santa Clara 2016 - Ik ben zelf van developer/product owner naar devops manager gegaan en na 2 jaar voor mezelf begonnen. Het is echt niets voor mij - mensen die klagen dat hun collega te laat op het werk komt. Ik wil gewoon dingen bouwen. Als Freelancer kan ik daarin nog steeds doorgroeien gelukkig.

Ik zou lig geen manager worden als dat de enige manier is om door te groeien binnen het bedrijf waar je nu werkt. Ga dan solliciteren / voor jezelff beginnen Ik ken genoeg bedrijven waar de senior devs meer verdienen dan de manager, Als je in die 20 jaar geen management taken zelf hebt opgepakt liggen daar imho ook je interesses niet.

[ Voor 6% gewijzigd door BCC op 02-03-2018 20:45 ]

[pirke]

BCC schreef op vrijdag 2 maart 2018 @ 20:43:

[...]

Ik zou lig geen manager worden als dat de enige manier is om door te groeien binnen het bedrijf waar je nu werkt. Ga dan solliciteren / voor jezelff beginnen Ik ken genoeg bedrijven waar de senior devs meer verdienen dan de manager, Als je in die 20 jaar geen management taken zelf hebt opgepakt liggen daar imho ook je interesses niet.

Vaak zie je twee richtingen: management of architectuur, waarbij management de echt lucratieve kansen biedt aan een select groepje. Van teamleider, naar projectleider, naar afdelingshoofd, naar vice president, senior vice president en board member. Je moet dan wel bereid zijn flinke offers te maken, en de meesten zullen zo ver niet komen. Op architectuurvlak doorgroeien ga je van technical lead binnen het team in stappen naar product/systeem architect.

Voor wat betreft je netto inkomen zijn er weinig (senior) developers die meer verdienen dan de projectleider of het afdelingshoofd. Meer dan de teamleider komt wat vaker voor. Maar als je echt wilt harken moet je inderdaad gaan freelancen. In mijn huidige rol als senior developer verdien ik netto hoogstwaarschijnlijk meer dan ons afdelingshoofd, plus ik heb minder "gedoe" Het feit dat ik zowel management als architectuur ervaring heb helpt natuurlijk, maar de echte winst zit hem simpelweg in goed onderhandelen, de belastingvoordelen en aftrekposten, en geen detacherings- of tussenbureau die flinke marges afsnoepen. Het nadeel is dat je meestal geen doorgroeimogelijkheden krijgt, omdat ze niet in je gaan investeren. Je wordt betaald voor wat je kan, niet voor je potentieel. Daarom eerst doorgroeien in loondienst, het liefst in verschillende rollen, en daarna als freelancer doen wat je het leukste vind tegen 2x je oude netto salaris.

[Croga]

Anoniem: 832815 schreef op vrijdag 2 maart 2018 @ 20:20:
Volgens mij kun je Prince2 en Agile niet op die manier met elkaar vergelijken; Agile wordt gebruikt bij het ontwikkelen van de software en Prince2 is meer een project-management methode (communicatie met de klant, managen van resources, issues en risico's, planning, rapportage etc.).

Zodra je ze zo gaat bekijken kun je net zo goed Scrum het raam uit gooien.

Agile wordt gebruikt voor het hele bedrijf. Zo niet dan wordt er geen Agile gebruikt.
- Communicatie met de klant doe je continu, incrementeel en iteratief. Dus niet de vaste contactmomenten die Prince beschrijft maar gewoon altijd.
- Managen van resources gebeurt tegenwoordig gewoon in de cloud. Tenzij je bedoelt "Managen van mensen", dat is in Scrum en Agile ingebakken. Zodra je mensen "resources" gaat noemen heb je de strijd, alweer, verloren.
- Issues bestaan niet in Scrum. Een issue los je op. Nu. Dat hoeft dus niet gemanaged te worden
- Risicos haal je weg. Nu. Dat hoeft dus niet gemanaged te worden. En zeker niet op de manier die Prince2 voor staat. Een "Risico lijst" is een manier om dingen weg te moffelen, niet een manier om ze op te lossen
- Rapportage is ingebakken in Scrum. Meer dan wat er daar in beschikbaar is rapporteer je niet. Rapportages buiten de Sprint review zijn pure waste.

Ik vindt het heel erg jammer om te zien dat je nu Project Manager wordt. Het is een uitstervend beroep, en met recht. Nog sterker: Ik baal er iedere keer weer van als een goede software engineer/architect verloren gaat aan zoiets. Software engineers zijn de belangrijkste personen in ieder software development traject. Daar hebben we in Nederland dan ook het grootste tekort aan. Project managers hebben we er 15 in een dozijn.

[BCC]

Mkb Nederland wil om de een of andere reden niet genoeg betalen voor goede vakmensen om ze aan te trekken/te houden. In de bouw zie je dat nu ook Backfireen. Projecten die verkocht worden zonder dat je het personeel hebt en dan huilen dat freelancers zo duur zijn.

[ Voor 43% gewijzigd door BCC op 03-03-2018 08:20 ]

[Lethalis]

Croga schreef op vrijdag 2 maart 2018 @ 22:28:
[...]
Ik vindt het heel erg jammer om te zien dat je nu Project Manager wordt. Het is een uitstervend beroep, en met recht. Nog sterker: Ik baal er iedere keer weer van als een goede software engineer/architect verloren gaat aan zoiets. Software engineers zijn de belangrijkste personen in ieder software development traject. Daar hebben we in Nederland dan ook het grootste tekort aan. Project managers hebben we er 15 in een dozijn.

Dat ben ik met je eens en omdat vraag en aanbod salarissen bepaalt, zou je ook verwachten dat een software engineer meer verdient dan een project manager.

Maar ja, daar gaat het dus mis.

Als software engineer loop je als ervaren kracht tegen een salarisplafond aan. En dan moet je dus "iets anders" als je meer wil verdienen.

Toen wij nog deel uitmaakten van een grotere onderneming kregen sommige ontwikkelaars zelfs een andere functietitel (bijvoorbeeld "product specialist") alleen maar omdat ze anders bovenschalig zouden zijn en dus nooit meer opslag zouden krijgen.

Terwijl managers veel hogere salarissen hadden...

[Croga]

Lethalis schreef op zaterdag 3 maart 2018 @ 08:21:
Dat ben ik met je eens en omdat vraag en aanbod salarissen bepaalt, zou je ook verwachten dat een software engineer meer verdient dan een project manager.

Maar ja, daar gaat het dus mis.

Als software engineer loop je als ervaren kracht tegen een salarisplafond aan. En dan moet je dus "iets anders" als je meer wil verdienen.

Toen wij nog deel uitmaakten van een grotere onderneming kregen sommige ontwikkelaars zelfs een andere functietitel (bijvoorbeeld "product specialist") alleen maar omdat ze anders bovenschalig zouden zijn en dus nooit meer opslag zouden krijgen.

Terwijl managers veel hogere salarissen hadden...

Ik ben het met je eens dat dat altijd het probleem geweest is. Gelukkig zie ik het nu hier en daar langzaam veranderen. Vooral omdat het hele concept "managers" geminimaliseerd wordt. Helaas is dat niet van de ene op de andere dag verandert en is er nog heel wat werk te doen aan de HR kant én aan de OR kant van bedrijven.

Steeds meer zijn bedrijven aan het kijken naar salaris op basis van de toevoeging aan het bedrijf. Een Project Manager voegt geen enkele waarde toe aan het bedrijf en ik plijt er dus ook overal voor de functie volledig weg te snijden.

Ik vindt het absoluut terecht dat een CEO meer verdient dan een engineer. Ik vindt het absolute nonsense dat een Project Manager meer verdient dan een engineer. En ik doe hard mijn best bedrijven dit te laten begrijpen. Een echte goede software engineer gaat je zowel veel meer opleveren als veel meer besparen dan willekeurig welke middle-manager.

[BCC]

Er zijn ook tech managers waar ik wel van vind dat ze software engineers++ zijn trouwens 😀

[wm1234]

Het lijkt mij logisch dat developers minder verdienen dan een manager. Het blijft uiteindelijk een uitvoerende kracht, zonder budget verantwoordelijkheid en geen eind verantwoordelijkheid over meerdere mensen. Die taak is veel belastender. De meeste developers maken nou ook weer niet de meest hoogstaande dingen (de meeste opdrachten vragen ook niet zo diepgaande structuren) op de super experts daar gelaten.

Over het algemeen verdienen goede architecten ook een goed salaris, net zoveel als projectmanagers. Afhankelijk van de complexiteit waar de architect in acteert.

[Croga]

wm1234 schreef op zaterdag 3 maart 2018 @ 08:31:
Het lijkt mij logisch dat developers minder verdienen dan een manager. Het blijft uiteindelijk een uitvoerende kracht, zonder budget verantwoordelijkheid en geen eind verantwoordelijkheid over meerdere mensen. Die taak is veel belastender.

En laten nou juist Project Managers ook helemaal geen verantwoordelijkheid hebben. Al helemaal niet over meerdere mensen.

Ja, op papier wel. In de praktijk kan een Projectmanager niets doen om dat te beïnvloeden en dus gaat men over budget en weet men daar een goede smoes voor te verzinnen. Ik noem dat een wassen neus.
En zelfs wanneer het budget niet past wordt de "schuld" alsnog naar beneden door geschoven.

Ik heb het zelf jaren gedaan. Nooit enige druk gevoeld omdat het middle management elkaar toch wel vrij praat. Snij die hele laag er tussenuit en er verandert daadwerkelijk helemaal niets.

wm1234 schreef op zaterdag 3 maart 2018 @ 08:31:
De meeste developers maken nou ook weer niet de meest hoogstaande dingen (de meeste opdrachten vragen ook niet zo diepgaande structuren) op de super experts daar gelaten.

Dat klopt. Niemand pleit er voor om álle developers enorme bergen geld te geven. Maar een plafond instellen als je niet uit de software engineering stapt is IBM-theorie en de basis voor The Peter Principle.

[ Voor 22% gewijzigd door Croga op 03-03-2018 08:38 ]

[wm1234]

Ik zal er is in duiken. Ik ben het wel met je eens dat je als project manager wel een toegevoegde waarde moet leveren maar om het helemaal af te schaffen.

Ik zie de meeste technische mensen nog niet direct met de klant praten (sowieso meerdere aanspreekpunten) en op individueel niveau continue beslissingen nemen. Je kan natuurlijk een scrum master nemen maar gaat die dan ook de facturen maken en verantwoorden. Ik zie het nog niet zo snel gebeuren of je krijgt alweer snel een manager met een andere naam.

[Croga]

wm1234 schreef op zaterdag 3 maart 2018 @ 08:47:
Ik zal er is in duiken. Ik ben het wel met je eens dat je als project manager wel een toegevoegde waarde moet leveren maar om het helemaal af te schaffen.

Ik zie de meeste technische mensen nog niet direct met de klant praten (sowieso meerdere aanspreekpunten) en op individueel niveau continue beslissingen nemen. Je kan natuurlijk een scrum master nemen maar gaat die dan ook de facturen maken en verantwoorden. Ik zie het nog niet zo snel gebeuren of je krijgt alweer snel een manager met een andere naam.

Nee, daar heb je een Product Owner voor. Die praat met de stakeholders, zorgt dat er duidelijk is wat er gewenst/nodig is en zorgt eventueel dat de developers zelf met de gebruiker om de tafel gaan zitten. Ik zie de meest technische mensen zeker wél direct met de eindgebruiker praten. Dat zijn namelijk de enige twee partijen die exact weten van de hoed en de rand. Een projectmanager kan daar alleen maar extra onduidelijkheid in zaaien maar kan zeker nooit, op geen enkele manier, die communicatie verbeteren.

Maar je beschrijving klinkt erg als die van een software huis wat software voor anderen aan het bouwen is. Ook dat model heeft zijn langste tijd gehad. Ik ken geen enkel stuk software wat buiten een bedrijf gebouwd is, wat niet 100 keer beter was geweest als het intern gebouwd was. Maar dat is weer een heel ander verhaal.....

[pirke]

Croga schreef op zaterdag 3 maart 2018 @ 08:37:

[...]

Dat klopt. Niemand pleit er voor om álle developers enorme bergen geld te geven. Maar een plafond instellen als je niet uit de software engineering stapt is IBM-theorie en de basis voor The Peter Principle.

Dat fenomeen heb ik helaas regelmatig mogen observeren, leuk dat er een naampje aanhangt

[Croga]

pirke schreef op zaterdag 3 maart 2018 @ 09:54:
Dat fenomeen heb ik helaas regelmatig mogen observeren, leuk dat er een naampje aanhangt

Bedenk je vooral goed dat Systems Thinking stelt dat negatieve zaken binnen een bedrijf nauwelijks aan personen te wijten zijn maar nagenoeg altijd veroorzaakt worden door het systeem.

The Peter Principle is één van de meest ernstige vormen hier van. Zo lang "managers" meer geld (en dus waardering-by-proxy) ontvangen dan engineers, zal iedere engineer proberen manager te worden. Onafhankelijk van geschiktheid of de nood aan management. En aangezien salaris schalen vooral door managers bepaald worden, die allemaal onderdeel zijn van dit systeem, zal dat ook in stand blijven. Dit is, helaas, niet iets wat eenvoudig te veranderen is (of mischien wel gelukkig anders zat ik weer zonder werk )

[renegrunn]

Croga schreef op vrijdag 2 maart 2018 @ 22:28:
[...]

Zodra je ze zo gaat bekijken kun je net zo goed Scrum het raam uit gooien.

Agile wordt gebruikt voor het hele bedrijf. Zo niet dan wordt er geen Agile gebruikt.
- Communicatie met de klant doe je continu, incrementeel en iteratief. Dus niet de vaste contactmomenten die Prince beschrijft maar gewoon altijd.
- Managen van resources gebeurt tegenwoordig gewoon in de cloud. Tenzij je bedoelt "Managen van mensen", dat is in Scrum en Agile ingebakken. Zodra je mensen "resources" gaat noemen heb je de strijd, alweer, verloren.
- Issues bestaan niet in Scrum. Een issue los je op. Nu. Dat hoeft dus niet gemanaged te worden
- Risicos haal je weg. Nu. Dat hoeft dus niet gemanaged te worden. En zeker niet op de manier die Prince2 voor staat. Een "Risico lijst" is een manier om dingen weg te moffelen, niet een manier om ze op te lossen
- Rapportage is ingebakken in Scrum. Meer dan wat er daar in beschikbaar is rapporteer je niet. Rapportages buiten de Sprint review zijn pure waste.

Ik vindt het heel erg jammer om te zien dat je nu Project Manager wordt. Het is een uitstervend beroep, en met recht. Nog sterker: Ik baal er iedere keer weer van als een goede software engineer/architect verloren gaat aan zoiets. Software engineers zijn de belangrijkste personen in ieder software development traject. Daar hebben we in Nederland dan ook het grootste tekort aan. Project managers hebben we er 15 in een dozijn.

Geheel eens met je eerste punten, maar niet met de laatste alinea 'Het is een uitstervend beroep, en met recht.'. Net zoals de keuze van methodologie (geen 1 is perfect), is de noodzaak van een project manager geheel afhankelijk van tal van factoren.
Ik werk al 10 jaar binnen een e-commerce bedrijf als project manager. Bij mijn vorige bedrijf zijn we volledig overgestapt naar Agile, en werd met recht de project manager overbodig (wel 2 functies nodig voor scrum ipv 1, maar dat terzijde).
Maar nadat ik de overstap maakte naar ons moederbedrijf, ben ik aangebleven als project manager. Alhoewel de omgeving waarin ik in werk merendeel Agile werkt, is er toch een PM nodig. Het gaat om een wereldwijde organisatie waarin ik als PM verantwoordelijk ben voor de implementatie van een nieuw e-com platform. Developers zitten in Mumbai en Edinburgh, business owners in de VS, klant in Schotland, Frankrijk en Oostenrijk. Het managen van verwachtingen, planningen, communicatie etc verloopt via mij. Sprint planning e.d. worden gedaan op lokaal niveau.

Om terug te komen op TS: laat je niet leiden door de keuze van een methodologie. Scrum, Kanban, Prince2 etc zijn beurt allemaal erg populair, maar geen 1 is perfect. Het is geheel afhankelijk van de organisatie, product en mensen wat werkt. Pas toe wat werkt voor deze mix.

[Croga]

renegrunn schreef op zaterdag 3 maart 2018 @ 12:53:
Alhoewel de omgeving waarin ik in werk merendeel Agile werkt, is er toch een PM nodig. Het gaat om een wereldwijde organisatie waarin ik als PM verantwoordelijk ben voor de implementatie van een nieuw e-com platform. Developers zitten in Mumbai en Edinburgh, business owners in de VS, klant in Schotland, Frankrijk en Oostenrijk. Het managen van verwachtingen, planningen, communicatie etc verloopt via mij. Sprint planning e.d. worden gedaan op lokaal niveau.

Ik hoop dat je begrijpt dat daar een PM nodig is omdat het bedrijf niet Agile werkt.....
- Project gebaseerd werken in plaats van product gebaseerd
- Nog geen idee wat een product, in concept, in houdt
- Geen colocated teams en dus geen Agile

Ik zeg niet dat PMs nú overbodig zijn. Ik zeg dat ze een uitstervend ras zijn omdat ze overbodig zullen raken....

[renegrunn]

Croga schreef op zaterdag 3 maart 2018 @ 13:01:
[...]

Ik hoop dat je begrijpt dat daar een PM nodig is omdat het bedrijf niet Agile werkt.....
- Project gebaseerd werken in plaats van product gebaseerd
- Nog geen idee wat een product, in concept, in houdt
- Geen colocated teams en dus geen Agile

Ik zeg niet dat PMs nú overbodig zijn. Ik zeg dat ze een uitstervend ras zijn omdat ze overbodig zullen raken....

'Het' bedrijf bestaat niet in mijn geval. Het gaat hier om meerdere ondernemingen (binnen dezelfde NV) die allen op een eigen manier werken. De organisatie waarvan ik deel uitmaak is agile - van links naar rechts en van onder tot boven.
Ik ben het met je eens dat de functie van PM waarschijnlijk minder nodig zal zijn in de toekomst, maar ik denk niet dat het volledig zal verdwijnen. Misschien tot een minimum binnen IT, maar er is meer dan IT in de wereld. En dan nog, over 10-15 jaar vinden we waarschijnlijk product owner / scrum master hopeloos ouderwets omdat er weer een nieuwe stroming is opgestaan, en dat is prima omdat de wereld om ons heen en organisaties mee veranderen.
Wat ik probeer te verduidelijken het is niet zwart-wit, elke organisatie is anders waarvoor de ene methode beter werkt dan de andere.

[m-vw]

Project management valt en staat met de heilige drie-éénheid (triple constraint) Scope-Tijd-Kwaliteit.

Simpel uitgelegd: Wijziging van één heeft consequenties op de ander twee. Dat zijn de te managen pijlers.
Je krijgt te maken met interne en externe Stakeholders (nog zo'n leuke term) aan wie je bovenstaande waarschijnlijk keer op keer op één of andere manier moet uitleggen.

Misschien heb ik er overheen gelezen, maar ik zag enkel administratie, geen budgetverantwoordelijke?

Er zijn zeer veel cursussen/opleidingen, maar uit eindelijk komt het allemaal op hetzelfde neer.

[Yucon]

Van architect naar projectmanager vind ik een vrij aparte move. Als mensen vanuit een technische achtergrond projectmanager wordt dan is die splitsing vaak eerder in hun carriere. Hoe is het balletje zo gerold?

Tegelijkertijd lijkt het me geweldig lastig om inhoudelijk van het project af te blijven. Dat is altijd lastig als je uit een inhoudelijke functie komt, maar als architect ben je al gewend om van bovenaf te kijken. Dan wordt het volgens mij helemaal moeilijk.

[Anoniem: 832815]

Croga schreef op zaterdag 3 maart 2018 @ 08:54:
[...]

Nee, daar heb je een Product Owner voor. Die praat met de stakeholders, zorgt dat er duidelijk is wat er gewenst/nodig is en zorgt eventueel dat de developers zelf met de gebruiker om de tafel gaan zitten. Ik zie de meest technische mensen zeker wél direct met de eindgebruiker praten. Dat zijn namelijk de enige twee partijen die exact weten van de hoed en de rand. Een projectmanager kan daar alleen maar extra onduidelijkheid in zaaien maar kan zeker nooit, op geen enkele manier, die communicatie verbeteren.

Wellicht had ik de term Project Manager niet moeten gebruiken in dit draadje; mijn toekomstige rol is eigenlijk een (misschien wel heel lastige) combinatie van Product Owner (de software wordt middels Agile / Scrum ontwikkeld), budget bewaker bij fixed price projecten en begeleider / ondersteuner van de project medewerkers etc. etc. Eigenlijk alles wat komt kijken bij het hele ontwikkeltraject uitgezonderd het allereerste sales contact en het pure ontwikkelwerk. De duur van de projecten loopt uiteen van een aantal weken tot een aantal jaren.

[ Voor 7% gewijzigd door Anoniem: 832815 op 03-03-2018 20:51 ]

[Anoniem: 832815]

renegrunn schreef op zaterdag 3 maart 2018 @ 12:53:
[...]
Om terug te komen op TS: laat je niet leiden door de keuze van een methodologie. Scrum, Kanban, Prince2 etc zijn beurt allemaal erg populair, maar geen 1 is perfect. Het is geheel afhankelijk van de organisatie, product en mensen wat werkt. Pas toe wat werkt voor deze mix.

Hier ben ik het helemaal mee eens; ik heb een gezond wantrouwen tegen iedereen die verkondigt de perfecte methodologie ontdekt te hebben; zo'n 'silver bullet' bestaat gewoonweg niet.

[Anoniem: 832815]

Mocht iemand nog een keer in dezelfde situatie terechtkomen dan kan ik dit boek trouwens wel aanraden:
https://www.managementboe...ojectmanager-roel-wessels

Zag trouwens dat er ook een Agile toevoeging is op PRINCE2, hebben mensen daar al ervaring mee?
https://www.axelos.com/be...ons/prince2/prince2-agile

[The Eagle]

Geen ervaring, maar van wat ik begrepen heb waren de makers van PRINCE2 een beetje van de wap dat iedereen ineens agile wilde werken, en hebben ze geprobeerd Scrum in een prince2 jasje te gieten. Soort oude wijn in nieuwe zakken dus, aldus zo komt het over.

Agile werken is ook organisationele impact, je organisatie moet er klaar voor zijn. Dat heb je met PRINCE2 niet, daar heb je gewoon watervalmodel. Als ik me god herinner laat men bij agile prince2 de diverse fases in de waterval agile uitvoeren. Maar het blijft natuurlijk nog steeds een waterval

[Anoniem: 832815]

The Eagle schreef op vrijdag 16 maart 2018 @ 10:55:
Geen ervaring, maar van wat ik begrepen heb waren de makers van PRINCE2 een beetje van de wap dat iedereen ineens agile wilde werken, en hebben ze geprobeerd Scrum in een prince2 jasje te gieten. Soort oude wijn in nieuwe zakken dus, aldus zo komt het over.

Agile werken is ook organisationele impact, je organisatie moet er klaar voor zijn. Dat heb je met PRINCE2 niet, daar heb je gewoon watervalmodel. Als ik me god herinner laat men bij agile prince2 de diverse fases in de waterval agile uitvoeren. Maar het blijft natuurlijk nog steeds een waterval

Ok, duidelijk. Ik ga eerst maar eens beginnen aan de PSM1 (en wellicht PSPO1) certificering en daarna verder kijken.

[downtime]

Anoniem: 832815 schreef op zaterdag 3 maart 2018 @ 19:55:
[...]

Wellicht had ik de term Project Manager niet moeten gebruiken in dit draadje; mijn toekomstige rol is eigenlijk een (misschien wel heel lastige) combinatie van Product Owner (de software wordt middels Agile / Scrum ontwikkeld), budget bewaker bij fixed price projecten en begeleider / ondersteuner van de project medewerkers etc. etc.

Gewoon uit nieuwsgierigheid: Hoe kun je nu Agile zijn bij een fixed price project? Fixed price houdt toch per definitie in dat functionaliteit van het eindproduct al vast ligt? Want waarover heb je anders een prijs afgesproken? Uitgangspunt van Agile is nu juist dat die functionaliteit, en daarmee de prijs, in de loop van het project kan wijzigen.

Of bedoel je dat je zowel Agile als Waterval projecten doet en je rol dus per project kan varieren?

[JaQ]

@CommanderJ Chen heeft een heel aardig stukje geschreven over de overgang van software engineer naar product manager. In mijn beleving is dat de minder hippe benaming van een product owner. Misschien kan je er wat mee?

downtime schreef op maandag 26 maart 2018 @ 21:32:
[...]

Gewoon uit nieuwsgierigheid: Hoe kun je nu Agile zijn bij een fixed price project? Fixed price houdt toch per definitie in dat functionaliteit van het eindproduct al vast ligt? Want waarover heb je anders een prijs afgesproken? Uitgangspunt van Agile is nu juist dat die functionaliteit, en daarmee de prijs, in de loop van het project kan wijzigen.

Of bedoel je dat je zowel Agile als Waterval projecten doet en je rol dus per project kan varieren?

Dus jij begint een product/project zonder beschrijving van een minimal viable product?

Je kan toch prima een X aantal sprints afnemen op basis van een beschrijving van een minimal viable product? Agile is geen excuus om niet te plannen

[ Voor 57% gewijzigd door JaQ op 26-03-2018 21:39 ]

[Yucon]

downtime schreef op maandag 26 maart 2018 @ 21:32:
[...]

Gewoon uit nieuwsgierigheid: Hoe kun je nu Agile zijn bij een fixed price project? Fixed price houdt toch per definitie in dat functionaliteit van het eindproduct al vast ligt? Want waarover heb je anders een prijs afgesproken? Uitgangspunt van Agile is nu juist dat die functionaliteit, en daarmee de prijs, in de loop van het project kan wijzigen.

Of bedoel je dat je zowel Agile als Waterval projecten doet en je rol dus per project kan varieren?

Je kunt de functionaliteit als 'bruikbare software' definieren. Of 'een redelijk werkend prototype'. Maar dat werkt alleen bij veel vertrouwen van de betrokken partijen, plus de optie om er nog een scrum achteraan te doen. 'Fixed price' is dan zoiets als 'fixed price tot een werkend resultaat' en niet noodzakelijk 'tot een compleet afgerond eindresultaat'. Het wordt voornamelijk gebruikt voor situaties waar het voor beide partijen duidelijk is dat compleet fixed price gewoon niet haalbaar is en men tevens meent dat er toch meerdere iteraties voor een compleet afgerond product nodig zullen zijn.

Als de situatie zich er voor leent werkt het erg goed. Maar sowieso zit in een scrum al een zeker element van fixed price omdat het aantal uren vast ligt. De praktijk is wat weerbarstiger dan de theorie. Er kan dus wel eens wat geschoven worden met overuren of mensen aan andere projecten uitlenen waardoor toch wat verschil ontstaat, maar dat is meestal marginaal op het geheel. Wat je in ieder geval in je achterhoofd moet houden is dat er in sommige situaties dermate veel afhankelijkheden met andere business logic zijn dat je vooraf de details heel slecht in kunt schatten.

[ Voor 21% gewijzigd door Yucon op 26-03-2018 21:48 ]

[downtime]

JaQ schreef op maandag 26 maart 2018 @ 21:37:

Dus jij begint een product/project zonder beschrijving van een minimal viable product?

Minimal viable product zie ik als een tussenstap. Niet als het eindresultaat want dan ben je gewoon aan het watervallen met een Agile-sausje erover. Toch?

Overigens "begin" ik niks. Ik ben geen developer maar ik probeer gewoon wat verder dan alleen mijn eigen vak te kijken en er wellicht wat van te leren.

Je kan toch prima een X aantal sprints afnemen op basis van een beschrijving van een minimal viable product? Agile is geen excuus om niet te plannen

Agile is geen excuus om niet te plannen. Maar het zou je de flexibiliteit moeten bieden om de planning tijdens het traject bij te stellen.
Als bijstellen niet mogelijk is, omdat eindresultaat en prijs (en daarmee doorlooptijd zoals @Yucon terecht opmerkt) al vast liggen, dan zie ik niet waarom het nog Agile zou zijn.

Zoals het mij uitgelegd is:

• Bij een project draait het om een afweging tussen kwaliteit/functionaliteit, budget en tijd. Bij waterval ligt de functionaliteit (in principe) vast en kun je dus alleen bijsturen op de factoren budget en tijd. In de praktijk betekent dit dat tegenvallers tot budgetoverschrijdingen en vertraging leiden.
• Bij Agile kun je ook bijsturen op de factor kwaliteit/functionaliteit. Daardoor hoeft een tegenvaller niet altijd tot budgetoverschrijdingen en vertraging te leiden. Je kunt er ook voor kiezen om minder functionaliteit af te nemen en op die manier budget en tijdslijnen te controleren.

Maar wellicht heb ik nu helemaal verkeerd begrepen wat Agile doet.

Yucon schreef op maandag 26 maart 2018 @ 21:44:
[...]

Als de situatie zich er voor leent werkt het erg goed. Maar sowieso zit in een scrum al een zeker element van fixed price omdat het aantal uren vast ligt. De praktijk is wat weerbarstiger dan de theorie. Er kan dus wel eens wat geschoven worden met overuren of mensen aan andere projecten uitlenen waardoor toch wat verschil ontstaat, maar dat is meestal marginaal op het geheel. Wat je in ieder geval in je achterhoofd moet houden is dat er in sommige situaties dermate veel afhankelijkheden met andere business logic zijn dat je vooraf de details heel slecht in kunt schatten.

Per sprint is inderdaad sprake van fixed price omdat prijs direct aan besteedde uren gerelateerd is en je maar beperkt met personeel kunt schuiven. Maar een project bestaat toch uit meerdere sprints en als het minimal viable product er eenmaal staat dan kun je in principe elke sprint opnieuw bepalen of die sprint de extra kosten waard is.

[JaQ]

downtime schreef op maandag 26 maart 2018 @ 22:25:
Minimal viable product zie ik als een tussenstap. Niet als het eindresultaat want dan ben je gewoon aan het watervallen met een Agile-sausje erover. Toch?

Ik zie het meer zoals je het zelf aan het einde van je reactie beschrijft: het minimale product waarmee de klant tevreden is icm een fixed aantal sprints. Je zal dan vooraf toch een idee moeten hebben van hoe lang je over het minimale product gaat doen. En inderdaad, dat is het startpunt. Het idee is dat je daar van kan afwijken op basis van gewogen keuzes (bijvoorbeeld door meer budget of minder functionaliteit).

downtime schreef op maandag 26 maart 2018 @ 22:25:
Overigens "begin" ik niks. Ik ben geen developer maar ik probeer gewoon wat verder dan alleen mijn eigen vak te kijken en er wellicht wat van te leren.

Excuus, dat bedoelde ik niet zo agressief als het wellicht over kwam

downtime schreef op maandag 26 maart 2018 @ 22:25:
Agile is geen excuus om niet te plannen. Maar het zou je de flexibiliteit moeten bieden om de planning tijdens het traject bij te stellen.
Als bijstellen niet mogelijk is, omdat eindresultaat en prijs (en daarmee doorlooptijd zoals @Yucon terecht opmerkt) al vast liggen, dan zie ik niet waarom het nog Agile zou zijn.

Zoals het mij uitgelegd is:

• Bij een project draait het om een afweging tussen kwaliteit/functionaliteit, budget en tijd. Bij waterval ligt de functionaliteit (in principe) vast en kun je dus alleen bijsturen op de factoren budget en tijd. In de praktijk betekent dit dat tegenvallers tot budgetoverschrijdingen en vertraging leiden.
• Bij Agile kun je ook bijsturen op de factor kwaliteit/functionaliteit. Daardoor hoeft een tegenvaller niet altijd tot budgetoverschrijdingen en vertraging te leiden. Je kunt er ook voor kiezen om minder functionaliteit af te nemen en op die manier budget en tijdslijnen te controleren.

Maar wellicht heb ik nu helemaal verkeerd begrepen wat Agile doet.

Ik denk dat ik ongeveer dezelfde definitie volg. Met de kanttekening dat de minimale functionaliteit soms een vereiste is, schrappen is niet altijd een optie.

Een voorbeeld uit mijn praktijk (Ik werk voor een bank en bemoei me daar met finance en IT): Als je denkt aan rapportages op basis van wet en regelgeving dan is het minimale product (=het correct en complete rapport) echt het minimum. Performance-verbeteringen, procesverbeteringen, architectuurverbeteringen etc. zou je als additionele features kunnen zien bovenop het minimale product. Ja dat komt gevaarlijk dicht bij waterval, maar ja.. hoe ga je anders om met externe verplichtingen in een agile omgeving?

En als je je bedenkt wat er nodig is om zo'n rapport te maken qua inspanning dan wordt het helemaal interessant. Nieuwe Europesche wetgeving als AnaCredit die binnenkort van kracht wordt betekent een enorm "project". Data uit een hele rits systemen die verspreid zijn over veel landen. Requirements vanuit "de klant" zijn helder (dat is namelijk de wet, alhoewel iedere regulator per land een eigen interpretatie aan de wet heeft gegeven ). Kortom: een kloppend rapport dat over meerdere landen gaat, met meerdere interpretaties (=attributen op het rapport) maar dat op groepsniveau nog steeds klopt. Je kan wel op je vingers natellen dat je het dan over een redelijk aantal squads hebt. Ik gok zomaar dat de ECB er niet mee akkoord gaat als het rapport niet geleverd wordt "omdat het niet in de sprint planning paste omdat de PO andere prio's stelt"'

En ow ja, de bank waar ik werk heeft zo ongeveer in ieder blaadje gestaan als voorbeeld voor een "agile" transformatie.

Nu lijk ik misschien cynisch, maar ik geloof absoluut in engineering culture en inhoudelijke kennis tot aan de top. Ik ben echter minder verliefd op rituelen die bij religies horen, misschien te praktisch ingesteld?

[downtime]

JaQ schreef op maandag 26 maart 2018 @ 22:48:
[...]

Excuus, dat bedoelde ik niet zo agressief als het wellicht over kwam

Geen probleem. Ik wou gewoon duidelijk maken dat ik geen "practitioner" ben maar een relatieve buitenstaander die een concept probeert te begrijpen waar ik vaak tegenstrijdige meningen over hoor, ook van mensen die er wel dagelijks mee werken.

Ik denk dat ik ongeveer dezelfde definitie volg. Met de kanttekening dat de minimale functionaliteit soms een vereiste is, schrappen is niet altijd een optie.

Performance-verbeteringen, procesverbeteringen, architectuurverbeteringen etc. zou je als additionele features kunnen zien bovenop het minimale product. Ja dat komt gevaarlijk dicht bij waterval, maar ja.. hoe ga je anders om met externe verplichtingen in een agile omgeving?

Ik zou zeggen dat je dan weliswaar een Agile werkwijze volgt maar zo aan handen en voeten gebonden bent dat je (in dat project) niet de potentiele voordelen van Agile kunt realiseren. Het eindproduct ligt immers vast, de tijdslijnen ook, en dus heb je alleen financiele handvaten die je bij waterval ook al had.

Dat hoeft niet erg te zijn. Soms kies je een werkwijze gewoon omdat de betrokkenen ermee bekend zijn, en ze vertrouwt zijn met hun rol in die werkwijze, en niet omdat die werkwijze jou op dat moment andere voordelen oplevert.

Een voorbeeld uit mijn praktijk (Ik werk voor een bank en bemoei me daar met finance en IT): Als je denkt aan rapportages op basis van wet en regelgeving dan is het minimale product (=het correct en complete rapport) echt het minimum.

Ik werk zelf als IT-beheerder bij een financiele instelling. Ken het wereldje wel al is het indirect vanuit het contact met mensen uit "de business".

[Anoniem: 832815]

JaQ schreef op maandag 26 maart 2018 @ 21:37:
@CommanderJ Chen heeft een heel aardig stukje geschreven over de overgang van software engineer naar product manager. In mijn beleving is dat de minder hippe benaming van een product owner. Misschien kan je er wat mee?

Dank voor de link, het stukje bevestigt wat ik ook al van anderen hoor, het is vooral praten / overleggen / informeren en nagenoeg geen technisch inhoudelijk werk meer (op wat architectuur / globale designs reviews na).

Ik merk wel dat ik veel energie krijg van deze stap; nieuwe markt, nieuwe collegas, nieuwe rol en ik heb er veel zin in!