Share via

Agile-procedures implementeren die worden geschaald

  • Artikel

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

Enterprise-organisaties gebruiken Agile-procedures om verschillende redenen. Een van de volgende redenen zijn onder andere:

  • Verkort de time-to-market, versnel productlevering
  • De effectiviteit van de organisatie verbeteren om veranderende prioriteiten te beheren
  • Softwarekwaliteit en leverings voorspelbaarheid verbeteren
  • Zichtbaarheid van projecten verbeteren en projectrisico's verminderen

Naarmate uw organisatie groeit, wilt u uw procedures schalen om flexibel te blijven en te voldoen aan veranderende doelen. Houd hiervoor rekening met de volgende twee leidende principes:

  • Hoe ziet succes eruit voor u, uw teams en uw organisatie? Wat is het meest interessant: Tijdige levering? Productkwaliteit? Voorspelbaarheid? Klanttevredenheid?
  • Ga terug naar de eerste principes, ga terug naar de principes en gedeelde waarden die zijn geïnventariseerd in het Agile-manifest , zoals vermeld door Ken Stichtener, een van de oprichters van Scrum:
    • "Waarden en principes schalen, maar procedures zijn contextgevoelig."
    • "Houd de waarden, houd de principes, denk voor jezelf. Een kernonderdeel van Agile is dat de mensen die het werk doen de mensen zijn die het beste kunnen uitzoeken hoe ze het kunnen doen."

Ritme en stroom maken

Door gebruik te maken van een gedeelde frequentie en een set periodieke communicaties, maakt u een constante activiteitsstroom in de hele organisatie. Procedures voor het creëren van ritme en stroom binnen grotere organisaties zijn onder andere:

  • Gedeelde frequentie: regelmatige sprints en releases zorgen voor het ritme van het bedrijf. Het werken met alle teams aan een gedeelde frequentie helpt bij alle coördinatie- en samenwerkingsactiviteiten.
  • Sprint-e-mailberichten: Als u de organisatie en alle teams op de hoogte wilt houden van de voortgang en plannen van functieteams, kan elk functieteam een samenvatting van de vorige sprintresultaten en huidige sprintplannen per e-mail verzenden.
  • Sprint demo's: Een snelle video van 2 tot 3 minuten die een nieuwe functie illustreert die het team heeft geproduceerd. Koppelingen naar dergelijke video's kunnen worden opgenomen in sprint-e-mailberichten.
  • Vergaderingen presenteren: Om andere teams te informeren en feedback te vragen over software die in ontwikkeling is, laten teams het werk zien dat ze hebben gedaan. Voer deze vergaderingen regelmatig uit gedurende de levenscyclus van het project en open ze voor alle belanghebbenden.
  • E-mailberichten met een foutoverzicht: ter ondersteuning van inzicht in de productkwaliteit en om het onderhouden van bugdiscipline te stimuleren, deelt u regelmatig metrische gegevens over de kwaliteit met de organisatie. Deze metrische gegevens kunnen actieve bugs per functieteam, bugtrends en bugs per engineer omvatten.
  • Coördinatievergaderingen: houd vergaderingen die teams regelmatig coördineren of zo vaak als nodig is om overlappende doelen, afhankelijkheden en risico's aan te pakken.

Interactie met klanten

Klanten betrekken tijdens uw productlevenscyclus is een primair Agile-principe. Elk team in staat stellen om rechtstreeks met klanten te communiceren op de functiesets die ze bezitten.

  • Doorlopende feedback: bouwen in feedbacklussen van klanten. Deze lussen kunnen vele vormen aannemen:
    • Stem van de klant: maak het eenvoudig voor klanten om feedback te geven, ideeën toe te voegen en te stemmen op functies van de volgende generatie. Het geven van feedback wordt vaak gedaan via een speciale website.
    • Productfeedback: Feedbackknoppen in product zijn een andere manier om feedback te vragen over de productervaring of specifieke functies.
    • Klantdemo's: Regelmatig geplande demo's die vragen om feedback van uw klanten, kunnen helpen bij het vormgeven van producten van de volgende generatie en u op weg houden om toepassingen te bouwen die uw klanten willen gebruiken.
  • Vroege adopterprogramma's: dergelijke programma's moeten worden ontwikkeld met het idee dat alle teams op een bepaald moment willen deelnemen. Early adopters krijgen toegang tot vroege versies van werkende software, die ze vervolgens feedback kunnen geven. Deze programma's werken vaak door bepaalde functievlagmen in te schakelen voor een early adopter-lijst.
  • Gegevensgestuurde beslissingen: zoek manieren om uw product te instrumenteren om nuttige gegevens te verkrijgen en die verschillende hypothesen kunnen testen. Help bij het stimuleren van een experimentvriendelijke cultuur die het leren viert.

