Acties:
  • 0 Henk 'm!

  • anyonas
  • Registratie: November 2000
  • Laatst online: 12-08 10:04
De afgelopen jaren ben ik nogal vaak een code monkey geweest in projecten en tegenwoordig vind ik het coderen zelfs niet meer zo leuk.

Sinds 2 weken zit ik op een ander project waar veel vergaderingen bij komen kijken. Mensen een klein beetje coördineren maakt er ook deel van uit. Verder moet ik veel research naar werkmethoden, technologieën en oplossingen doen (meer architecturaal). Het is een beetje een manusje van alles job.
Dit bevalt me heel goed omdat ik eindelijk een veel socialere positie heb en dat heb ik altijd wel gemist.
In het verleden heb ik ook al een beetje taakverdeling en opvolging mogen doen (delegeren). Coaching heb ik ook reeds moeten doen.
Dat zijn de leukste herinneringen aan men job.

Nu mijn vraag is eigenlijk of projectmanagement een realistische volgende stap is voor mij? Ik ben reeds 7,5 jaar actief als ontwikkelaar en heb al veel ervaring opgedaan op verschillende markten. Evolueren naar analist/architect interesseert me maar matig. Deze rol heb ik dan ook al deels kunnen doen maar het constant maken van analyses gaat snel vervelen voor me.

De interesse voor projectmanagement komt eigenlijk omdat ik een meer sociale job wil. Het hele realisatieproces interesseert me wel. Planning, time management, teammanagement, budget management schrikken me in eerste instantie ook niet af. Ik wil dan ook enkele opleidingen doen om de kennis op te doen.

Ik hoor steeds van andere developers dat ze nooit willen evolueren naar projectmanager. Zij coderen dan ook heel graag en zouden dat niet willen opgeven.

Is er iets dat ik over het hoofd zie?

Ter informatie:
- Ik heb geen hoger diploma
- ik ben heel sociaal en kan goed en rustig om met iedereen. Ontwikkelaar is niet echt een sociale job.

It's dark but I don't want to find the light


Acties:
  • 0 Henk 'm!

  • Valandil
  • Registratie: November 2002
  • Nu online
Uiteraard is dat mogelijk. Ik heb zelf de overstap gemaakt van Technisch beheer naar uiteindelijk technisch projectleider, projectmanager.

Het is niet een stap die je ineens maakt. Je moet daarvoor andere vaardigheden gaan ontwikkelen. Je komt (hoe zwaarder de klus) in lastige politieke situaties. Je softskills moeten steeds vaker gebruikt worden en je moet leren soms de inhoud los te laten.

Begin eens met Prince2 foundations, doe daarnaast wat "softe" trainingen om ook daar vaardigheden te leren.
Daarnaast moet ook de gelegenheid zich aandoen om die kant op te gaan. Een mooie eerste stap is inderdaad een coördinerende functie waarna je steeds meer verantwoordelijkheden krijgt. Kleine (deel)projecten.

Wat mij altijd goed geholpen heeft is een ervaren projectmanager als sparringspartner.

Mijn tips:
- begin klein
- anticipeer goed
- breng risico's tijdig in kaart
- zoek een ervaren sparringspartner
- leer van je fouten en leer van anderen
- blijf binnen je scope v/h project

[ Voor 10% gewijzigd door Valandil op 02-04-2009 21:38 ]

wijze woorden


Acties:
  • 0 Henk 'm!

  • André
  • Registratie: Maart 2002
  • Laatst online: 19-08 13:52

André

Analytics dude

Doe wat je gevoel je ingeeft, wat maakt het uit dat de andere developers het niet willen. Niet iedereen is hetzelfde. En als ik jou zo hoor lijkt het me gewoon een logische stap.

Acties:
  • 0 Henk 'm!

  • anyonas
  • Registratie: November 2000
  • Laatst online: 12-08 10:04
André schreef op donderdag 02 april 2009 @ 21:34:
Doe wat je gevoel je ingeeft, wat maakt het uit dat de andere developers het niet willen. Niet iedereen is hetzelfde. En als ik jou zo hoor lijkt het me gewoon een logische stap.
In het begin schrikte me dat idd een beetje af. Maar ik heb al wel gerealiseerd dat ik anders ben als hun en dat ik zulke functie liever zou doen dan puur te ontwikkelen. Maar als iedereen in je omgeving die functie af breekt zet je de stap toch minder snel.

