Agile vergemakkelijkt veranderingsbeheer bij de overheid

Geplaatst op 1 maart 2022 in Digitale transformatie van de overheid

Is agile het wondermiddel voor het succes van overheidsprojecten? Wij zijn voorstanders van agile vanwege de verbeterde succespercentages met behulp van agile productontwikkeling, agile projectmanagement en agile landontwikkeling. Onze methodologie, A-i³+qM is gebaseerd op bewezen goede praktijken en bijna 40 jaar exclusieve overheidsimplementaties.

Hoe is Veranderingsmanagement gerelateerd aan de Agile Methode?

Agile technieken, indien aangepast aan de overheid, integreren verandering. Voorbij software veranderingsmanagement naar echte organisatorische verandering. Planning van overheidsmiddelen (GRP) software wordt geconfigureerd om effectief aan de reële eisen te voldoen.

Wanneer het goed wordt toegepast, betrekt agile belanghebbenden vroeg en vaak. Weerstand tegen verandering verdwijnt naarmate problemen worden aangepakt en vooruitgang wordt bewezen. Zoals Jason Little opmerkt, "Agile gaat niet over "Agile", het gaat over verandering“.

Beheer van veranderingen bij de overheid is bijzonder belangrijk bij de invoering van nieuwe financiële, personeels-, aanbestedings- of prestatiesystemen. In de Cynefin-kader (schema hierboven), is de uitvoering van het GRP meer dan technisch. Het is niet eenvoudig, ook al hopen velen dat de regeringen "beste praktijken". Veel van deze praktijken zijn ongepast voor de toenmalige overheidscontext.

En een GRP implementeren is veel meer dan alleen een software change management project. Het is transformationeel. Er moeten juridische hervormingen, nieuwe processen, reorganisaties en nieuwe prestatiemetingen plaatsvinden.

Het doel van de implementatie van GRP is de ondersteuning van goede praktijkenwaardoor de uitvoering ingewikkeld wordt. De realiteit is dat implementaties complex worden, soms chaotisch, vanwege de unieke beperkingen van de publieke sector:

• Belanghebbenden gaan verder dan de overheid en zijn ook burgers
• Capaciteit en stimulansen van de openbare dienst
• Politiek, politiek en nog eens politiek

Hoe is veranderingsmanagement geïntegreerd in Agile?

Hoewel er talrijke agile technieken zijn (zie glossarium hieronder), organisatorisch veranderingsmanagement in de publieke sector is impliciet sinds de oprichting van de Agile Manifest. De waarden van het Manifest laten zien hoe mensen, samenwerking en flexibiliteit voorop staan.

• Individuen en interacties boven processen en instrumenten: frequente interactie met belanghebbenden en gebruikers vermindert de weerstand tegen verandering en vergroot de kans dat de echte behoeften worden aangepakt (Een agile principe: "mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het hele project").
• Werkende software over uitgebreide documentatie: documentatie leidt niet tot een gedeeld begrip met belanghebbenden en gebruikers - vertraagt vaak implementaties waardoor tijd ontstaat voor weerstand tegen verandering te verhogen (Een agile principe: "de meest efficiënte en effectieve methode om informatie over te brengen aan en binnen een ontwikkelingsteam is face-to-face conversatie").
• Samenwerking met de klant in plaats van contractonderhandelingen: samenwerking geeft belanghebbenden en gebruikers een stem
• Reageren op verandering boven het volgen van een plan: context wordt geleerd door gesprekken, niet door rigide planning

Hoe je Agile Change Management in de overheid goed aanpakt

Agile werkt goed wanneer vertrouwen wordt mogelijk gemaakt en aangemoedigd. Agile maakt verandermanagement bij de overheid mogelijk, mits goed gemanaged:

• Overwegingagile technieken zoals Design Thinking en PDIA moedigen empathie en begrip van problemen vanuit het perspectief van belanghebbenden en gebruikers aan.
  • IMPACT: belanghebbenden en gebruikers beseffen dat systemen niet door buitenstaanders worden opgelegd
