Advertorial | Agile wars en hoe deze te voorkomen

[vc_row padding_top=”0″ padding_bottom=”20″][vc_column][vc_column_text]Een advertorial van onze keurmerkopleider Global Project Performance

Hebben projectmanagers nog bestaansrecht in dit agile tijdperk? Is Agile PM beter dan PRINCE2 Agile? Of moeten we helemaal geen agile projectmanagement methodieken gebruiken en alle ontwikkelingen vorm geven met SCRUM? Bestaat er zo iets als de beste agile aanpak? Wellicht hebt u ook wel eens te maken met een stammenstrijd in uw organisatie ten aanzien van methodieken.

---

1. Agile Wars en hoe deze te voorkomen

Een paar jaar geleden organiseerden we voor onze klanten een masterclass onder de titel Agile Wars. De inhoud van de masterclass was ontwikkeld door Barbara Roberts, voormalig Director of Product Innovation bij het Agile Business Consortium.

We organiseerden de masterclass omdat we tijdens onze advieswerkzaamheden en in trainingen vaak deelgenoot worden gemaakt van situaties waarin mensen binnen eenzelfde organisatie elkaar betwisten met managementmethodieken. Een onwenselijke situatie. Immers alle afdelingen en teams in een organisatie zouden uiteindelijk dezelfde klant moeten dienen.

Inmiddels is het stof rondom de methodiekenstrijd wel een beetje neer gedaald. Maar de zienswijze van Barbara Roberts en het onderstaande artikel van haar hand zijn desalniettemin nog steeds actueel.[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39132″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]

2. Principe: op maat maken voor uw unieke omstandigheden

Nu “de markt” van project-, portfolio- en verandermanagement inmiddels overspoeld is met managementmethodieken worden organisaties zich steeds meer bewust van het belang om standaard methodieken passend op maat te maken voor de organisatie.

Een standaardmethodiek kun je nooit uit het boek toepassen in je eigen organisatie. Maatwerk, training, ondersteuning, kwaliteitsborging, community of practice en een mindset van continu verbeteren zijn noodzakelijk om duurzaam resultaat te boeken.

3. Leren van de thought leaders

Door de jarenlange praktijkervaring die mensen als Barbara Roberts hebben, kunnen zij een realistische visie bieden op wat wel en niet werkt in de praktijk en hoe je de introductie van management best practices het best kunt aanpakken. Met onze thought leader serie van artikelen willen we u blijven inspireren en aanmoedigen om best practices effectief te verbinden met de managementroutines van uw organisatie en haar teams.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_single_image image=”39134″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]De onderstaande tekst is een letterlijke vertaling naar het Nederlands van het artikel dat door Barbara Roberts is geschreven. Wij vinden het de zeer moeite waard om deze met u te delen.

Start artikel Barbara Roberts:

4. Achtergrond

In het hart van Agile waarderen we “individuen en interacties boven processen en tools”. En toch lijken de verschillende Agile-benaderingen al jaren met elkaar in oorlog te zijn. Agile wordt maar al te vaak aangeboden als een binaire keuze (“je bent agile of niet agile”), samen met de aanbeveling dat één Agile-benadering (meestal degene die wordt “verkocht”) alles is wat je nodig hebt.[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39135″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]Ik heb ook vaak een beweging gezien om de gevestigde Agile-benadering te verdringen met een andere smaak van Agile, ongeacht hoe goed de gevestigde Agile-benadering werkt – een “Mijn Agile is beter dan die van jou” mentaliteit.

Dit lijkt allemaal ver af te staan ​​van onze oorspronkelijke bedoeling dat Agile een collaboratieve, coöperatieve (en pragmatische) aanpak zou moeten zijn, gericht op het leveren van de beste oplossing voor de klant.

5. Een andere manier van denken

Laten we dit eens vanuit een ander uitgangspunt bekijken. Waarom zou u uw keuze beperken tot een enkele Agile-aanpak, als er een mogelijkheid is om een ​​”best of breed” voor uw organisatie te creëren door Agile-aanpak met elkaar te combineren?