Er zijn reeds enkele cursussen geplant via men werk. Ik hoop op die manier toch al heel wat te leren. Die Prince2 foundations zal ik ook alvast opnemen in mijn planning.

Bedankt voor de tips!

It's dark but I don't want to find the light


Acties:
  • 0 Henk 'm!

Verwijderd

Volgens mij is het heel logisch dat je na zoveel jaar programmeren wat anders wilt. De logische stap is doorgaans lead developer of architect etc., maar een ander traject kan net zo goed technisch projectleider of project manager zijn, waarom niet?

Het is overigens fijn dat je cursussen kan doen via je werk om daar te komen waar je heen wilt, dat betekent toch ook wel dat ze achter je staan in je ontwikkeling.

Overigens ben ik ook een ontwikkelaar die langzaam probeert door te groeien naar wat anders. Mijn directe collega's hebben die ambitie ook niet direct, maar vinden het verder ook niet raar dat ik dat wel heb.

Acties:
  • 0 Henk 'm!

  • Standeman
  • Registratie: November 2000
  • Laatst online: 09:57

Standeman

Prutser 1e klasse

Ik vind het ook wel een logische stap. Ik zelf zou die stap niet zo snel nemen en zou eerder kiezen voor de architecten kant. Tot nu toe vind ik het nog super om "code-monkey" te zijn. (Ik werk echter wel bij een heel klein bedrijfje, dus er zijn nog veel meer dingen te doen dan alleen code kloppen.)

The ships hung in the sky in much the same way that bricks don’t.


Acties:
  • 0 Henk 'm!

Verwijderd

anyonas schreef op donderdag 02 april 2009 @ 22:57:
In het begin schrikte me dat idd een beetje af. Maar ik heb al wel gerealiseerd dat ik anders ben als hun en dat ik zulke functie liever zou doen dan puur te ontwikkelen. Maar als iedereen in je omgeving die functie af breekt zet je de stap toch minder snel.

Er zijn reeds enkele cursussen geplant via men werk. Ik hoop op die manier toch al heel wat te leren. Die Prince2 foundations zal ik ook alvast opnemen in mijn planning.

Bedankt voor de tips!
Als je projectmanager wilt worden, betekent dat inderdaad dat je veel moet communiceren. Zowel mondeling als schriftelijk. Ik zou dan zeker wat aandacht aan je schrijfstijl gaan geven; bovenstaand stukje barst van de fouten namelijk.

Verder uiteraard Prince2 halen. Of voor een IPMA traject gaan.

Acties:
  • 0 Henk 'm!

  • anyonas
  • Registratie: November 2000
  • Laatst online: 12-08 10:04
Verwijderd schreef op vrijdag 03 april 2009 @ 11:37:
[...]

Ik zou dan zeker wat aandacht aan je schrijfstijl gaan geven; bovenstaand stukje barst van de fouten namelijk.
Ik had al wel een vermoeden dat ik daar een opmerking over ging krijgen. Op professioneel vlak hecht ik veel meer belang aan schrijffouten dan 's avonds in de zetel. Ik geef toe dat ik hier ook aan zal moeten werken.
Op het werk lees ik steeds alles meerdere keren na.

It's dark but I don't want to find the light


Acties:
  • 0 Henk 'm!

  • Falcon
  • Registratie: Februari 2000
  • Laatst online: 09:38

Falcon

DevOps/Q.A. Engineer

Is kwaliteit/testen projecten niet wat voor je?

"We never grow up. We just learn how to act in public" - "Dyslexie is a bitch"


Acties:
  • 0 Henk 'm!

Verwijderd

Hier ook van software ontwikkelaar nu al behoorlijk van jaren actief als project manager voor met name grotere software- en internetproducties (.NET). Alleen privé ontwikkel ik nog software, dus ik blijf een code monkey. Dat leer je niet af.

Voor sommige branches is het een nadeel om inhoudelijk op de hoogte te zijn van je vakgebied. Voor software ontwikkeling absoluut niet het geval. Als mijn projectteam aan komt met technische inschattingen ben ik goed in staat om realistische inschattingen te onderscheiden van de ach-doe-maar-maal-twee inschattingen. Daarnaast kan je op zowel functioneel als technisch vlak vanuit je ervaring sturen, en gaat het praten over technische onderwerpen veel sneller, je tikt dingen sneller af en je kunt sneller vooraf knelpunten zien aankomen.

