Personateam

Uit Pareltaal
Ga naar: navigatie, zoeken


…productontwikkeling.

✣  ✣  ✣

Je wilt je organisatie inrichten op maximale klantgerichte waardecreatie.

Krachten:

  • De wet van conway ‘dwingt’ de architectuur tot afspiegeling van de organisatie en verhindert de ‘juiste’ architectuur die het best tegemoetkomt aan het vervullen van de wensen van de klant en haar waardecreatie.
  • Matrixorganisaties:
    • richten zich op maximale uitnutting en bezetting van haar menselijke hulpbronnen;
    • leiden tot overspecialisatie met een averechts effect op een gematigd tramgetal;
    • verhinderen het leren buiten de eigen specialiteit, hetgeen leidt tot verarming van het werk en minder werkplezier;
    • hebben de neiging het personeelsbestand van managers te verhogen.
  • Onderzoek toont een omgekeerd verband tussen het aantal managers en de productiviteit van ontwikkelaars—naarmate het aantal managers toeneemt, neemt de productie af; deze organisatievorm is riskant voor (software-)ontwikkeling en productie.
  • Teams met zowel interne als externe focus hebben grotere kans succesvol te zijn.
  • Overbodig maken van managers verlaagt overhead en is goedkoper.

Ook bekend als stabiele teams of feature teams. personateams richten zich nog meer dan feature teams op waardecreatie voor de klant.

Het ideale personateam:

  • leeft lang—het team blijft bij elkaar zodat ze kunnen samenklonteren voor betere prestaties, met een kans op hieperproductiviteit;
  • is multi-disciplinair—over functies en componenten heen;
  • werkt in dezelfde ruimte—noem het een atelier of studio;
  • werkt aan complete klantgerichte eigenschappen—over alle componenten en disciplines (analyse, ontwerp, realisatie, testen…) heen;
  • is samengesteld uit generalisatiespecialisten; en
  • is in scrum meestal zeven plus of min twee mensen.

Daarom:

Organiseer stabiele teams rondom klantgerichte waardecreatie en laat ze klantgerichte zaken van het uiteindelijke product bouwen. Breng met levendige persona's focus aan in alle activiteiten. Laat de stabiele teams zichzelf ontwikkelen tot bruisende, meesterlijke, autonome, zinnige en hieperproductieve teams en koester dat.

✣  ✣  ✣



✣  ✣  ✣



personateams kennen een lang leven en is multidisciplinair en genereren veel klantgerichte waarde, van begin tot einde.

In software-omgevingen loopt dat begin tot einde van de klant tot in de gegevensbank en terug.

Een personateam kent geen specialismen. Er is dus niet een persoon die alleen maar ontwikkelt en een ander persoon die alleen maar test. In principe kan iedereen alles wat nodig is om klantwensen te vervullen en zijn sommigen in bepaalde vaardigheden beter dan anderen. Bovendien leert elk teamlid voortdurend bij op nieuwe gebieden. Dit draagt bij aan een gematigd tramgetal en verrijkt het werk voor zowel het team als het individu.

Het team werkt volgens het credo maak af wat je begint en begin wat je afmaakt. Teamleden helpen elkaar om bepaalde verhalen af te maken.

Dynamisch evenwicht

Soms gaat er iemand, soms komt er iemand. De nadruk ligt hier op soms en op iemand. Het team wordt dus niet zomaar opgeheven of gehalveerd. Daarmee doe je jezelf als organisatie te kort. Teams ontmantelen is een desinvestering en kapitaalvernietiging. Je hebt net veel geïnvesteerd om het team door de forming, storming, norming en performing fases heen te halen. En nu het project is afgelopen hef je het team op. Zonde.

Je kan beter het team uit een nieuwe werkvoorraad laten putten. Of, beter nog, ervoor zorgen dat de werkvoorraad gevuld blijft en dat er altijd werk voor twee tot drie sprints is.