Iedere organisatie is uniek, al zullen er altijd groepen van organisaties zijn die met soortgelijke vraagstukken te maken hebben. Het is dus onwaarschijnlijk dat dezelfde enkele Agile-aanpak even geschikt zal zijn voor een op technologie gericht softwarehuis, een complexe productorganisatie, een wereldwijde farmaceutische organisatie, een technische productieorganisatie of een klein startend bedrijf.

Zelfs binnen een complexe bedrijfsorganisatie kan de stijl van Agile per gebied verschillen, aangezien de problemen waarmee men te maken heeft totaal verschillend zijn. Ik heb jarenlang Agile-transformaties geleid in grote complexe bedrijfsorganisaties, en voor de overgrote meerderheid hiervan is de optimale oplossing het creëren van een “blended agile”-benadering. Zo wordt gezorgd dat de gekozen stijl van Agile en de agile aanpak een oplossing bieden de specifieke problemen die de organisatie wil oplossen.

6. Het uitgangspunt: een eenvoudig begrip van de Agile-opties

Om weloverwogen beslissingen te nemen, is het een goed uitgangspunt om een ​​eenvoudig beeld te hebben van de voor- en nadelen van de verschillende agile-benaderingen. En hoewel er nu waarschijnlijk 100 verschillende agile “smaken” zijn, zal ik me hier concentreren op de meest algemeen aanvaarde. Per benadering zal ik enkele voor de hand liggende sterke en zwakke punten uiteen zetten.

Deze white paper is bedoeld als een eenvoudig startpunt om besluitvorming te ondersteunen voor diegenen die geen Agile-experts zijn. Het is niet bedoeld als een gedetailleerde uitgebreide analyse van elke Agile-benadering, aangezien de volledige details elders beschikbaar zijn.

7. Enkele basisconcepten

De onderstaande informatie verwijst naar enkele basisconcepten waarnaar in dit document wordt verwezen:

• Oplossing:de oplossing die wordt geleverd. Dit kan een bedrijfsverandering zijn of een nieuwe manier van werken. De oplossing kan al dan niet software bevatten, maar normaal gesproken is het niet alleen software, aangezien nieuwe software ook veranderingen in de ondersteunende processen met zich meebrengt.
• Team:dit verwijst naar een agile team van “doeners”, de machinekamer voor het creëren van de oplossing.
• Project:dit is een stuk werk met een gedefinieerd begin, midden en einde. Een intrinsieke manier van werken voor de meeste complexe corporate organisaties (maar niet de enige manier).
• Continue verbetering:ook wel “Business as usual” genoemd. Dit is doorlopend werk zonder gedefinieerde eindtoestand. Bijvoorbeeld het aanbieden van doorlopende ondersteunende activiteiten.

8. Agile-benaderingen: basis voor- en nadelen

8.1 Scrum

Scrum beschrijft een eenvoudig teamproces en is overwegend IT-gericht in de manier waarop het wordt gebruikt, hoewel het niet beperkt is tot IT-gebruik. Scrum bestaat al vele jaren. Het is de meest bekende en populaire van de Agile-benaderingen.

Sterktes

• Heel eenvoudig te begrijpen (3 rollen, 3 ceremonies, 3 artefacten). Kan worden beschreven op een enkele pagina, waardoor het gemakkelijk te “verkopen” is.
• Als team gebaseerd agile proces is het uitstekend, het werkt goed en het is een vrij eenvoudig startpunt voor Agile op teamniveau.
• De onderliggende Scrum-waarden: commitment, lef, focus, openheid en respect.
• Scrum empirische procesbeheersing: Transparantie, Inspectie en Aanpassing.

Zwaktes

• Scrum heeft geen begrip van “project”, waardoor het moeilijk is om vooraf duidelijk te maken wat het eindresultaat zal zijn.
• De “Product Owner”-rol – de enkele “business”-rol” omvat veel verantwoordelijkheden, van besluitvorming op hoog niveau tot dagelijkse beslissingen op laag niveau. Het vinden van één persoon met de kennis en beschikbaarheid om dit allemaal te dekken, is vaak een probleem.
• Geen erkenning van het werk dat nodig is in de vroege stadia om het startpunt voor werken te creëren (bijvoorbeeld om de initiële Product Backlog te creëren).
• Scaling Scrum (het “Scrum of Scrums” -concept) biedt geen “project” -denken.