Ik zie het ook bij collega pm's, die geen achtergrond hebben in de software ontwikkeling. Die hebben het echt heel moeilijk om controle te houden. Software ontwikkeling is één van de meest lastige vakgebieden om project management in uit te oefenen, veel diversiteit in technieken, dynamische ontwikkelingen, veel afhankelijkheden.

Ik doe met name de grotere trajecten omdat ik dit zelf gewoon een leuker gebied vindt dan het mkb. Vaak hoger budget, meer full service dienstverlening van strategie/concept tot lancering/maintenance, en meer lef en organisatie om dingen te doen die je in het mkb maar weinig tegen komt. Ik hou totaal niet van hit 'n run trajecten. Dan kak ik echt in, ik heb echt de uitdaging nodig van nieuwe concepten, nadenken over het concept, complexe technieken, etc.

Met software en concepten die organisaties veranderen, steengoed zijn uitgedacht, en echt een effect kunnen hebben daar maak je mij echt enthousiast mee. :)

[ Voor 7% gewijzigd door Verwijderd op 03-04-2009 14:30 ]


Acties:
  • 0 Henk 'm!

Verwijderd

anyonas schreef op vrijdag 03 april 2009 @ 13:44:
[...]

Ik had al wel een vermoeden dat ik daar een opmerking over ging krijgen. Op professioneel vlak hecht ik veel meer belang aan schrijffouten dan 's avonds in de zetel. Ik geef toe dat ik hier ook aan zal moeten werken.
Op het werk lees ik steeds alles meerdere keren na.
Waarom niet gewoon altijd correct schrijven? Wanneer je verschillende stijlen hanteert, lijkt het me logisch dat je juist meer fouten zult maken...

Acties:
  • 0 Henk 'm!

  • Testert
  • Registratie: Januari 2008
  • Laatst online: 30-09-2024
anyonas schreef op vrijdag 03 april 2009 @ 13:44:
[...]

Ik had al wel een vermoeden dat ik daar een opmerking over ging krijgen. Op professioneel vlak hecht ik veel meer belang aan schrijffouten dan 's avonds in de zetel. Ik geef toe dat ik hier ook aan zal moeten werken.
Op het werk lees ik steeds alles meerdere keren na.
Mijn advies: ga je gedragen naar wat je wilt worden. Wil je projectmanager worden:
- Wees je bewust van politiek, budgetten & risico's,
- Spreek collega's aan op hun gedrag op een constructieve manier,
- Denk vanuit de onderaannemersrol en zorg er voor dat de opdrachtgever krijgt waar hij/zij iets aan heeft, ook al druist dat soms in tegen je gevoel van techneutenethiek.

En, solliciteer bij een bedrijf wat je die mogelijkheden biedt en probeer alsnog dat diploma te halen.

Sjoch dizze stêd; sjoch wat der rûnom bart - It âlde spegelet him yn wat de takomst hat


Acties:
  • 0 Henk 'm!

  • Testert
  • Registratie: Januari 2008
  • Laatst online: 30-09-2024
Verwijderd schreef op vrijdag 03 april 2009 @ 14:27:
...

Alleen privé ontwikkel ik nog software, dus ik blijf een code monkey. Dat leer je niet af.

Voor sommige branches is het een nadeel om inhoudelijk op de hoogte te zijn van je vakgebied. Voor software ontwikkeling absoluut niet het geval. ...

Ik zie het ook bij collega pm's, die geen achtergrond hebben in de software ontwikkeling. Die hebben het echt heel moeilijk om controle te houden. Software ontwikkeling is één van de meest lastige vakgebieden om project management in uit te oefenen, veel diversiteit in technieken, dynamische ontwikkelingen, veel afhankelijkheden.

...
Ik ben het niet helemaal met je eens. Waarom zou het bij software ontwikkeling niet nadelig zijn om inhoudelijke kennis te hebben als het bij andere zaken wel zo is? Op welke andere branches doel je dan?

Ik zie het ook bij projectleiders, die geen achtergrond hebben in software ontwikkeling. Die vertrouwen op het oordeel van hun professionele teamleden. Bemoeien zich niet met de inhoud en houden de focus op budget, tijd en doelen. Hebben in mijn ervaring meer oog voor alternatieve oplossingen voor een probleem dan een bepaalde technische implementatie waar een procesaanpassing goedkoper en sneller is.