Op grote schaal kan je behoeftegebieden (need areas or requirement areas) of personateams definiëren, met daarin een of meer stabiele teams die een specifieke subset van de bedrijfsbrede product werkvoorraad naar zich toehaalt. Elk product werkvoorraad item is dan toegewezen aan precies één gebied en vormt zo de personawerkvoorraad of gebiedswerkvoorraad. Elk personawerkvoorraad heeft een eigen persona producteigenaar.

Opschalen kan goed tot ongeveer tien teams per producteigenaar. Komt het boven de tien teams, overweeg dan gradueel over te gaan naar personateams en/of behoeftegebieden.

De definitie van klaar geldt overkoepelend voor alle teams en het gehele productportfolio.

personateams minimaliseren op een krachtige manier kostbare overdracht, wachten, werk in uitvoering, informatieverstrooiing en onderbezet personeel.

personateams vormen een sleutel voor het versnellen van time to value en het opschalen van wnedbaar ontwikkelen. Voor de meesten is het langzame verloop van het hervormen van de teamstructuur en een beroep doet op het lerend vermogen, vele belanghebbenden, beleid en mentaliteit een bepalende organisationele uitdaging.

Een scrum team is per definitie een personateam en in staat om al het werk te doen om een gebruikersverhaal compleet te realiseren, op te leveren en te verschepen. Scrum teamleaden hebben geen speciale functie en zijn niets meer en ook niets minder dan teamlid. Er is geen speciale nadruk op titels zoals ‘ontwikkelaar’ versus ‘tester’. Iedereen helpt elkaar, ook op onbekend terrein, om het product zoals afgesproken op te leveren.

personateams zijn een verfijning van multi-disciplinaire teams, een goed onderzocht en bewezen praktijk om snelheid van ontwikkeling te verhogen.

personateams gaan over autonomie, verantwoordelijkheid, aanspreekbaarheid, identiteit, consent en balans.

  • Autonomie—Mensen aan het front weten kennen het klappen van de zweep op hun gebied beter dan ieder ander. Geef ze dus volledige zeggenschap over hun eigen gebied binnen de algemene richtsnoeren en beginselen van de organisatie.
  • Toerekeningsvatbaarheid—Als een gebalanceerde groep van mensen wederzijds aansprakelijk en toerekeningsvatbaar is voor alle aspecten van ontwerp, bouw, test, kwaliteit en het verschepen van een product (increment) verzinnen ze zelf manieren om kritische observaties met elkaar te delen, bijvoorbeeld tijdens een terugblik. Omdat ze aanspreekbaar zijn voelen ze zich ook eigenaar zodra ze het opmerken. Dit beeld geven ze door aan de rest van het team.
  • Identiteit—Met multi-disciplinaire personateams gaan individuen zich langzaam en zeker identificeren met een (deel van) het product in plaats van met een smalle gespecialiseerde vaardigheid.
  • Consent—Consent of instemming is de atmosfeer van een personateam. Omdat het punt van identificatie eerder het product of een eigenschap van het product is dan de functie, en omdat iedereen zich wederzijds aanspreekbaar voelt voor het product is een bepaalde mate van openheid veilig, nodig zelfs. Consent leidt meestal tot betere oplossingen die zich aandienen dan andere beslismodellen.
  • Balans—Balans bij een personateam gaat over diversiteit in kennis, kunde, vaardigheid, opdrachten en gezichtspunten.

personateams zijn gemeengoed in organisaties die leren om sneller te leveren en hun vaardigheden verbreden. In Nederland is Planon een goed voorbeeld.

De producteigenschap is de natuurlijke eenheid van functionaliteit die je voor je klanten ontwikkelt en levert en is daarmee de ideale taak voor een team. Het personateam is verantwoordelijk is verantwoordelijk voor het vrijgeven van de eigenschap aan de klant binnen een gegeven tijd, budget en kwaliteit. Een personateam dient multi-disciplinair te zijn omdat het alle fases van het ontwikkelproces af moet dekken, van klantcontact tot systeemtest en alle systeemgebieden, over componenten heen, die door die eigenschap geraakt worden.