[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39136″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]

8.2 SAFe (Scaled Agile Framework)  

SAFe ondersteunt het bouwen van grote, geïntegreerde oplossingen waarvoor doorgaans honderden of meer mensen nodig zijn om ze te ontwikkelen en te onderhouden. Het groeit snel in populariteit.

Sterktes  

• Uitstekend geschikt voor het coördineren van complex technisch werk dat wordt geleverd door een groot aantal mensen in meerdere teams.
• Definieert 2-4 werkniveaus: “Team” en “Programma” (continue leveringspijplijn met behulp van een agile team-van-agile-teams), plus een of beide “Large Solution” en “Portfolio”.

Zwaktes

• Zeer beperkte informatie over het betrekken van de “business”.

[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39137″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]

8.3 eXtreme Programming (XP)

XP richt zich, zoals de titel suggereert, op het bieden van technieken voor software-engineering en best practices voor ontwikkelaars. In de praktijk wordt XP over het algemeen gebruikt in combinatie met Scrum – tot het punt waarop veel ontwikkelaars niet zeker weten waar XP eindigt en Scrum begint. In werkelijkheid is Scrum + XP een winnende combinatie voor softwareontwikkeling.

Sterkes

• Voor ontwikkelaars bieden de praktijken en technieken een uitstekende basis om ervoor te zorgen dat de best practices op het gebied van engineering worden gevolgd en dat er goed geteste code van hoge kwaliteit wordt geproduceerd.

Zwaktes

• De puur technische focus betekent dat de taal die door XP wordt gebruikt niet noodzakelijkerwijs geschikt is voor communicatie buiten de softwareontwikkelingsgemeenschap.

[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39138″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]

8.4 DSDM/AgilePM  

DSDM – (huidige versies Agile Project Framework en AgilePM) biedt een raamwerk voor het opleveren van projecten op een Agile manier.  Het kan worden verkleind tot kleine, zeer eenvoudige projecten, of opgeschaald om grote en zeer complexe projecten op te leveren. DSDM is met succes gebruikt bij grote bedrijfsveranderingen of sterk gereguleerde projecten.

Sterktes

• Projectgericht, geschikt voor elke projectstijl (niet alleen IT) en voor zowel grote als kleine projecten.
• Bewezen goed te werken binnen de complexe bedrijfswereld van projecten, programma’s en portfolio’s, en in sterk gereguleerde omgevingen.
• Brede roldefinitie:
  • Goede spreiding en diepgang van de zakelijke roldefinitie (sponsor, visionair, ambassadeur en adviseurs).
  • De roldefinitie omvat projectniveau.
• Erkenning van specialistische vaardigheden, zoals bedrijfsanalist en tester.
• Erkenning van het werk dat nodig is in de vroege stadia van een project, vooral rond het creëren van een stevig fundament (het definiëren van de breedte voor eisen en oplossingen).
• MoSCoW-prioritering, erkend als een van de meest effectieve prioriteringstechnieken die beschikbaar zijn.
• Ondersteunt bedrijfsconcepten (zoals Business Cases, Kwaliteit en Governance) maar allemaal toegepast in een agile stijl.
• Ontworpen om aan te sluiten bij Agile Program Management en Agile Portfolio Management.

Zwaktes

• Er zit veel in en kan daarom moeilijk zijn om uit te leggen.
• Geen specifieke focus op IT.

[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39139″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column width=”1/2″][vc_column_text]

8.5 Lean  

Lean is een systematische methode voor het minimaliseren van afval binnen een productiesysteem zonder dat dit ten koste gaat van de productiviteit. Lean pakt verspilling aan die is ontstaan ​​door overbelasting en ongelijkmatige werkdruk. In relatie tot Agile levert Lean vaker de mindset die ten grondslag ligt aan het werk dat wordt uitgevoerd.

