Een Agile-cultuur binnen uw team promoten

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Naarmate uw team groeit, wilt u dat uw hulpprogramma's ermee groeien. En als u een onderneming bent die Agile-methodologieën aanneemt, wilt u dat uw Agile-hulpprogramma's de bedrijfsdoelen van uw onderneming ondersteunen.

Voor het schalen van Agile is echter zowel de cultuur als de hulpprogramma's binnen uw organisatie vereist.

Notitie

Nieuw bij Agile? Zie Agile Culture and Scaling Agile to Large Teams voor meer informatie.

Autonomie inschakelen

Organisaties die flexibel willen zijn, moeten rekening houden met de dubbele verplichtingen voor het creëren van afstemming in de onderneming en het ondersteunen van teamautonomie. Een team moet autonomie hebben om efficiënt te zijn. En ondernemingen hebben afstemming tussen teams en de organisatie nodig om efficiënt te zijn.

Te veel afstemming met onvoldoende teamautonomie leads biedt geen ondersteuning voor innovatie of flexibiliteit van teams om dingen gedaan te krijgen. Te weinig afstemming met elk team dat een eigen programma uitvoert, biedt niet het inzicht en de coördinatie die nodig is om te voldoen aan bedrijfsdoelen.

Met het juiste niveau van afstemming in de autonomie van de organisatie en het team krijgen personen de mogelijkheid om te innoveren en geïnspireerd om samen te werken om te voldoen aan bedrijfsdoelen.

Uitlijning maken

Houd rekening met de volgende gebieden wanneer u plant hoe u uw Agile-hulpprogrammaset wilt laten groeien. Deze gebieden zijn essentieel voor het creëren van bedrijfsuitlijning tijdens het ontwikkelen van teamautonomie.

Gebied

Uitlijning maken

Autonomie ondersteunen

Productvisie

De organisatie definieert de doelen en roadmap voor de organisatie. U kunt doelen definiëren als epics en functies die worden weergegeven in de achterstand van de portfolio.

Een team bepaalt hoe het beste aan de roadmap kan worden voldaan. Het team breekt doelen op in gebruikersverhalen of productachterstanditems met behulp van hun teamachterstanden.

Teamstructuur

Op basis van bedrijfsdoelen bepalen organisaties het aantal en de grootte van teams. Verticaal gestructureerde functieteams leiden tot meer autonomie en efficiëntie.

Met teams moeten er enkele vaste rollen zijn, zoals producteigenaar en ontwikkelingsleiders, maar ook ruimte om rollen te rouleren. Teamleden kunnen bijvoorbeeld om beurten fungeren als Scrum Master, het ontwikkelen van sprintdemo's, het uitvoeren van sprint retrospectieven of het maken van sprint-e-mails.

Ontwikkelingsritme

Agile-organisaties moeten regelmatig producten en functie-updates vrijgeven. Het opstellen van regelmatige release- en sprintschema's bevordert het ritme van het bedrijf.
Elke sprint, een tijdvakken van herhaling van constante duur tussen twee en vier weken, omvat planning, uitvoering, leveren van waarde, reflectie en continue verbetering.

Alle teams beheren hun werk binnen de set sprintfrequentie. Het team levert input in de lengte van sprints die het beste voor hen werkt.
Het team kiest de Agile-methoden die voor hen werken, Scrum, Kanban of een combinatie van beide. Het team neemt ook het eigendom van het starten en handelen op hun eigen set continue verbeteringsprocedures.
Het is mogelijk dat sommige teams in kortere sprints worden uitgevoerd. Als een organisatie bijvoorbeeld een sprintfrequentie van 2 weken instelt, kunnen sommige teams ervoor kiezen om in sprints van 1 week te werken, terwijl ze nog steeds overeenkomen met de organisatieplanning.

Communicatiefrequentie

