Samenwerking tussen analisten: praktische tips

Samenwerking tussen analisten: praktische tips

Dennis Geluk

Als analist werk je in projecten samen met collega’s die verschillende taken en verantwoordelijkheden hebben. Een goede onderlinge samenwerking en communicatie is dan cruciaal om op een efficiënte manier tot een waardevolle (software)oplossing te komen.

Dit artikel is de laatste van een reeks publicaties waarin we als analisten praktische tips delen om efficiënt met verschillende rollen in een project samen te werken. Dit keer staat de samenwerking tussen analisten onderling centraal.

Samenwerking tussen meerdere analisten: enkele voorbeeldscenario’s

Laten we beginnen met een stukje context. Gezien de gemiddelde samenstelling van een Scrum team kan ik mij goed voorstellen dat niet iedereen een beeld heeft bij de samenwerking van analisten onderling.

Waar er doorgaans in een ontwikkelteam slechts één analist (rol) in het team zit zijn er wel degelijk scenario’s te verzinnen waarin een team meerdere analisten heeft of waarin samenwerking vereist is met analisten uit een ander team. Denk bijvoorbeeld aan:

  • de periode waarin een uitstromende analist zijn werkzaamheden overdraagt aan een nieuw teamlid
  • een periode waarin het team een sterke afhankelijkheid heeft met functionaliteiten die opgeleverd moeten worden door een ander team
  • een periode waarin extra capaciteit gevraagd is om nieuwe “Features” voor te bereiden voor bijvoorbeeld een aankomend PI event (SAFe)
  • een periode waarin een team wordt gesplitst in twee teams om de toenemende vraag te kunnen ondersteunen

3 praktische tips voor een betere samenwerking tussen analisten

1. Verdeel de verantwoordelijkheid

Als we kijken naar scenario’s waarin meerdere analisten samen verantwoordelijk zijn voor bijvoorbeeld één feature, één applicatie of één team dan is het in de praktijk vaak lastig om de werkverdeling helder en transparant te houden.

Daar waar je samen verantwoordelijk bent is het makkelijk om ook samen zaken op te gaan pakken. Dit heeft uiteraard als voordeel dat je veel inhoudelijk kunt sparren en dat je gezamenlijk tot een gedeelde oplossing kunt komen. Het nadeel is echter dat de capaciteit op deze manier niet optimaal benut wordt.

Onze ervaring is dat het in zo’n scenario loont om de verantwoordelijkheden scherp te verdelen en goede afspraken te maken over het eigenaarschap van features:

  • Wees transparant in het eigenaarschap. Door voor iedereen helder te maken welke analist het primaire aanspreekpunt voor een story of feature is, voorkom je verwarring en weet iedereen wie het eigenaarschap heeft van de functionaliteit.
  • Beperk de focus. Door het eigenaarschap en de daarbij horende verantwoordelijkheden te verdelen voorkom je dat meerdere analisten zich vastbijten in hetzelfde onderwerp en dat daarmee capaciteit en focus verloren gaat. Uiteraard is het nog steeds logisch om daar waar nodig actief kennis te delen en te sparren over eventuele uitdagingen. Uiteraard helpt een WIP limit ook prima om de focus te behouden.
  • Zorg voor benaderbare documentatie. Gezien het feit dat slechts één analist het primaire aanspreekpunt is, is het belangrijk om de beschikbare informatie (documentatie) toegankelijk op te zetten en te houden voor andere analisten / geïnteresseerden. Een teamwiki is vaak handig, maar niet als je informatie actief wilt delen met mensen buiten je team.

2. Werk consistent

Een veelvoorkomende valkuil voor agile teams is dat zij de focus te veel op het eigen team hebben gericht. Een risico hiervan is dat niet, of onvoldoende, aansluiting gezocht wordt bij een gedeelde werkwijze voor het vastleggen van requirements / documentatie. Zeker in een omgeving waarin analisten actief kennis moeten delen, loont het de moeite om hier effort in te stoppen. Kennis delen kan bijvoorbeeld via analistengildes waar men behaalde resultaten en best practices kan delen. Een gedeelde werkwijze heeft de volgende voordelen:

  • Verhoging van de flexibiliteit. Door de werkwijzen op elkaar af te stemmen wordt de onderlinge inwisselbaarheid groter en kunnen de analisten elkaar makkelijker vervangen en ondersteunen. Hierdoor wordt de flexibiliteit van de organisatie en de value stream vergroot.
  • Verhoging van de continuïteit. Een gedeelde werkwijze zorgt voor continuïteit voor het team en maakt communicatie met andere teams makkelijker.

3. Communiceer!

Zoals bij iedere vorm van samenwerking is communicatie het belangrijkste punt om rekening mee te houden. Zonder actieve communicatie zullen mensen zich verschuilen achter procedures en dreigt “shaming en blaming” indien zaken niet lopen zoals verwacht. Zoek daarom de communicatie actief op en plan zo nodig een afstemmingsoverleg tussen betrokken analisten met bijvoorbeeld de gedeelde PO(s).

Binnen deze actieve communicatie zal “planning” vaak ook een meer prominente rol gaan spelen. Zeker indien je als team afhankelijk bent van werkzaamheden van een ander team, is het essentieel om transparant en helder inzicht te geven in de planningen van de diverse teams.

Uiteraard is dit een belangrijk onderdeel in de voorbereiding van het PI event. Na het PI event zal dit in een scrum-of-scrums ook afgedekt worden. Het kan echter geen kwaad om hier ook gewoon buiten dit afstemmingsmoment transparant in te zijn.

Dus:

  • Deel planningen. De meest primaire vorm is uiteraard om je scrum board op een toegankelijke plaats op te hangen zodat iedereen kan zien waar aan gewerkt wordt / zal worden. Indien je met behulp van een elektronisch board werkt is het simpel om je board openbaar te maken voor andere gebruikers.
  • Visualiseer afhankelijkheden. Naast het simpel delen van je planning loont het de moeite om afhankelijkheden met andere teams inzichtelijk te maken. Dit kan bijvoorbeeld door een simpele kleur- / notatieconventie op je papieren board, maar ook door de zaken elektronisch te koppelen, bijvoorbeeld via “dependency” relaties.

Meer informatie?

Wilt u de samenwerking tussen de analisten in uw team optimaliseren? DiVetro heeft veel ervaring met de interactie tussen analisten onderling in Scrum. Wij vertellen u graag hoe u deze samenwerking kunt structureren en verbeteren. We helpen u graag via info@divetro.nl of +31 (0)88 000 54 00.

Dennis Geluk is een senior informatie-analist en partner van DiVetro. Hij heeft meer dan 15 jaar IT-ervaring. Dennis is een gecertificeerd Use-Case 2.0 coach. Hij heeft bij verschillende organisaties een spilfunctie vervuld bij het implementeren van UC2.0, het invoeren van Agile werken en het verbeteren van requirements standaarden. Momenteel is Dennis coach en business analist bij de KLM en helpt hij diverse organisaties met vragen rond professionalisering.

Geen reactie's

Geef een reactie