Sterktes

• Een Lean-mentaliteit creëert een waardevol perspectief op het werk dat wordt gedaan.
• Het uitvlakken van pieken en dalen helpt verspilling te beperken en de efficiëntie te verbeteren.

Zwaktes

• Waarschijnlijk niet genoeg alleen voor de meeste omstandigheden.

[/vc_column_text][/vc_column][vc_column width=”1/2″][vc_single_image image=”39140″ img_size=”medium”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]

8.6 Kanban  

Kanban is een methode voor het managen van productontwikkeling met de nadruk op continue levering zonder het ontwikkelteam te overbelasten. Net als Scrum is Kanban een proces dat is ontworpen om teams effectiever te laten samenwerken. Kanban-borden bieden een effectief visueel beeld van de voortgang en de huidige status, zowel in elektronische als fysieke vorm. Dit ondersteunt Agile-transparantie.

Sterktes

• Zeer effectief voor continue verbeteringsactiviteiten.
• Work In Progress (WIP) limieten zorgen ervoor dat commitment om werk uit te voeren realistisch en haalbaar blijft.
• Zelf organiserend “pull”-systeem dat is ontworpen om over bestaande workflows heen te worden gelegd.

Zwaktes

• Meestal niet genoeg alleen.

[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_single_image image=”39141″ img_size=”large”][/vc_column][/vc_row][vc_row padding_top=”10″ padding_bottom=”10″][vc_column][vc_column_text]

9. Een Blended Agile-benadering  

Dit is waarschijnlijk het gemakkelijkst uit te leggen door enkele real-life voorbeelden te geven (geanonimiseerd).

9.1 Voorbeeld wereldwijd gereguleerde organisatie  

Een grote, wereldwijd gereguleerde organisatie die programma’s en projecten van meerdere miljoenen euro’s uitvoert. De organisatie was al gecommitteerd aan PRINCE2 en formele CMMI-kwaliteitscertificering op het hoogste niveau.

De valse start

XP werd gekozen als het enige “agile antwoord”, aangestuurd door een interne liefhebber. Er werd besloten om alle projectmanagers te laten vervallen, omdat de interne Agile-coach hen vertelde “XP heeft geen rol voor projectmanagers”.

De herstart

Uit een evaluatie bleek dat, aangezien de hele organisatie gebaseerd is op succesvolle realisatie van projecten en programma’s, het een slechte zet was om alle projectmanagers te laten vervallen.

Er werd overeengekomen om:

• XP te behouden aangezien het goed is in wat het doet (software-engineering) en er al veel ontwikkelaars waren opgeleid.
• DSDM / AgilePM te introduceren om:
  • Zowel het teamniveau als projectniveau te adresseren en om een ​​model te bieden voor het betrekken van de business.
  • Deze te laten samenwerken met PRINCE2 (reeds beproefd en getest). Hierdoor kan het team gefocust blijven op softwareontwikkeling.
  • Een nieuwe Agile-interface te creëren voor het interne kwaliteitsproces die moest voldoen aan de eisen voor CMMI-niveau 5 (dit is de eerste keer geslaagd).

Uiteindelijke Agile-oplossing:

mix van XP + DSDM, gekoppeld aan PRINCE2, formele interne kwaliteit en formele externe kwaliteit CMMI-niveau 5.

9.2 Voorbeeld wereldwijde product organisatie

Een wereldwijde technische product organisatie, die onderdelen produceert op alle 5 continenten. Ze hadden al gekozen voor (een vroege versie van) SAFe als hun agile aanpak. Maar toen besloten ze dat ze het concept van “Project” nodig hadden. Dit moest worden toegevoegd.

Uiteindelijke Agile-oplossing:

Een mix van SAFe + de projectmanagementelementen van DSDM (maar gedefinieerd met behulp van SAFe-terminologie).

9.3 Voorbeeld in UK gevestigde organisatie

Een in het Verenigd Koninkrijk gevestigde organisatie die een complex technisch product verkoopt.