• Klantgerichtagile werkt vanuit de klant naar buiten (wat we in productmanagement "outside-in" noemen) in plaats van product naar binnen (wat we in productmanagement "inside-out" noemen).
  • IMPACT: de angsten en aspiraties van belanghebbenden en gebruikers worden in de projecten verankerd.
• Communicatie: constante communicatie houdt belanghebbenden en gebruikers op de hoogte door middel van borden en andere visuele communicatiemethoden om beslissingen, vooruitgang en achterstanden aan te tonen
  • IMPACT: belanghebbenden en gebruikers zijn minder geneigd zich het ergste voor te stellen tussen mijlpalen, wanneer de vooruitgang zichtbaar wordt gecommuniceerd.
• Gesprek: face-to-face gesprekken met belanghebbenden en gebruikers, waaronder workshops, brainstormsessies en storyboards
  • IMPACT: belanghebbenden en gebruikers erkennen de mogelijkheid om de projectresultaten aan te passen terwijl ze meer leren over de waarde van het project voor hen, hun organisatie en hun land om de aanvaarding van de verandering te vergroten.
• Context: de context van land en overheid wordt begrepen door projectteams (en FreeBalance heeft instrumenten om dit proces mogelijk te maken).
  • IMPACT: het gedeelde begrip onder de deelnemers wordt vergroot om de weerstand tegen verandering te verminderen.
• Samenwerking: projectteams, belanghebbenden en gebruikers werken samen om prioriteiten te stellen, problemen op te lossen en oplossingen te bespreken.
  • IMPACT: invloed op het project door betrokkenheid verhoogt de aanvaarding van de verandering
• Creativiteit: de creativiteit van belanghebbenden en gebruikers benutten om problemen beter op te lossen
  • IMPACT: belanghebbenden helpen problemen op te lossen, inclusief veranderingsproblemen
• Bevestigingsamenwerking geeft deelnemers bevestiging van projectprioriteiten gedurende het hele project in plaats van ondertekening bij belangrijke mijlpalen als enige weg.
  • IMPACT: Projectvertragingen worden beperkt door iteratieve bevestiging, waardoor er weinig tijd is voor weerstand tegen verandering, terwijl feedback-lussen de zorgen van belanghebbenden en gebruikers valideren.
• Capaciteit: tijdens gesprekken en samenwerking opgebouwde capaciteit in het overheidsdomein voor projecten en bestuur als mentor, ter aanvulling van de opleiding en ter verbetering van het projectsucces
  • IMPACT: houdt het veranderingstraject van de organisatie ook na het project in stand (en maakt het project duurzamer)

Waarom verzetten overheden zich tegen Agile Change Management?

Sommige overheidsklanten vragen waarom wij niet-experts betrekken bij het ontwerpen van oplossingen. Demonstraties blijken de beste aanpak te zijn om de impact van agile te communiceren om de besluitvorming en het beheer van organisatorische veranderingen in de publieke sector te verbeteren. Naast het gebruik van agile voor implementatieshebben we agile oefeningen gebruikt op onze jaarlijkse Internationale stuurgroep FreeBalance (FISC), veranderingsworkshops en landencontextoefeningen.

De verandering in de houding van de ambtenaren is begrijpelijk. Eerst achterdocht. Misschien een beetje verwarring. Dan samenwerking en gesprek. Het komt zover dat elke werkgroep bevindingen wil presenteren aan de workshop. Echte samenwerking.

Wat is het proces van organisatorisch veranderingsmanagement?

Traditionele organisatorische veranderingsmanagementprocessen neigen naar een lineaire opeenvolging zoals beschreven door de 5 I's:

1. Inwijding
2. Onderzoek
3. Intentie
4. Inleiding
5. Uitvoering
6. Integratie

Een andere aanpak, ontworpen door John Kotter:

Dit zijn uitstekende kaders voor organisatorische verandering. De lineaire benadering lijkt echter aan te sluiten bij de traditionele waterval benaderingen. Net zoals agile kan worden afgestemd op de CMMi- en ISO-normen, is er geen reden waarom deze benaderingen niet kunnen worden benut. iteratief. Iteratie kan de resultaten van verandering verbeteren, net zoals de succespercentages van softwareontwikkeling en projectbeheer verbeteren door agile.