Zichtbaarheid van projecten verbeteren

Hoe meer inzicht u en uw teams hebben in het doel, de visie en de voortgang van het werk dat wordt uitgevoerd, hoe beter u de risico's kunt verminderen en afhankelijkheden kunt beheren.

  • Teamstructuur: Ongeacht hoe groot uw organisatie wordt, het structureren van uw organisatie rond kleine teams van 6 tot 9 schaalaanpassingen. Maak verticale, autonome functieteams gegroepeerd onder portfoliobeheergebieden.
  • Structuur voor uitsplitsing van werk: het opsplitsen van grote doelen, functies of vereisten in kleinere blijft een stabiele structuur van projectmanagement. Door werk op te splitsen in taken van vergelijkbare grootte, kunnen teams betere schattingen maken en risico's en afhankelijkheden identificeren.
  • Geconsolideerde weergaven: gebruik uw hulpprogramma's voor onlinetracking om werk samen te voegen om kennis te krijgen tussen teams. Maak dashboards om voortgang en trends weer te geven.
  • Ervaringsbeoordelingen: Deze vergaderingen, gehouden voordat de ontwikkeling begint met een functie, worden gebruikt om leiderschap te informeren over scenario's en prioriteiten, feedback te verzamelen, verwachtingen in te stellen en eventuele problemen tussen teams over de functie op te lossen.

Een productief personeel in staat stellen

Enkele specifieke Agile-procedures die goed worden geschaald en leiden tot gelukkigere, betrokken en productieve werknemers zijn onder andere:

  • Ingesloten leiderschap: Teams en leiders binnen de organisatie in staat stellen zoveel mogelijk zelf te organiseren en zelf te beheren. De autonomie van het team verhoogt de effectiviteit van het organisatieflexibiliteitsteam. Zorg ervoor dat teams beschikken over de corporate sponsorship die nodig is om te slagen.
  • Dagelijkse stand-ups: Of Scrum-vergaderingen helpen teams gefocust te houden op wat ze dagelijks moeten doen om hun sprintverplichtingen te maximaliseren. Naarmate organisaties groeien, moeten ze overwegen om deze vergaderingen te staken, zodat deelname tussen teams waar nodig kan plaatsvinden.
  • Scrum van scrums: dagelijkse stand-ups van leden van verschillende Agile-teams komen dagelijks bijeen om voltooid werk, volgende stappen en problemen of blokken binnen hun representatieve teams te rapporteren.
  • Teamcommunicatie: Geef teams en moedig ze aan om hun procedures en richtlijnen te delen, waartoe ze en andere teams toegang hebben via het bedrijfsnetwerk. Veelgebruikte hulpprogramma's die voor dit doel worden gebruikt, zijn teamwiki's, OneNotes of Markdown-sites.
  • Samenwerking: moedig informele communicatie tussen teams en samenwerking binnen het team aan. Het institutionaliseren van procedures zoals codebeoordelingen, ontwerpbeoordelingen, specificatiebeoordelingen vergroten niet alleen de samenwerking van teams, maar helpen bij het ontwikkelen van individuele en algemene bedrijfscompetenties.

Organisatiecultuur verbeteren