Final Agile Solution 1:

XP + Scrum + Kanban … voor productontwikkeling.

Final Agile Solution 2:

XP + Kanban … voor hun Business-As-Usual Support-teams. Dit was een groep individuen die aan afzonderlijke onderdelen werkte. Ze konden daarom hun werk niet met elkaar ruilen of delen.

9.4 Voorbeeld wereldwijde complexe veranderprogramma’s

Een wereldwijde organisatie die een complex programma voor bedrijfsverandering uitvoert, met veranderingen in het werkvloerproces, wijzigingen in het bedrijfsmodel en maatwerk van softwarepakketten.

Final Agile Solution:

Agile Program Management (voor het hogere niveau) + Agile Project Management voor alle projecten (zowel IT als niet-technisch) + Scrum / Kanban / Lean op teamniveau.

10. Samenvatting  

Een goed uitgangspunt bij het kiezen van een Agile-benadering of mix van Agile-benaderingen is het beantwoorden van enkele eenvoudige vragen:

• Zijn we een kleine, eenvoudige organisatie, een grote complexe corporate organisatie of ergens tussen de twee uitersten in?
• Heeft onze organisatie al een projectmatige aanpak om veranderingen te realiseren (technisch en niet-technisch)?
• Gaan onze initiatieven alleen over het bouwen van een product of gaan ze ook over bedrijfsverandering?
• Ligt de focus voor Agile op het leveren van technisch en niet-technisch werk, of alleen technisch werk?
• Ligt de focus voor Agile op het leveren van zeer grote complexe technische stukken werk?

Het beantwoorden van deze eenvoudige vragen levert al een eerste inzicht op in passende Agile-benaderingen die als basis kunnen dienen. Van daaruit kan worden gekeken naar aanvullende behoeften en Agile-benaderingen die daar een antwoord op kunnen bieden.

De uiteindelijke oplossing voor uw organisatie kan dus Scrum, SAFe of DSDM zijn. Of het kan een mix zijn van SAFe+Scrum of AgilePM+Scrum+Kanban.

Het belangrijkste is dat je de Agile aanpak of combinatie van aanpakken kiest die het beste past bij wat jouw organisatie nodig heeft.

11. Over Global Project Performance

De missie van Global Project Performance is om best practices (veel gebruikte standaards) op maat te maken en effectief te implementeren binnen organisaties. Met meer dan 500 klanten is de onderneming in de afgelopen 15 uitgegroeid tot een leidend instituut op het gebied van project-, programma-, portfolio- en verandermanagement en het daarvoor benodigde leiderschap.

Global Project Performance is een IPMA-Keumerkopleider, Accredited Consulting Partner voor P3M3 (Project Programme Portfolio Management Maturity Model) en Accredited Training Organisation voor PRINCE2, Agile PM, PRINCE2 Agile, Stakeholder Engagement, Change Management, Project Programme Portfolio Offices (P3O), Managing Successful Programmes (MSP), Management of Portfolios (MOP), Managing Benefits en Management of Risk (M_o_R).

Wilt u kennis maken met onze onderscheidende dienstverlening? Neem dan contact op via 030 22 11 987, bezoek onze website www.globalprojectperformance.com of mail ons info@globalprojectperformance.com.[/vc_column_text][/vc_column][/vc_row][vc_row padding_top=”30″ padding_bottom=”10″][vc_column width=”1/2″][vc_column_text]www.globalprojectperformance.com

info@globalprojectperformance.com

030-2211987[/vc_column_text][vc_btn title=”Naar de website” style=”custom” custom_background=”#f90000″ custom_text=”#ffffff” align=”center” link=”url:https%3A%2F%2Fwww.globalprojectperformance.com|title:Naar%20de%20website|target:_blank”][/vc_column][vc_column width=”1/2″][vc_column_text][/vc_column_text][/vc_column][vc_column][/vc_column][/vc_row][vc_row padding_top=”20″][vc_column][kleo_social_share][vc_posts_grid loop=”size:12|order_by:date|post_type:post|categories:801″][/vc_column][/vc_row]