Net zoals sprints een natuurlijk ritme aan de werkstroom brengen, dus ook regelmatige communicatie. Door verwachtingen in te stellen voor de typen communicatie die ze willen zien om op elkaar afgestemd te blijven en hoe vaak ze optreden, creëren organisaties natuurlijk afstemming tussen teams en de onderneming.
Team sprint-e-mailberichten, status van bugbalk en status van de bezorging van teamfuncties zijn voorbeelden van dergelijke reguliere communicatie.

Een team bepaalt de details die ze communiceren en wie de communicatie ontwikkelt. Hun sprint-e-mailberichten kunnen een samenvatting bevatten van eerdere sprintprestaties en de volgende sprintplannen of een demo van onlangs voltooide functies bevatten.

kwaliteit

Elke organisatie moet de criteria en standaarden instellen waarmee ze kwaliteit beoordelen en verwachtingen voor kwaliteitsnormen instellen. Een aantal manieren waarop ze de criteria definiëren, zijn het instellen van afsluitcriteria voor nieuwe functieontwikkeling, standaarden voor het beheren van technische schulden en foutlimieten voor teams of personen.
Ze kunnen ook de foutstatus en trends bewaken door bugdashboards te maken.

Een team kiest hoe ze voldoen aan de kwaliteitsnormen. Ze kunnen bug bashes voor nieuwe functies of aan het einde van elke sprint. Ze kunnen een individu kiezen om te functioneren als een bugschild op een roterende basis.

Risico's beheren, werk bijhouden

De organisatie bepaalt hoe elke functionele eenheid status en risico communiceert. Ze stellen een "communicatiecontract" vast met betrekking tot de minimale vereiste informatie die de organisatie nodig heeft.
Daarnaast biedt de organisatie de infrastructuur om risico's te verminderen. De organisatie is de teams alles verschuldigd wat ze kunnen doen om risico's te verminderen die gebruikelijk zijn in verschillende teams.

Naast het voldoen aan de behoeften die door de organisatie zijn ingesteld, bepalen teams alle andere details die ze nodig hebben om hun risico's te beheren en bij te houden. Of ze nu een white board met plaknotities of een volledig Gantt-diagram gebruiken, ze beheren de details. Teams kunnen bijvoorbeeld een achterstandsitem toevoegen om een afhankelijkheid bij te houden die ze hebben voor een ander team. Of ze kunnen hun risico's bijhouden via een lijst met problemen of belemmeringen. Daarnaast dragen teams regelmatig bij aan het verbeteren van het proces en de infrastructuur ter ondersteuning van het vermogen van de organisatie om risico's te beheren en inzichten te verkrijgen.

Teams structuren

Wanneer u schaalt, is een van de belangrijkste taken die u moet overwegen de structuur van uw teams. Normaal gesproken delen horizontale teamstructuren teams op basis van de softwarearchitectuur: gebruikersinterface, servicegerichte architectuur en gegevensteams.

Grafiek met horizontale versus verticale teams.

Met de acceptatie van Agile-procedures bieden verticale teamstructuren die de architectuur omvatten echter meer teamautonomie. Verticale teams kunnen de functies leveren die ze bezitten door in de softwarearchitectuur te werken. Ze verspreiden ook de kennis die nodig is om te werken op alle architectuurniveaus in alle teams.

Configureer uw teams langs de waardestromen die uw organisatie wil leveren. Fabrikam Fiber organiseert bijvoorbeeld hun teams in de volgende zeven functieteams.

Grafiek met zeven functieteams: winkelwagen, klantprofiel, servicestatus, e-mail, spraak, internet en tv

Elk team plant de functies die moeten worden geleverd. Ze hebben de autonomie om te bepalen hoe de gegevens moeten worden gestructuurd, de services moeten worden ontworpen en de web- en mobiele gebruikersinterfaces moeten worden ontworpen. Ze plannen in overeenstemming met de kwaliteitsnormen die zijn vastgesteld door de organisatie en waaraan alle teams bijdragen.

Uw Agile-hulpprogramma's configureren om te schalen