Wij hebben enkele projecten gezien waarbij organisatorisch veranderingsmanagement bij de overheid werd beschouwd als een aanvulling op projectmanagement. Dit resulteert vaak in "drive-by" en ineffectief veranderingsmanagement.
Het is zinvol om veranderingsdeskundigen bij projecten te hebben. Er is vaak een breuk wanneer veranderexperts domeinexpertise missen. Het is dus effectiever om verandering integraal in projecten te hebben. Om projectmedewerkers verandering en geloofwaardigheid te laten opbouwen.

Wat zijn de voordelen van Agile Change Management bij de overheid?

Reed Deshler ziet de behoefte aan een real-time benadering voor veranderingsbeheer in agile projecten. Dit omvat het aanpassen van begrepen veranderingsbeheerprocessen om ze "geschikt te maken voor het doel" van individuele projecten. Een studie van Prosci analyseerde verandermanagementpraktijken in agile projecten. De analyse vond dat succesvol veranderingsmanagement in agile projecten vereist:

• Iteratieve benaderingen in plaats van lineaire
  • OPMERKING: alle projectonderdelen zijn iteratief in agile, en de impact van veranderingsmanagement is continu om veranderingsacceptatie op te bouwen.
• Veranderingsplannen voor aanpassing
  • OBSERVATIE: wijzigingsplannen moeten veranderen naarmate projectdeelnemers meer te weten komen over de context via gesprekken en samenwerking - beschouw dit als aanpassing aan feedback ziet er zo uit
• Vereist meer tijd vooraf
  • OPMERKING: agile biedt het communicatiekader voor verandering om de planning te vergemakkelijken, terwijl meer veranderingsplanning tot stand komt door minder projectplanning en documentatie - waar veranderingsmanagement een hogere prioriteit krijgt.

Onze ervaring met agile in de echte wereld is dat het het soort quick wins genereert die nodig zijn om de buy-in van de verandering te behouden. Agile biedt zichtbare stappen tussen de quick wins dankzij betrokkenheid, flexibiliteit en prototyping. Wij hebben geprofiteerd van het productontwerp van de FreeBalance Accountability Suite™ dankzij configuratiemethoden waarmee bedrijfsregels en configuratie in workshops kunnen worden bevestigd. Dit maakt het soort agile ontwikkeling mogelijk dat niet beschikbaar is in volledig aangepaste overheidssoftware of zwaar aangepaste software uit de particuliere sector, zoals Enterprise Resource Planning (ERP).

PDIA-aanpak van agile veranderingsmanagement bij de overheid

Zoals eerder beschreven, is de context van organisatieveranderingsmanagement meestal meer complex bij de overheid dan in het bedrijfsleven. Probleemgestuurde iteratieve aanpassing (PDIA), een ontwikkelingsmethodologie voor de openbare sector en een uitstekend instrument voor veranderingsbeheer, pakt deze complexe uitdaging aan. PDIA wordt steeds meer geaccepteerd in het kader van goed bestuur en land ontwikkelingsgemeenschap.

PDIA is ontwikkeld door de Building State Capacity faciliteit van de Harvard Kennedy School of Government. Dit is veel meer dan een academische oefening met talrijke casestudies in de echte wereld. Het maakt deel uit van de Ontwikkeling anders doen beweging. Wij zijn grote fans van PDIA. Veel van onze leidinggevenden hebben Executive Education voor PDIA gevolgd. Veel van onze medewerkers hebben online PDIA cursussen gevolgd.

PDIA geeft prioriteit aan verandering en overtuiging, maakt het in kaart brengen van rollen en communicatiestrategieën mogelijk. Het in kaart brengen van belanghebbenden, communicatie en samenwerking is in PDIA ingebouwd.

PDIA maakt het mogelijk de veranderingsruimte: de overlapping van autoriteit, bekwaamheid en aanvaarding. Dit is een bijzonder sterke techniek voor veranderingsmanagement. Zoals beschreven in de Manifest Ontwikkeling Anders Doen: succes is te danken aan legitimering "op alle niveaus (politiek, bestuurlijk en sociaal), het opbouwen van eigenaarschap en momentum gedurende het hele proces om in werkelijkheid 'lokaal eigendom' te zijn (niet alleen op papier)".