De dagelijkse bouw (Daily Build) kan alleen volledig geïmplementeerd worden in een organisatie die voornamelijk verantwoordelijkheid neemt voor het ontwerp van eigenschappen voor de klant.

De reden voor verantwoordelijkheid voor producteigenschappen is een eerste vereiste voor het behalen van voordeel van de dagelijkse bouw is de hoeveelheid coördinatie en planning die nodig is tussen degenen die verantwoordelijk zijn om consistente onderdelen van elke module de gebouwd kan worden.

Een personateam handelt al deze coördinatie effectief en efficiënt binnen het team af.

Een personateam zijn ‘verticale’ teams gericht op zakelijke functionaliteit en waardecreatie. personateams leveren ‘verticale’ klantgerichte producteigenschappen, van begin tot eind—GUI, applicatielogica, database, …) in plaats van ‘horizontale’ componenten of de lagen van een spekkoek.

personateams zijn de enige oplossing om klantgerichte waardecreatie altijd in het vizier te hebben.

personateams zijn eerst en vooral stabiele teams en kennen een sterk gematigd tramgetal omdat elk teamlid een generalisatiespecialist is.

Voordelen

  • Meer doorvoersnelheid van waarde—gericht op het leveren van de meest waardevolle zaken voor de klant of markt.
  • Meer zelflerend vermogen—het individuele en teamleren neemt toe vanwege de bredere verantwoordelijkheid en colocatie met collegae die specialisten zijn in een variëteit van gebieden. Dit is van kritisch belang voor verbetering en versnelling op lange termijn.
  • Minder verkwisting door onderbezette mensen—het team voelt zich verantwoordelijk voor het juist opleveren van eerder gemaakte beloftes en helpt elkaar de beloftes na te komen.
  • Makkelijker plannen—door een complete producteigenschap aan het team te geven wordt het organiseren en plannen eenvoudiger—het is niet langer nodig om enkelvoudige specialisten tussen functionele en componententeams te coördineren.
  • Minder verwkisting door overdracht—omdat het gehele personateam in dezelfde ruimte al het werk doet (analyseren, ontwerpen, coderen, testen) is de overdracht enorm verminderd.
  • Snellere cycli door minder wachttijd—de verkwisting door onnodig wachten wordt sterk verminderd omdat overdrachten geëlimineerd zijn en omdat het afmaken van een klantgerichte producteigenschap niet op meerdere partijen, die elk hun werk serieel, doen hoeft te wachten.
  • Zelfregulerend en zelforganiserendpersonateams zijn autonoom en coördinatie is triviaal en hebben daarom geen project manager of matrixmanagement nodig hetgeen resulteert in lagere kosten en hogere efficiency. Het team heeft de volledige verantwoordelijkheid voor het volgens afspraak opleveren van een eindproduct en de coördinatie met anderen.
  • Betere ontwerp- en codekwaliteit—meerdere personateams die aan gedeelde componenten werken creëren de behoefte om de code schoon te houden, volgens standaarden geformatteerd en voortdurend geherstructureerd en omgeven door vele unit tests omdat het anders niet mogelijk is om mee te werken. Componententeams daarentegen leren leven met verduisterde code die alleen zij begrijpen vanwege hun lange vertrouwdheid ermee.
  • Meer zin—teams die zich verantwoordelijk voelen voor een klantklaar eindproduct genieten van meer richting, betekenis, nut en plezier van hun werk en motiveert.
  • Eenvoudige koppelvlakken en coördinatie van modules—één persoon of team moderniseert beide zijden van een koppelvlak (caller en callee) en past de code in alle modules aan. Omdat het personateam over alle componenten heen werkt is coördinatie tussen teams niet nodig.
  • Makkelijker veranderen—Veranderingen in eisen of ontwerp (komt natuurlijk bijna niet voor) worden door één team geabsorbeerd en maken hercoördinatie en herplanning over meerdere teams overbodig.

Componenten zoals lagen (spekkoek, vet platform en klassen blijven natuurlijk bestaan en we streven naar hun sublieme kwaliteit, maar we organiseren de teams niet overeenkomstig.