Naarmate uw organisatie groeit, kunt u uw Agile-hulpprogramma's op de volgende manieren schalen.

  • Teams en gefilterde achterstandsweergaven toevoegen: u voegt teams toe om de autonomie van het team te ondersteunen en ze te voorzien van de hulpprogramma's die ze kunnen configureren en beheren die ondersteuning bieden voor hoe ze willen werken. Deze hulpprogramma's omvatten productachterstanden, Kanbanborden, sprintachterstanden, Taskboards en andere.

    U kunt teams ook configureren ter ondersteuning van een hiërarchie van achterstanden en portfolioachterstanden, zodat portfoliobeheerders prioriteit en voortgang in verschillende teams kunnen bekijken.

  • Sprints en releases instellen: u kunt uw iteraties structuren ter ondersteuning van een platte set sprints of een set sprints die zijn ingesloten in geplande releases. Elk team activeert de set sprints en releases waaraan ze moeten deelnemen.

  • Portfolio's beheren: door een hiërarchie van teams en achterstanden in te stellen en portfolioachterstanden te activeren. Functieteams die zijn gericht op een subset van de productachterstand, kunnen zich concentreren op alleen hun achterstand. Portfoliobeheerders die achterstanden willen bekijken en organiseren om de voortgang en afhankelijkheden bij te houden, kunnen portfolioachterstanden van Functies en Epics beheren.

    Als u andere portfolioachterstanden nodig hebt, bijvoorbeeld scenario's of initiatieven, kunt u ze ook toevoegen.

  • Dashboards configureren: Met teamdashboards kunt u grafieken configureren waarmee de voortgang binnen een team of in alle teams wordt bijgehouden. U kunt met name status- en trenddiagrammen toevoegen op basis van query's die u maakt.

  • Werk groeperen of categoriseren: Er zijn verschillende manieren om werk te groeperen dat u wilt bijhouden. Achterstallen filteren werkitems op basis van teamgebiedtoewijzingen. Met portfolioachterstanden kunt u achterstallige items onder Functies en Epics groeperen.

    Als u werkitems wilt bijhouden en rapporteren op basis van andere groeperingen, kunt u dat doen. U kunt tags toevoegen aan werkitems en vervolgens backlogs of query's filteren op basis van tags. U kunt ook subgebiedpaden toevoegen om meer gedetailleerde functiegebieden weer te geven.

  • Voeg mappen toe en gebruik teamfavorieten: naarmate uw teams groeien, ziet u een groeiende lijst met werkitemquery's, builddefinities en broncodemappen. Door mappen, submappen en teamfavorieten te gebruiken, kunt u veel van deze lijsten eenvoudiger beheren. U kunt teamfavorieten toevoegen voor gedeelde query's, broncode en builddefinities.

Schalen met teams en niet met projecten

Organisaties kijken vaak naar het toevoegen van een project voor elk softwareontwikkelingsproject.

We raden u aan teams toe te voegen om uw hulpprogramma's te schalen in plaats van om de volgende redenen projecten toe te voegen:

  • Zichtbaarheid: het is eenvoudiger om de voortgang in alle teams weer te geven
  • Bijhouden en controleren: het is eenvoudiger om werkitems te koppelen aan andere objecten voor tracerings- en controledoeleinden
  • Onderhoudbaarheid: u minimaliseert het onderhoud van beveiligingsgroepen en procesupdates.

Zie Over projecten en het schalen van uw organisatie voor meer informatie.

Voordat u een van de Agile-hulpprogramma's kunt maken of ermee kunt werken, hebt u een project nodig. Als u er nog geen hebt, kunt u er een maken.

Als u klaar bent om van één team naar twee teams te gaan of meerdere teams te configureren, raadpleegt u Teams toevoegen. Zie Teams beheren en teamhulpprogramma's configureren om een teambeheerder toe te voegen of teamassets te configureren.

Lees deze artikelen voor meer informatie:

Resources voor de flexibele cultuurindustrie