Een goede aannemer of architect hoeft geen goede timmerman te zijn geweest.

Sjoch dizze stêd; sjoch wat der rûnom bart - It âlde spegelet him yn wat de takomst hat


Acties:
  • 0 Henk 'm!

Verwijderd

Testert schreef op zaterdag 04 april 2009 @ 22:22:
Een goede aannemer of architect hoeft geen goede timmerman te zijn geweest.
Het hoeft inderdaad niet, maar het helpt wel. Als het bij jullie goed werkt, dan is dat vaak het gevolg van de juiste processen en vakmensen. In dat geval hoeft de project manager zich alleen te bekommeren om de cijfers en de planning.

Over dit onderwerp - en met name de positieve invloed op software trajecten - is door diverse vakmensen uit de software industrie veel interessants over geschreven. Het beschikbaar hebben van die ervaring 'kan' ervoor zorgen dat risico's voor budget en doorlooptijd sneller worden ontdekt. Het biedt je naast de input van je team de mogelijkheid om voor de klant betere beslissingen te nemen. Ik wil je graag de bron geven maar ik kan het hele boek hierover (van Microsoft) zo even niet in de kast terugvinden.

Maar nogmaals, het is geen don't. Het is voor software ontwikkeling echter gemiddeld genomen wel een voordeel.

Acties:
  • 0 Henk 'm!

  • Abbadon
  • Registratie: Februari 2000
  • Laatst online: 19-08 10:06
Ik ben ook na 7,5 jaar techniek uiteindelijk projectmanager geworden, dit geldt voor best wel veel projectleiders en -managers. Dus zeker een realistische stap :) Je moet het wel echt willen natuurlijk.

Verder sluit ik me bij Testert's verhaal aan; je hoeft echt geen technisch inhoudelijke kennis te hebben. Ik heb het bij collega's vaker als nadeel gezien dan als voordeel (lees: ze bemoeien zich teveel met de techniek waardoor belangrijkere zaken als scope, budget en planning niet genoeg aandacht kregen).

Begin idd eerst zo snel mogelijk met PRINCE2 Foundation. Een goede begeleider/buddy met ervaring is in het begin ook een must (en later nog steeds handig hoor). En zorg dat je ruimte krijgt om fouten te mogen maken.

Just pick a dead end and chill out 'till you die.


Acties:
  • 0 Henk 'm!

Verwijderd

Wordt er hier niet meer naar werkervaring icm leeftijd gekeken ?

Ik zie dat de TS 24 jaar is en de man hierboven toch wel een redelijk stukje ouder.

24 opzich met verantwoordelijkheden binnen een bedrijf kan... het kan hier alleen vaak veel geharrewar door geven en ik moet zeggen... veel 24 jarigen komen er later pas achter dat het wellicht toch anders had gemoeten omdat ze zo graag wilden.

Ik denk opzich dat het goed is dat je iets meer sociaal bezig bent en er rustig aan in stroomt dan dat je mag zeggen... kijk hier ben ik, 24 jaar en ik ga jou vertellen wat je moet doen collega van 35 !

UIteraard moet je wel lol in je werk hebben... echter is het niet alleen maar aansturen, vergaderen, etc... overal moet echt gewerkt worden... maar dat merk je pas als je het zat wordt :P

[ Voor 13% gewijzigd door Verwijderd op 06-04-2009 00:14 ]


Acties:
  • 0 Henk 'm!

Verwijderd

Abbadon schreef op zondag 05 april 2009 @ 22:50:
Verder sluit ik me bij Testert's verhaal aan; je hoeft echt geen technisch inhoudelijke kennis te hebben. Ik heb het bij collega's vaker als nadeel gezien dan als voordeel (lees: ze bemoeien zich teveel met de techniek waardoor belangrijkere zaken als scope, budget en planning niet genoeg aandacht kregen).