PDIA erkent dat substantiële verandering niet afhangt van de heldhaftige leider. Succesvolle verandering in de publieke sector komt van vele leiders. Dit zijn agenten. Dit gaat verder dan de traditionele benadering van change agents naar scaling agents. Geschaalde verandering wordt gepresenteerd met een sneeuwvlok metafoor.

Wat is de FreeBalance Agile Methodologie?

Onze methodologie is in de loop der jaren geëvolueerd. De huidige versie is A-i³+qM (versneld, geïntegreerd, iteratief, uitvoeringsgericht, kwaliteitsbeheer):

• Versneld door zoveel mogelijk oude watervalprocessen die tot projectproblemen leiden te elimineren. Dit omvat onnodige documentatie en gedetailleerde projectplannen, ten gunste van workshops en korte processtappen. De teamgrootte wordt klein gehouden om communicatie met de klant mogelijk te maken en coördinatieoverhead te verminderen.
• Geïntegreerd via één enkele methodologie ter ondersteuning van de ontwikkeling en de implementatie van diensten. Dit wordt geïntegreerd met de eisen van de klant via de klantgerichte processen. Dit zorgt voor transparantie tussen de klantmedewerkers, de uitvoerders en het ontwikkelingsteam. Implementatie- en productontwikkelingsteams zijn geïntegreerd volgens DevOps-praktijken.
• Iteratief om in te spelen op veranderingen van de klant en de implementatie door middel van fasen. De methodologie maakt gebruik van het beste van bewezen "lean" softwareontwikkeling en dienstenmethodologieën met workshops, korte iteraties, user stories, mijlpalen en de mogelijkheid om vooruitgang aan te tonen. Deze technieken worden uitgebreid tot buiten de ontwikkelingsorganisatie voor implementatiediensten, waardoor de productiviteitswinst en het vermogen om te reageren op de eisen van de klant worden vergroot.
• Uitvoeringsgericht met goede praktijksjablonen en bewezen programmamanagementprocessen. Deze methodologie is gericht op het succes van de klantimplementatie, eerder dan op een softwarerelease die interne of willekeurige doelstellingen bereikt. Implementatie en productontwikkeling worden beheerd via een Program Management Office.
• Kwaliteit aanpak zorgt ervoor dat de software wordt vrijgegeven en ondersteund volgens de goede praktijken van Commercial Off-the-Shelf (COTS) met unit-, systeem-, stress- en regressietests. Kwaliteit is geïntegreerd met implementatie waarbij FreeBalance test op basis van klantomgevingen.

A-i³+qM erkent de tekortkomingen van traditionele projectmanagementprocessen bij GRP implementaties. En, de patronen van mislukking.

Agile Woordenlijst

Alle definities, behalve PDIA, via wikipedia.org.