U verbetert de effectiviteit van de organisatie door deel te nemen aan de cultuur die u wilt bouwen. Cultuurwijzigingen treden op wanneer individuen, teams en organisaties een of meer continue verbeteringspraktijken aannemen. Enkele schaalbare Agile-procedures zijn:

  • Retrospectieven: Door vragen te stellen zoals: "Wat is er goed gegaan?", "Wat moeten we anders doen?", en "Wat moeten we stoppen?" helpen teams te weerspiegelen hoe ze hun processen en procedures kunnen verbeteren. Retrospectieven helpen teams om te ontdekken wat goed werkt en wat verbetering nodig heeft. Retrospectieven kunnen altijd en overal worden uitgevoerd. Het institutionaliseren van bepaalde retrospectieven op regelmatige frequentie helpt echter bij het institutionaliseren van continue verbeteringspraktijken. Voorbeeld:

    • Sprint retrospectieven kunnen teams helpen om gebieden te identificeren die regelmatig moeten worden verbeterd.

    • Release retrospectieven kunnen organisaties helpen bij het identificeren van gebieden om communicatie en interne praktijken en brandstofverbetering voor de volgende release te verbeteren.

    • Operationele beoordelingen: worden doorgaans maandelijks gehouden en bevatten vertegenwoordigers uit een hele waardestroom. Een portfolio van projecten en andere initiatieven beslaat en objectieve, kwantitatieve gegevens gebruikt, ontwerpt deze retrospectieven om discussies te veroorzaken over de dynamiek die van invloed is op de prestaties tussen teams.

      Zie de Agile Retrospectievenwiki voor ideeën, tips en hulpprogramma's voor het plannen en uitvoeren van retrospectieven. Zie ook de extensie Marketplace Retrospectieven.

  • Verbeteringsregistratiebord: Goede ideeën voor het verbeteren van processen kunnen op elk gewenst moment ontstaan. Het vastleggen van deze ideeën om deze ideeën te bespreken en te bepalen hoe ze snel kunnen worden uitgevoerd, is een sleutel voor het ondersteunen van procesverbeteringsinspanningen.

    Een white board biedt eenvoudige en visuele middelen waarmee ideeën kunnen worden vastgelegd. U kunt ook een verbeteringsteam maken en ideeën vastleggen die u op een elektronisch Kanbanbord bijhoudt.

  • Delen institutionaliseren: het delen van best practices en het communiceren van ideeën helpt alle teams binnen een organisatie te groeien en te verbeteren. Het ontwikkelen van een leercultuur is essentieel voor het ondersteunen van deze en andere continue verbeteringsactiviteiten. Enkele ideeën die u moet overwegen:

    • Interne wiki's

    • Interne distributielijsten

    • Hackathon weken of 10% hacktijd

    • Intern Agile-ondersteuningsteam ter ondersteuning van teams die Agile-procedures aannemen

      De Culture Game biedt een goede resource voor Agile-managers om teams te helpen agile te gebruiken en best practices te delen.

  • Community's van de praktijk: interne gemeenschappelijke disciplines ondersteunen (bijvoorbeeld DBA's, SW Architecten, UX-ontwerp)

Werksoftware

"Werksoftware regelmatig leveren, van een paar weken tot een paar maanden, met een voorkeur voor de kortere tijdschaal."
"Werkende software is de primaire maat voor de voortgang."
- Agile-manifest

Naarmate de hoeveelheid software, functies en complexiteit toeneemt, moet u procedures gebruiken die u helpen bij het produceren van verbruiksoplossingen.

  • Functievlagmen: gebruik functievlagmen om de toegang tot verschillende functies in of uit te schakelen. Ondersteuning bieden voor het inschakelen van functies aan early adopters om feedback te krijgen.
  • Releasetreinen: Geef een ander type frequentie op om een of meer functies te leveren. Functieteams begrijpen het vooraf geplande schema voor het pushen van nieuwe functies en plannen correct. Releasetreinen kunnen overeenkomen met hetzelfde sprintritme dat voor de organisatie is vastgesteld of zich in een ander tempo voordoen. Zie Scaled Agile Framework voor het instellen van sprints en het vrijgeven van treinen.
  • Continue integratie: Gebruik processen die handmatig werk elimineren en automatiseer in plaats daarvan de stroom van software via de cycli testen, bouwen en implementeren.
  • Interne open source: breng de waarde en ethos die is ontwikkeld in de Open Source Software-community naar uw interne ontwikkelteams.

Naast de bovenstaande procedures vindt u meer richtlijnen voor het schalen van uw Agile-hulpprogramma's in de volgende artikelen:

Industriebronnen

Procedures die niet worden geschaald

  • Grote initiatieven schatten: Een deel van de watervalprojectmethoden is betrokken bij het schatten van resources en planningen. Hoe groter de initiatieven, hoe minder waarschijnlijk deze schattingen een waarde hebben. Naarmate projecten groeien, kunnen risico's en onvoorziene problemen en belemmeringen ontstaan, waarbij veel schattingen ongeldig worden.
  • Snelheid: hoewel teamsnelheid een nuttige metriek kan bieden om inzicht te krijgen in hoeveel werk elk team tijdens een sprintcyclus kan voltooien, kunt u geen teamsnelheden toevoegen om zinvolle of nuttige metrische gegevens te verkrijgen. Bovendien is het gebruik van snelheid die is opgedaan van veel teams om betrouwbare langetermijnprognoses te voltooien problematisch. Teams variëren op de manier waarop ze hun werk schatten en deze variaties nemen in de loop van de tijd toe.
  • Top-down prescriptieve oplossingen: Één grootte past niet op alle, en één oplossing past doorgaans niet bij alle teams. Het ondersteunen van teamautonoom betekent dat teams hun eigen oplossingen kunnen vinden.