Begin idd eerst zo snel mogelijk met PRINCE2 Foundation. Een goede begeleider/buddy met ervaring is in het begin ook een must (en later nog steeds handig hoor). En zorg dat je ruimte krijgt om fouten te mogen maken.
Die collega's moeten dan op zoek naar de balans. Er is een flinterdunne lijn tussen code monkey die project management 'erbij' is gaan doen, en een project manager die zijn ervaring als code monkey in zijn voordeel gebruikt bij het managen van projecten en de teams. Als project manager krijg je ook te maken met administratieve taken die je moet uitvoeren om te kunnen meten, als die taken je niet liggen dan is project management niet een job die je gelukkig zal maken.

Het werkt overigens ook zo in de bouw; Als je een goede aannemer die het klappen van de zweep kent, kan hij/zij ook met suggesties komen die je waardevermeerdering kunnen opleveren. Dan moet de aannemer wel inhoudelijke ervaring hebben om je daarover te adviseren. Als je een papieren manager toewijst op een dergelijk project zal je project vast af komen, binnen de voorafvastgestelde scope maar over het algemeen zoeken de klanten een sparring partner om optimaal rendement te behalen, niet een expert in het lezen van excel sheets. Als je consultants naar binnen kunt schuiven kun je de rol van sparring partner volledig delegeren, maar dat is niet altijd een mogelijkheid.

Ik had het boek alweer teruggevonden, Scott Berkun, voormalig group manager bij Microsoft voor oa de Windows, IE divisies. Hij heeft zijn jarenlange pm ervaring in de software industrie op papier gezet. Veel interessante cases, strategiën voor gebruik op de werkvloer, politieke situaties, ik vond het zelf een erg interessant boek met nieuwe invalshoeken. Het boek heet the art of project management. :)

p.s. zijn er hier nog scrum liefhebbers aanwezig? :P

Acties:
  • 0 Henk 'm!

Verwijderd

Mag ik je aanraden om http://www.joelonsoftware.com/ eens te bekijken?

Die site barst van leuke, slimme artikelen (geschreven door Joel Spolsky) over de hoe en wat van software ontwikkelen en project managen.

Acties:
  • 0 Henk 'm!

  • kdekker
  • Registratie: Januari 2005
  • Niet online
Verwijderd schreef op maandag 06 april 2009 @ 09:16:
[...]
p.s. zijn er hier nog scrum liefhebbers aanwezig? :P
Wij scrummen er lustig op lus, al weer bijna een jaar, en dat bevalt prima. In 1 klap van een kostbaar scoping proces af en iedereen weet wat t'ie moet doen (voor de scrum periode dan). Wel is aan het einde de voorbereiding voor de demo, backlog doorlopen voor de volgende sprint en nadenken voor de komende planning + nog net afmaken van de taken van de aflopende sprint een periode met meer stress. Overigens plannen we maintenance (=klantendefects) ook als scrum taak. Ons scrum team telt 7 man, en we werken in blokken van ca. 6 weken.

Acties:
  • 0 Henk 'm!

Verwijderd

kdekker schreef op dinsdag 07 april 2009 @ 20:35:
[...]

Wij scrummen er lustig op lus, al weer bijna een jaar, en dat bevalt prima. In 1 klap van een kostbaar scoping proces af en iedereen weet wat t'ie moet doen (voor de scrum periode dan). Wel is aan het einde de voorbereiding voor de demo, backlog doorlopen voor de volgende sprint en nadenken voor de komende planning + nog net afmaken van de taken van de aflopende sprint een periode met meer stress. Overigens plannen we maintenance (=klantendefects) ook als scrum taak. Ons scrum team telt 7 man, en we werken in blokken van ca. 6 weken.
Waarom nemen jullie de resterende product backlog voor de volgende sprint backlog niet mee in de volgende sprint planning? Normaliter houdt je vier uur product backlog->sprint backlog aan en vier uur technische inschattingen / selectie items. Hele bedoeling van de sprint is juist dat je je niet bezig gaat houden met alles wat niet in de sprint backlog aanwezig is. Dat is gebruikelijk en scheelt veel stress. Of houden jullie dag laatste dag van de sprint aan als zgn. retrospective + voorbereiding sprint planning. :)

Maintenance moet je inderdaad opnemen als backlog item, en opnemen in een sprint backlog, dus dat is goed. :)

Trouwens wel lange sprint, gebruikelijk is 3 weken. Maximaal toegestane weken ligt op een maand, anders kun je tussentijds heel moeilijk nog bijsturen. Is daar nog een specifieke reden voor geweest?