• Adaptieve softwareontwikkeling (ASD) is een softwareontwikkelingsproces dat is voortgekomen uit het werk van Jim Highsmith en Sam Bayer over snelle applicatieontwikkeling (RAD). Het belichaamt het principe dat voortdurende aanpassing van het proces aan het werk de normale gang van zaken is.
• Agile softwareontwikkeling is een benadering van softwareontwikkeling waarbij eisen en oplossingen zich ontwikkelen door de gezamenlijke inspanning van zelforganiserende en cross-functionele teams en hun klant(en)/eindgebruiker(s).[1] Het pleit voor adaptieve planning, evolutionaire ontwikkeling, vroege levering, en voortdurende verbetering, en het moedigt snelle en flexibele reactie op verandering aan.
• Ontwerpend denken verwijst naar de cognitieve, strategische en praktische processen waarmee ontwerpconcepten (voorstellen voor nieuwe producten, gebouwen, machines, enz.) worden ontwikkeld door ontwerpers en/of ontwerpteams. Veel van de belangrijkste concepten en aspecten van design thinking zijn geïdentificeerd via studies, op verschillende ontwerpgebieden, van ontwerpcognitie en ontwerpactiviteit in zowel laboratorium- als natuurlijke contexten.
• DevOps is een reeks softwareontwikkelingspraktijken die softwareontwikkeling (Dev) en IT-operaties (Ops) combineert om de levenscyclus van systeemontwikkeling te verkorten en tegelijkertijd regelmatig functies, fixes en updates te leveren die nauw aansluiten bij de bedrijfsdoelstellingen.
• Gedisciplineerde agile levering (DAD) is een raamwerk voor procesbeslissingen dat vereenvoudigde procesbeslissingen mogelijk maakt rond incrementele en iteratieve oplossingen. DAD bouwt voort op de vele praktijken van voorstanders van agile softwareontwikkeling, waaronder Scrum, agile modelling, lean software development, en andere.
• Dynamische systeemontwikkelingsmethode (DSDM) is een agile raamwerk voor projectoplevering, aanvankelijk gebruikt als een softwareontwikkelingsmethode.
• Extreem programmeren (XP) is een softwareontwikkelingsmethode die bedoeld is om de kwaliteit van software te verbeteren en beter in te spelen op veranderende eisen van de klant. Als een vorm van agile softwareontwikkeling wordt gepleit voor frequente "releases" in korte ontwikkelingscycli, die bedoeld zijn om de productiviteit te verbeteren en controlepunten in te voeren waarop nieuwe eisen van de klant kunnen worden overgenomen.
• Functiegerichte ontwikkeling (FDD) is een iteratief en incrementeel softwareontwikkelingsproces. Het is een lichtgewicht of Agile methode voor het ontwikkelen van software.
• Iteratieve en incrementele ontwikkeling is elke combinatie van zowel een iteratief ontwerp als een iteratieve methode en een incrementeel bouwmodel voor ontwikkeling.
• Kanban (Japans 看板, uithangbord of billboard) is een slanke methode om het werk in menselijke systemen te beheren en te verbeteren. Deze benadering beoogt werk te beheren door de vraag in evenwicht te brengen met de beschikbare capaciteit, en door de aanpak van knelpunten op systeemniveau te verbeteren.
• Lean software ontwikkeling is een vertaling van lean manufacturing principes en praktijken naar het softwareontwikkelingsdomein. Aangepast aan het Toyota Productiesysteem, is het in opkomst met de steun van een pro-lean subcultuur binnen de Agile gemeenschap. Lean biedt een solide conceptueel kader, waarden en principes, evenals goede praktijken, afgeleid van ervaring, die agile organisaties ondersteunen.
• Grootschalige Scrum (LeSS) is een raamwerk voor productontwikkeling dat Scrum uitbreidt met schaalregels en richtlijnen zonder de oorspronkelijke doelstellingen van Scrum te verliezen.
• Modelgedreven engineering (MDE) is een softwareontwikkelingsmethode die zich richt op het creëren en exploiteren van domeinmodellen, die conceptuele modellen zijn van alle onderwerpen die verband houden met een specifiek probleem. Het gaat dus om abstracte representaties van de kennis en activiteiten die een bepaald toepassingsdomein beheersen, en niet zozeer om computerconcepten (d.w.z. algoritmen).
• Microsoft Oplossingen Kader (MSF) is een reeks principes, modellen, disciplines, concepten en richtlijnen voor het leveren van informatietechnologische diensten van Microsoft. MSF is niet beperkt tot het ontwikkelen van applicaties alleen; het is ook van toepassing op andere IT-projecten zoals implementatie-, netwerk- of infrastructuurprojecten. MSF dwingt de ontwikkelaar niet om een specifieke methodologie te gebruiken (zoals het watervalmodel of agile softwareontwikkeling).
• De Persoonlijk softwareproces (PSP) is een gestructureerd softwareontwikkelingsproces dat is bedoeld (gepland) om software-ingenieurs te helpen hun prestaties beter te begrijpen en te verbeteren door discipline aan te brengen in de manier waarop zij software ontwikkelen en hun voorspelde en feitelijke ontwikkeling van de code bij te houden. Het laat ontwikkelaars duidelijk zien hoe ze de kwaliteit van hun producten kunnen beheren, hoe ze een degelijk plan kunnen maken en hoe ze toezeggingen kunnen doen. Het biedt hen ook de gegevens om hun plannen te rechtvaardigen.
• Probleemgestuurde iteratieve aanpassing (PDIA) is een proces van gefaciliteerde opkomst dat gericht is op problemen (geen oplossingen) en een stapsgewijs proces volgt (geen rigide plan) dat flexibel leren en aanpassen mogelijk maakt, ontworpen door de Building State Capacity faciliteit van de Harvard Kennedy School of Government.
• Snelle ontwikkeling van toepassingen (RAD), ook wel Rapid-application building (RAB) genoemd, is zowel een algemene term, gebruikt om te verwijzen naar adaptieve benaderingen van softwareontwikkeling, als de naam voor James Martin's benadering van snelle ontwikkeling. In het algemeen leggen RAD-benaderingen van softwareontwikkeling minder nadruk op planning en meer op een adaptief proces. Prototypes worden vaak gebruikt naast of soms zelfs in plaats van ontwerpspecificaties.
• De Rationeel verenigd proces (RUP) is een iteratief proceskader voor softwareontwikkeling, sinds 2003 gecreëerd door de Rational Software Corporation, een divisie van IBM.[1] RUP is niet één concreet voorschrijvend proces, maar eerder een aanpasbaar proceskader, bedoeld om te worden aangepast door de ontwikkelingsorganisaties en softwareprojectteams die de elementen van het proces selecteren die passen bij hun behoeften. RUP is een specifieke implementatie van het Unified Process.
• De Geschaald Agile Framework (afgekort als SAFe), is een set van organisatie- en werkstroompatronen bedoeld om bedrijven te begeleiden bij het schalen van lean en agile praktijken. Samen met grootschalige Scrum (LeSS), gedisciplineerde agile levering (DAD), en Nexus, is SAFe een van een groeiend aantal raamwerken die trachten de problemen aan te pakken die zich voordoen bij het schalen voorbij een enkel team.
• Scrum is een agile kader voor het managen van kenniswerk, met de nadruk op softwareontwikkeling, hoewel het ook op andere terreinen breed wordt toegepast en langzaamaan ook door traditionele projectteams in het algemeen wordt verkend. Het is ontworpen voor teams van drie tot negen leden, die hun werk opdelen in acties die kunnen worden voltooid binnen iteraties met een tijdskader, sprints genoemd, niet langer dan een maand en meestal twee weken, en dan de voortgang bijhouden en opnieuw plannen in dagelijkse scrums van 15 minuten.
• Scrumban is een Agile managementmethodologie die hybriden van Scrum en Kanban beschrijft en oorspronkelijk werd ontworpen als een manier om van Scrum naar Kanban over te stappen. Tegenwoordig is Scrumban een managementkader dat ontstaat wanneer teams Scrum gebruiken als hun gekozen manier van werken en de Kanban-methode gebruiken als een lens waardoor zij hun manier van werken kunnen bekijken, begrijpen en voortdurend verbeteren.
• SEMAT (Software Engineering Method and Theory) is een initiatief om software engineering opnieuw vorm te geven zodat software engineering een rigoureuze discipline wordt. Het initiatief werd in december 2009 gelanceerd door Ivar Jacobson, Bertrand Meyer en Richard Soley met een oproep tot actie en een visie. Het initiatief werd gezien als een meerjarige inspanning om de kloof tussen de ontwikkelaarsgemeenschap en de academische gemeenschap te overbruggen en om een gemeenschap te creëren die waarde geeft aan de hele softwaregemeenschap.
• In combinatie met het persoonlijke softwareproces (PSP), de team software proces (TSP) biedt een gedefinieerd operationeel proceskader dat is ontworpen om teams van managers en ingenieurs te helpen bij het organiseren van projecten en het produceren van software de principes producten die in omvang variëren van kleine projecten van enkele duizenden regels code (KLOC) tot zeer grote projecten van meer dan een half miljoen regels code.
• Het Unified Software Development Process of Unified Process is een iteratief en incrementeel proces voor softwareontwikkeling. De bekendste en uitvoerig gedocumenteerde verfijning van het Unified Process is het Rational Unified Process (RUP). Andere voorbeelden zijn OpenUP en Agile Unified Process.