Iig leuk om meer ervaringen te lezen. Demo's zijn altijd het struikelblok inderdaad. Hoor ik van veel meer mensen :D

Acties:
  • 0 Henk 'm!

  • Martin Sturm
  • Registratie: December 1999
  • Laatst online: 11-08 15:23
Sowieso is het echt toepassen van Scrum voor veel organisaties echt heel lastig. Volgens mij vervalt men vaak toch weer in niet gelijkwaardige rollen voor pm's en devvers, sprints worden (veel) te lang, en nog meer van dat soort dingen. Meestal is de achterliggende oorzaak dat men het toch te 'eng' vindt om echt agile te werken met de bijbehorende verantwoordelijkheden voor b.v. developers.

Acties:
  • 0 Henk 'm!

  • bonzz.netninja
  • Registratie: Oktober 2001
  • Laatst online: 08:59

bonzz.netninja

Niente baffi

Martin Sturm schreef op woensdag 08 april 2009 @ 00:06:
Sowieso is het echt toepassen van Scrum voor veel organisaties echt heel lastig. Volgens mij vervalt men vaak toch weer in niet gelijkwaardige rollen voor pm's en devvers, sprints worden (veel) te lang, en nog meer van dat soort dingen. Meestal is de achterliggende oorzaak dat men het toch te 'eng' vindt om echt agile te werken met de bijbehorende verantwoordelijkheden voor b.v. developers.
klopt wel een beetje. Wij proberen het wel heel erg hard (scrum). Sprints worden niet te lang, maar soms niet goed ingevuld. De taken zijn toch vaak niet los testbaar waardoor je eigenlijk een beetje het hele idee al snel mist. Maar goed. De sprint presentatie bijv. voegt wel echt iets toe. Het is echter niet angst of niet genoeg verantwoordelijkheden geven, maar meer dan de ontwikkelaar die verantwoordelijk niet wil pakken.

[ Voor 7% gewijzigd door bonzz.netninja op 08-04-2009 00:16 ]

vuistdiep in het post-pc tijdperk van Steve  | Joepie joepie. Dat ging echt toppie! | https://www.dedigitaletuin.nl


Acties:
  • 0 Henk 'm!

  • kdekker
  • Registratie: Januari 2005
  • Niet online
Verwijderd schreef op dinsdag 07 april 2009 @ 21:07:
[...]
Waarom nemen jullie de resterende product backlog voor de volgende sprint backlog niet mee in de volgende sprint planning? Normaliter houdt je vier uur product backlog->sprint backlog aan en vier uur technische inschattingen / selectie items. Hele bedoeling van de sprint is juist dat je je niet bezig gaat houden met alles wat niet in de sprint backlog aanwezig is. Dat is gebruikelijk en scheelt veel stress. Of houden jullie dag laatste dag van de sprint aan als zgn. retrospective + voorbereiding sprint planning. :)

Maintenance moet je inderdaad opnemen als backlog item, en opnemen in een sprint backlog, dus dat is goed. :)
De backlog die niet ingepland is gaat inderdaad automatisch naar de volgende sprint, maar omdat door de tijd prioriteiten veranderen kunnen en de backlog kan veranderen, doen we in de laatste week van de sprint al voorbereidingen voor de volgende sprint. Die voorbereidingen doet bijv. de architect of lead engineer, samen met de projectleider. Er is daarnaast een aparte ronde door de productowner die de backlog weer aanvult/prioriseert. De demo kost ca 1.5 uur, het plannen 3 a 4 uur.
Trouwens wel lange sprint, gebruikelijk is 3 weken. Maximaal toegestane weken ligt op een maand, anders kun je tussentijds heel moeilijk nog bijsturen. Is daar nog een specifieke reden voor geweest?
Hier mee voorkomen we dat de overhead van demo en planning niet te groot is t.o.v. de sprint. We spenderen ca 30% aan maintenance (waar dus weinig spannends is aan te demo-en). Die overige tijd gaat naar de backlog.

Maintenance wordt overigens ingepland in de vorm van 'queue mag niet hoger staan dan...'. Bij zeer veel inkomende defects loop je kans dat een volgende sprint meer tijd naar maintenance moet.

Naast ons eigen scrum team werken we gedeeltelijk samen (wel een apart backlog, maar wel op 1 product) met een ander team. Reden dat er 2 teams zijn is het aantal mensen (totaal 15).
Pagina: 1