Efficiënt werken; stop onnodig mailverkeer op de werkvloer

Weet je het nog, toen internet en e-mail werden geïntroduceerd en helemaal hip en happening waren? Je hield vol spanning je mailbox in de gaten want digitale post: wow! Bijna 25 jaar later is de spanning er nog steeds, maar van een heel andere orde. Hoe kom je door die brei heen? Onderzoek toont keer op keer aan dat werknemers ruim 25% van hun tijd verliezen aan mailverkeer. In dit blog delen we tips om weer lekker en efficiënt te werken.

Versla de brei aan e-mails

Onze dagelijkse brei aan mails komt ruwweg uit drie bronnen: collega’s c.q. interne berichten, externe partijen en allerlei platformen en applicaties die je gebruikt. Bij de eerste categorie valt al winst te behalen door gewoon even naar de betreffende collega toe te lopen. Maak je je ‘stappenteller’ ook gelijk blij. En je hebt met een beetje geluk meteen reactie, want jouw mail heeft helaas veel concurrentie. Bellen kan ook, al zijn we dat met onze smartphones al bijna vergeten. Voor de laatste categorie kun je vaak al winst behalen met het aanpassen van de instellingen. Bijvoorbeeld door in te stellen dat je niet bij alle updates een notificatie per mail ontvangt maar wekelijks een samenvatting van de wijzigingen.

Efficiënte alternatieven voor e-mail

Ook de vele cc’tjes worden steeds meer ervaren als een vorm van berichtenterreur. Hoeveel daarvan had je nou echt niet willen of mogen missen? Laat ze via instellingen in een aparte mailbox zetten en bekijk ze op een later en geschikter tijdstip alsnog. Om het interne mailverkeer verder aan banden te leggen, zijn zeer handige chatapps beschikbaar. Die worden dan ook op steeds grotere schaal gebruikt.

Zelf werken we met Slack, maar ook Microsoft Teams, Workplace van Facebook, G-suite en Hangouts zijn goede alternatieven. Soms is de meest efficiënte vorm van communicatie een kort overleg van maximaal 15 minuten. Een prima manier voor een snelle update en bespreken van een probleem of vraag. Wanneer de collega’s niet allemaal op dezelfde plek aanwezig zijn, zijn Skype of Teams goede tools om online te overleggen.

Ambrero Blog - Efficient werken email alternatives

De voordelen van chatsoftware

De voordelen van chatsoftware liggen voor de hand: je bepaalt als team wie er wel en niet in een bepaalde chatgroep zitten. Vervolgens kun je via notificaties instellen wat je wilt ontvangen en hoe je daar, zichtbaar of hoorbaar, iets van merkt. Ook kun je kanalen aanmaken voor verschillende onderwerpen. En je kunt de chatsoftware gemakkelijk even uitzetten als je te druk bent of je wilt focussen! Slack en Teams bieden ook een directe messaging eigenschap aan die geïntegreerd kan worden met andere applicaties. Effectieve tooling voor het beantwoorden van korte vragen, tijdgevoelige zaken, versturen van berichten naar teams en mededelingen. Zoals wanneer een collega op taart trakteert bij de koffie!

Communicatie via klantenportalen

In het contact met klanten heeft het mailverkeer vaak betrekking op documenten of andere informatie die veelvuldig heen en weer geslingerd wordt. Over versiebeheer zullen we het maar helemaal niet hebben. Omdat die documenten vaak ook gevoelige informatie bevatten, is in veel gevallen het beschikbaar stellen via een klantenportaal een betere optie. Een klantenportaal biedt voordelen als:

  • Klantenbinding door korte communicatielijnen en informatie & service op maat
  • Kosten besparen door handmatige processen te automatiseren
  • Overzicht door 24/7 informatie te delen met de klant via één communicatiekanaal
  • Verhogen van efficiency door koppeling met andere systemen

Ter illustratie: voor MMD/AOC ontwikkelden we een portal voor het afhandelen van garantie-aanvragen. Hiermee realiseert onze klant een tijdsbesparing van 16 tot 20 uur per week. Hun klanten zijn ook blij met de klantenportaal omdat de aanvragen 15 keer sneller worden uitgegeven, zonder enig mailverkeer. Dubbele winst dus.

De tips nog even op een rij:

  • Intern mailverkeer verminderen door collega’s te bellen, een kort overleg houden en je gezonde verstand gebruiken
  • Extern mailverkeer via platformen, applicaties verminderen door het aanpassen van notificaties via instellingen
  • Mailverkeer met klanten stroomlijnen door een klantportaal te gebruiken
  • Hulpmiddelen om mailverkeer te verminderen door het gebruik van chatapps zoals Slack en Microsoft Teams

Wil je meer weten over de mogelijkheden om efficiënter te werken met software? Bel, Skype of Slack ons gerust. Mailen mag bij hoge uitzondering ook….

Bart Matthaei

Stel je klant centraal met een klantportaal

>Door de huidige stand van de technologie en de snelheid van communicatie verwachten bedrijven diezelfde snelheid als het gaat om samenwerking. Technologie is gemeengoed, je onderscheidend vermogen creëer je door je te richten op de mens. In dit artikel laten we zien hoe een klantportaal kan bijdragen aan een betere samenwerking, heldere communicatie en hogere klanttevredenheid.

Innovatie in samenwerking en communicatie

Herkenbaar? Je hebt informatie nodig van je klanten. De een stuurt een mail, de volgende belt op en de derde stuurt een link naar een Google spreadsheet. Je medewerkers moeten meer moeite doen om de informatie nauwkeurig te verwerken en dat is vervelend. Als klant moet je langer wachten op response en vraag je je af of je iets niet goed hebt aangeleverd. Inzicht in de voortgang ontbreekt immers. Is een aanvraag in behandeling genomen, al afgehandeld moet er nog nadere actie plaatsvinden? Met de technologische mogelijkheden van tegenwoordig moet dit beter kunnen!

Geef de klant zelf de regie

Met een klantportaal bied je klanten uniforme informatie via één communicatiekanaal. Ook kun je direct feedback geven of het gevraagde correct en volledig is ingevuld. Efficiënter voor beide partijen en de klant voelt zich centraal gesteld. Daarnaast geeft een portaal de klant automatisch inzicht in de voortgang. Zo maakten we een klantportaal voor een medische instelling. Via het portaal kunnen patiënten hun eigen afspraken inplannen. Daarmee krijgt de klant – of in dit geval de patiënt – het gevoel ‘het gaat hier om mij, ik hoef me niet te voegen naar de agenda van de arts, maar heb zelf de regie.’

Voorbeeld van een klantportaal

Een ander voorbeeld is van een opleider die trainingen verzorgt voor helpdeskmedewerkers van verzekeraars. Veel verzekeraars hebben in de laatste drie maanden van het jaar extra capaciteit nodig in het callcenter omdat veel mensen dan willen overstappen naar een nieuwe zorgverzekering. Die extra krachten worden via een uitzendbureau ingehuurd en moeten worden opgeleid. Daarvoor heb je informatie nodig: wie zijn deze mensen, wat hebben ze al in hun mars en wat zijn hun contactgegevens?

Real-time voortgang volgen

Tijdens de opleiding is er communicatie tussen de opleider en het uitzendbureau over de voortgang. Voorheen werd dat telefonisch besproken. Met een klantportaal kunnen zowel de uitzendbureaus als de opleider real-time de voortgang van alle cursisten volgen:

  • zijn ze aanwezig geweest bij de klassikale lessen
  • volgen ze de e-learning-lessen volgens plan
  • wanneer verwachten we de cursist te kunnen inzetten?

Gedurende het hele proces heeft de klant dus meer inzicht in de stand van zaken. Een fijn idee.

Technologie die bijdraagt aan de klantbeleving

Zo draagt een technologische oplossing als een portaal bij aan de beleving van je klant. Het is niet alleen enorm efficiënt, waardoor het voor iedereen tijd en geld bespaart. Nog veel belangrijker: je klant voelt zich betrokken bij het proces, voelt zich gezien en ‘in control’. En dat willen we toch allemaal?

Nieuwsgierig?

Benieuwd hoe je jouw klanten beter kunt bedienen? Bekijk hoe AOC/MMD hun garantie-aanvragen 40 keer sneller afhandelen dankzij hun klantportaal. Of neem vrijblijvend contact op met ons om de potentiële vooruitgang voor jouw organisatie te bespreken, via +31 (0)88 – 26 27 376.

Bart Matthaei

AVG komt eraan; ben je er klaar voor?

Check ons AVG actieplan en deze vraag is beantwoord.

Vanaf 25 mei 2018 is de Algemene Verordening Gegevensbescherming (AVG) van toepassing. Deze privacywetgeving geldt in de hele Europese Unie en is ook wel bekend als General Data Protection Regulation (GDPR).

Als organisatie krijg je met de komst van AVG meer verplichtingen. De nadruk ligt, meer dan nu, op jouw verantwoordelijkheid om te kunnen aantonen dat je handelt volgens de wet.

Deze verantwoordelijkheid gaat over alle persoonsgegevens die binnen je organisatie worden opgeslagen. Denk hierbij aan gegevens van je medewerkers (salarisadministratie) en je klanten (CRM). Het maakt niet uit of je deze gegevens in een eigen systeem opslaat of dat je hier een externe partij voor gebruikt, zoals bij SaaS dienstverlening voor CRM. Je bent en blijft verantwoordelijk voor de persoonsgegevens die je in deze systemen opslaat.

Strengere en uitgebreidere wetgeving

Deze verantwoordelijkheid is niet nieuw. De Wet Bescherming Persoonsgegevens stamt al uit 2001. Maar de nieuwe wetgeving is een stuk strenger en uitgebreider, veel meer bedrijfsactiviteiten vallen onder de nieuwe wetgeving. Daarnaast geeft de AVG de toezichthouders flinke bevoegdheid waarbij geldstraffen bij overtreding kunnen oplopen tot 20 miljoen euro. Het is dus belangrijk om te beoordelen of je voldoet aan de wetgeving. Niet alleen om de privacy van je medewerkers en klanten beschermen maar ook om boetes te voorkomen.

Om te kunnen voldoen aan de nieuwe wetgeving moet je een aantal voorbereidingen treffen. In mijn werk als softwareleverancier heb ik dagelijks te maken met beveiliging van data en persoonsgegevens. Met deze kennis en ervaring help ik je graag op weg met een concreet actieplan.

“AVG; de nadruk ligt op jouw verantwoordelijkheid om te kunnen aantonen dat je handelt volgens de wet”

AVG – terug naar de basis

Laat ik beginnen bij de basis en een aantal begrippen uitlichten die worden gebruikt in de Algemene Verordening Gegevensbescherming.

1. Persoonsgegevens

Het doel van de AVG is om persoonsgegevens te beschermen. Persoonsgegevens zijn gegevens die informatie bevatten over een natuurlijk persoon en waarmee hij/zij identificeerbaar zijn. Voorbeelden zijn o.a. NAW gegevens, BSN, IP adres en profielfoto.

2. Bijzondere persoonsgegevens

Dan zijn er ook nog bijzondere persoonsgegevens over iemands gezondheid, politieke opvattingen, ras, strafrechtelijk gedrag etc. Aangezien deze gegevens zeer gevoelig zijn gelden hier striktere regels voor. Sterker nog; verwerking is in de meeste gevallen verboden.

Het verwerken van persoonsgegevens omvat alle handelingen die een organisatie kan uitvoeren met persoonsgegevens, van verzamelen tot en met vernietigen.

3. Belangrijke rollen binnen AVG

Binnen de AVG zijn drie rollen belangrijk, namelijk:

  • Verwerkingsverantwoordelijke (voorheen verwerker); de persoon / organisatie die het doel van de verwerking vaststelt en de middelen beschikbaar stelt. In het kader van dit artikel ben jij dit.
  • Verwerker (voorheen bewerker); de persoon of organisatie die in opdracht van de verantwoordelijke de gegevens verwerkt. Dit zijn de leveranciers die te maken krijgen met je persoonsgegevens, zoals freelancers, de leveranciers van je SaaS applicaties, de hostingpartij die je gegevens opslaat.
  • Betrokkene; de persoon van wie de persoonsgegevens verwerkt worden.

Ambrero blog AVG komt eraan

AVG actieplan – de voorbereiding

Er is een aantal stappen die je kunt nemen om problemen te voorkomen. Hieronder vind je het overzicht.

Stap 1: zorg voor bewustwording

Informeer beleidmakers binnen je organisatie over de komst van de nieuwe privacyregels. Bepaal gezamenlijk de impact op de huidige processen en welke aanpassingen nodig zijn om aan de AVG te voldoen.

Stap 2: geef de betrokkenen grip

Onder de AVG krijgen de betrokkenen meer privacy rechten, zoals dataportabiliteit. Zorg ervoor dat zij deze rechten ook kunnen aanwenden. Bij het genoemde voorbeeld moet de betrokkene zijn/haar gegevens makkelijk kunnen ontvangen om eventueel door te geven aan een andere organisatie.

Stap 3: breng de persoonsgegevens in kaart

Een onderdeel van je verantwoordingsplicht is het in kaart brengen van de persoonsgegevens die worden verwerkt, het doel ervan, de bron van de gegevens en met wie deze worden gedeeld.

Stap 4: check je verwerkingsgrondslag

Om persoonsgegevens te mogen verwerken moet er een verwerkingsgrondslag zijn, zoals de expliciete toestemming van de betrokkenen. De eisen hiervoor zijn aangescherpt. Pas, indien nodig, de wijze waarop je de toestemming vraagt én registreert aan.

Stap 5: persoonsgegevens beveiligen

De AVG schrijft voor dat je technische en organisatorische maatregelen neemt om persoonsgegevens te beschermen tegen verlies en onrechtmatige verwerking. Denk hierbij aan pseudonimiseren en versleutelen van persoonsgegevens, het afschermen van persoonsgegevens, firewalls, virusscanners, het maken van back-ups etc.

Stap 6: hou bij ontwerp rekening met privacy

Privacy by design houdt in dat je bij het ontwerpen van producten en diensten ervoor zorgt dat persoonsgegevens goed beschermd worden. Je dient er voor te zorgen dat je alleen persoonsgegevens verwerkt die noodzakelijk zijn voor het specifieke doel dat je wilt bereiken. Vooral bij het ontwikkelen van maatwerk software kun je ook nadenken over wie bepaalde gegevens mag zien en wanneer hij deze te zien krijgt. Ambrero adviseert haar klanten hierin bij het uitwerken van een applicatie.

Stap 7: maak de standaard strikt

Hiermee wil de AVG bereiken dat, indien een dienst of applicatie de keuze geeft aan gebruikers welke persoonsgegevens wel of niet worden gedeeld en/of verzameld, standaard de meest strikte privacy-instellingen worden gehanteerd om zo de persoonsgegevens te beschermen. Een voorbeeld hiervan zijn de standaard privacy-instellingen van je Facebook account.

Stap 8: maak procedure voor datalekken

Stel een werkwijze op zodat het duidelijk is hoe er moet worden gehandeld bij het ontstaan van een datalek.

Stap 9: sluit verwerkersovereenkomsten af

Heb je het bewerken van jouw gegevens uitbesteed aan bijvoorbeeld een software leverancier of hostingpartij? Sluit dan met deze partijen een verwerkersovereenkomsten die voldoet aan de AVG eisen.

Stap 10: aanvullende voorbereidingen

In een aantal specifieke gevallen is het verplicht om een functionaris voor gegevensbescherming (FG) en/of een Leidend Toezichthouder aan te stellen en/of een Data Protection Impact Assessment (DPIA) te doen. Ga hier na of dit voor jouw organisatie geldt.

Hoe kan een softwareleverancier helpen?

Wanneer je gebruik maakt van een applicatie die extern is ontwikkelt mag je kennis verwachten op het gebied van gegevensbescherming. Een gedegen softwareleverancier geeft advies op het gebied van:

  • keuze van de te verwerken persoonsgegevens
  • de juiste keuzes op het vlak van privacy by design
  • beveiliging en versleuteling van persoonsgegevens
  • het loggen en signaleren van verdachte activiteit

AVG – samenwerken aan een veilige omgeving

Het doel van de Algemene Verordening Gegevensbescherming is om organisaties bewuster om te laten gaan met het verwerken van persoonsgegevens. Uiteindelijk is de veiligheid van deze gegevens alleen te waarborgen als alle betrokken partijen zich verantwoordelijk voelen.

Bij Ambrero is het beschermen van persoonsgegevens en data een belangrijk en vast onderdeel tijdens onze software cyclus. Voor advies over de toepassing hiervan bij een bestaande of nieuw te ontwikkelen applicatie kun je bij mij terecht. Ik help je graag een stap vooruit.

Bart Matthaei

Kostenbeheersing in Scrum: kiezen tussen scope en budget

Als er iets is dat ik de afgelopen 17 jaar als ontwikkelaar heb geleerd, is het dat er niets zo moeilijk is als het begroten van grote software projecten. Ik kan mij nog heel goed één van de eerste projecten van Ambrero herinneren, inmiddels zo’n 15 jaar geleden. We zouden een EPD (Electronisch Patienten Dossier) ontwikkelen voor Stichting CASA. Het exacte getal weet ik niet meer, maar ik kan me herinneren dat we voor de eerste fase een uur of 100 hebben geoffreerd. Uiteraard is het project vele malen groter geworden dan dat. Maar blijkbaar hebben we het goed gedaan, want CASA is lang klant gebleven. In deze blog deel ik mijn ervaring met kostenbeheersing in Scrum met je.

Inmiddels zijn we een stuk beter geworden in het inschatten van werk, maar het blijft een lastig onderdeel van ons vak. Bij maatwerkprojecten ligt er geen draaiboek klaar met exacte specificaties, dus de betrokken personen, inclusief de klant, doen een hoop aannames over de te ontwikkelen functionaliteit.

Waterval ontwikkelmethode voor meer zekerheid?

Ik hoor vaak de vergelijking met de bouwsector: een aannemer maakt toch ook een exacte prijscalculatie voor een bouwproject? Waarom is dat voor software dan zo moeilijk? Die aannemer doet dat op basis van standaardproducten (materiaal) en specificaties die vaak al vaststaan (bouwtekeningen). Wil je dit doortrekken naar softwareontwikkeling dan zal je vooraf exact moeten definiëren wat je wilt hebben en een specialist moeten inhuren om een specificatie te schrijven. Het resultaat is een hoop tijd en kosten om tot die specificatie te komen, maar daarna wel meer zekerheid over doorlooptijd en budget.

Ik zeg meer zekerheid, want uitgewerkte specificaties zijn geen garantie voor succes. Waar dingen in de bouw vaak zichtbaar en meetbaar zijn, is dit bij software ontwikkeling helaas niet het geval. De specificaties gaan over de verwachte output voor de klant: welke functionaliteit krijg ik en hoe ziet deze er ongeveer uit. Maar the devil is in the details: goede specificaties schrijven op detailniveau is ontzettend lastig, dus regelmatig lopen ontwikkelaars tegen diverse scenario’s aan waar bij het schrijven van de specificaties geen rekening mee is gehouden. Daarnaast loop je het risico op interpretatieverschillen van de specificaties: bij het waterval model is de periode tussen specificeren en software geleverd krijgen behoorlijk lang, vooral bij grotere projecten. Je kunt in de tussentijd slecht meten of de interpretatie van het team correct is en daarnaast loop je het risico dat de behoeften van de gebruikers in die periode inmiddels zijn veranderd.

“Hofstadter’s Law “It always takes longer than you expect, even when you take into account Hofstadter’s Law.”

Bovenstaand proces is het waterval model dat inmiddels door de meeste IT bedrijven is losgelaten. Tegenwoordig bewegen de meeste bedrijven richting “Agile”. Nu begint Agile als begrip door alle marketing-buzz nogal zijn waarde te verliezen, maar voor ons betekent het in ieder geval het volgende. Zet korte stappen richting je doel, waarbij je na iedere stap evalueert of de richting nog steeds de juiste is en of er zaken zijn die je kunt leren van de vorige stap die je hebt genomen. Herhaal dit proces, totdat je bent waar je wilt zijn.

Project agility met Scrum

Klinkt allemaal vrij logisch, en dat is het ook. De methodiek die we daarvoor gebruiken is Scrum. Scrum werkt niet op basis van uitgebreide specificaties die bij aanvang van het project in beton staan gegoten. In plaats daarvan ligt er een soort silhouet van functionaliteit, het Product Backlog, waarbij de functionaliteiten die op korte termijn gemaakt moeten worden vrij helder zijn, maar naar mate je richting de stip op de horizon kijkt steeds vager.

Dit geeft je de flexibiliteit om gedurende het project de functionaliteit te ontwikkelen die op dat moment de meeste waarde creëert voor je product. Daarnaast kun je makkelijk inspringen op actualiteiten binnen je bedrijf. Dankzij deze flexibiliteit is het mogelijk om in kortere tijd een productierijp systeem op te leveren, die wellicht nog niet bij de stip op de horizon is aanbeland, maar in ieder geval wel gebruikt kan worden, wat twee grote voordelen heeft:

  • Testresultaten van echte gebruikers
  • Het product verdient zichzelf sneller terug (opbrengsten/besparingen)

Echter het grootste voordeel van Scrum is de samenwerking tussen opdrachtgever (Product Owner) en het ontwikkelteam. Er is een korte feedback-loop, de stakeholders kunnen iedere 2 weken een resultaat zien en hier feedback op geven etc. Al met al zal dit de kwaliteit van de functionaliteit en de acceptatie van het product ten goede komen.

Projectfactoren Goed, Snel, Goedkoop – kies er twee

Maar deze werkwijze kent ook nadelen. De stip op de horizon blijft vaag en het is heel moeilijk (en risicovol) om hier een datum of budget aan te koppelen. Hierdoor krijgt een opdrachtgever soms het gevoel dat het project een bodemloze put is, zonder duidelijke deadline, waar iedere Sprint weer een stuk van zijn budget wordt verbrand. En dus rijst de vraag: kun je niet meer zekerheid krijgen?

Jazeker! Software ontwikkeling heeft een aantal factoren:

  • Scope; welke functionaliteit gaan we ontwikkelen?
  • Budget; hoeveel gaat het kosten? Oftewel, hoeveel mensen werken aan het project.
  • Tijd; wanneer is het af?

Ik geef een paar scenario’s van fixeren van deze factoren:

  • Scope is fixed, tijd is fixed; de leverancier garandeert dat hij op een bepaalde datum een bepaalde hoeveelheid functionaliteit af heeft. De enige manier waarop hij dit kan garanderen is als hij flexibel mag zijn in de inzet die hij op het project zet. Budget zal dus variabel moeten zijn.
  • Budget fixed, tijd is fixed; de leverancier garandeert een bepaalde inzet (budget) over een bepaalde periode (tijd), maar kan geen garanties geven over de hoeveelheid functionaliteit die ontwikkeld kan worden.
  • Budget is fixed, scope is fixed; de enige variabele is tijd, oftewel snelheid van ontwikkelen. Door sneller te ontwikkelen zal de software meer fouten bevatten en zal de kwaliteit naar beneden gaan. Daarnaast zal bij iedere tegenslag de kwaliteit verder onder druk komen te staan..

Het laatste scenario is onwenselijk. Je hebt als opdrachtgever op de korte termijn zekerheid, maar waarschijnlijk is het resultaat een stuk software dat niet goed functioneert, vol zit met fouten en slecht onderhoudbaar is. Op de lange termijn is dit de duurste optie en omdat wij graag achter ons product willen staan raden wij dit ten zeerste af!

Alle factoren fixeren voor het hele project is dus niet realistisch. Maar er kan wel een fixed-price per Sprint worden afgesproken. Vlak voor een Sprint staan de eisen immers vast en hierdoor is er geen risico op interpretatieverschillen. Daarnaast helpt het om het Product Backlog al in een vroeg stadium zo compleet mogelijk te maken. Op deze manier kan het team al een voorlopige schatting maken over de gevraagde functionaliteit en kan dit worden meegenomen in budgetoverwegingen.

Business Value creëren

Als je op projectniveau meer zekerheid wilt creëren dan is een Fixed Budget, Fixed Time scenario een goede optie. Hierbij is het duidelijk dat het projectteam in de afgesproken periode keihard gaat werken. En dat zij samen met de Product Owner het maximaal haalbare aan Business Value gaan creëren. Dit dwingt het team om pragmatisch te werk te gaan én de klant om te zoeken naar de bedrijfswaarde in de functionaliteit die hij van het ontwikkelteam vraagt.

Ambrero Software blog - kostenbeheersing-in-scrum - kostenbeheersinggrafiek

Bovenstaand plaatje illustreert hoe dat in zijn werk gaat. Gedurende de eerste fase van het project creëren we de waarde door risico’s weg te nemen. Visievorming over functionaliteit en technologie is in deze fase heel belangrijk. Daarnaast ontwikkelen we prototypes voor de verschillende technische uitdagingen. Als de risico’s van de baan zijn dan richten we ons op de Business Value. De functionaliteit die de meeste waarde toevoegt voor de organisatie ontwikkelen we als eerste. Naarmate het project vordert en de toegevoegde Business Value per Sprint afneemt, staat het de klant vrij om op ieder moment het project af te ronden (trimming the tail).

Kostenbeheersing in Scrum; communicatie is het sleutelwoord

Kostenbeheersing is bij alle IT projecten een uitdaging, met of zonder Scrum. Het bewaken van een budget is een gezamenlijke verantwoordelijkheid. Met name bij projecten waar niet voldoende gecommuniceerd wordt loopt dit vaak fout. Je kunt de grootste valkuilen vermijden door tijdens het project voortdurend met elkaar in dialoog te blijven en elkaar regelmatig bij te praten over voortgang, verwachtingen en het budget.

Communicatie is en blijft het sleutelwoord!

Bart Matthaei

Webapplicatie laten maken; tips voor een goede voorbereiding

Stel je wilt efficiënter werken, verschillende bedrijfsprocessen op elkaar laten aansluiten of snellere service verlenen. En je zoekt de oplossing in het laten ontwikkelen van een maatwerk webapplicatie. Lees dan onze tips ter voorbereiding zodat je investering snel rendement oplevert.

1. Doelstellingen van je maatwerk webapplicatie

Wat wil je bereiken met het laten ontwikkelen van een webapplicatie? Formuleer deze bedrijfsdoelstellingen concreet en meetbaar. Bepaal ook welk budget hiervoor beschikbaar is en het rendement dat je wilt nastreven.

2. Breng werkprocessen in kaart

Een intuïtieve en gebruikersvriendelijke webapplicatie ondersteunt de processen die op de werkvloer worden gevolgd. Een gedegen analyse van de bestaande werkprocessen is een essentieel onderdeel in de voorbereiding. Kijk hierbij ook naar mogelijke verbeterpunten! Op deze manier kom je tot optimale werkwijze en een webapplicatie die hierop aansluit.

3. Toekomstplannen voor je bedrijf

Bij het laten maken van een webapplicatie is het goed om stil te staan bij de toekomstplannen van je bedrijf. Is er sprake van een voorgenomen fusie, zijn er wetswijzigingen of een explosieve groei van klanten in het vooruitzicht? Het softwarebedrijf dat voor jou aan de slag gaat kan er met deze plannen voor zorgen dat jouw webapplicatie toekomstbestendig is.

4. Betrek gebruikers bij de ontwikkeling van je webapplicatie

Het is goed om de toekomstige gebruikers van de software in een vroeg stadium te betrekken bij het laten maken van je webapplicatie. De voordelen hiervan:

  • Je gebruikt de aanwezige kennis en ervaring binnen je organisatie
  • Je krijgt een compleet beeld van de gebruikerswensen
  • Je creëert draagvlak voor de nieuwe webapplicatie binnen je organisatie

Ambrero Blog - Webapplicatie laten maken - Diagram

5. Reserveer tijd voor het gehele softwareproject

Het investeren in een intensieve samenwerking kost tijd, maar leidt tot een effectieve ontwikkeling van je software. Veel softwareontwikkelaars hanteren Agile als werkwijze. Dit houdt in dat de ontwikkeling van een webapplicatie in korte iteraties, Sprints genoemd, wordt gedaan. Sprints zijn te vergelijken met deelprojecten waarbij er telkens een stuk functionaliteit wordt geïnventariseerd, ontworpen, ontwikkeld en getest.

De klant is nauw betrokken bij een Agile ontwikkelproject, vaak in de rol van Product Owner. Jij bepaalt welke stappen er gezet worden. Het prioriteren van de ontwikkelpunten geeft je grip en controle op het project. Het vraagt wel om een investering van je tijd, gemiddeld zo’n 8 – 16 uur per week.

6. Kies passende infrastructuur voor je webapplicatie

Nadat je applicatie is ontwikkeld wil je deze beschikbaar maken binnen je organisatie of aan je klanten. Hiervoor is het noodzakelijk dat er passende infrastructuur beschikbaar is om de maatwerk webapplicatie op te draaien. De kwaliteit van de onderliggende infrastructuur beïnvloeden namelijk de beschikbaarheid, snelheid, stabiliteit en gebruikerservaring van de webapplicatie.

Je hebt op het vlak van infrastructuur meerdere opties, zoals:

  • Public Cloud (zoals Azure en Amazon)
  • Private Cloud / eigen infrastructuur
  • Infrastructuur van derden (zoals een hostingpartij of een softwareontwikkelaar)
  • Hybrid Cloud / een combinatie tussen alle bovengenoemde infrastructuren

7. Regel het beheer van je webapplicatie

Wanneer je investeert software als stevig fundament van je bedrijfsvoering dan is het ook van belang om de beschikbaarheid en continuïteit ervan te borgen. Door jezelf de vraag te stellen wat het praktisch en financieel betekent als de applicatie niet bereikbaar is heb je een goed referentiekader welk niveau van beheer en onderhoud gewenst is.

Onderzoek wat de mogelijkheden zijn in beheer en monitoring van je software. Vergeet niet om support te regelen bij eventuele problemen en vragen. Deze zaken kun je vastleggen in een Service Level Agreement met je softwareleverancier.

8. Kies een softwarepartner die bij je past

Dit klinkt heel logisch, alleen waar let je op wanneer je geen product hebt om te vergelijken? Hier een aantal punten waar je verschillende ontwikkelaars tegen het licht kunt houden:

  • Wat is de ervaring met bedrijven in dezelfde branche of met vergelijkbare vraagstukken
  • Begeleiding en kennis; wat wordt er geboden in de verschillende fases; inventarisatie, ontwerp, ontwikkeling, beheer
  • Technologieonafhankelijk; functionaliteit moet leidend zijn in de keuze van de techniek, niet de kennis van een leverancier op dit vlak
  • Cultuur en communicatie; bij een intensieve samenwerking is het goed om te achterhalen of er een klik is op dit vlak

Je kunt je zoektocht naar een webapplicatie ontwikkelaar natuurlijk ook hier starten! We kunnen je ondersteunen in alle fases van het vertalen van jouw vraagstuk naar een effectieve softwareoplossing. Daag ons gerust uit!

Bart Matthaei

De eigenschappen van een web applicatie

Steeds vaker komen we de term web applicatie tegen bij software ontwikkeling. Maar wat is het nu precies? En wat maakt een web applicatie anders dan ‘gewone’ software?

Altijd up to date met een web applicatie

Een web applicatie is een programma dat online op een webserver draait en door de gebruiker te bedienen is via de webbrowser. Een enorm voordeel is dat er geen software op de desktop geïnstalleerd hoeft te worden. De gebruiker beschikt altijd over de nieuwste versie van de web applicatie. Daardoor hoeven er ook nooit updates gedownload te worden. Een ander groot voordeel is dat de gebruiker van de web applicatie overal ter wereld (samen) kan werken. Thuiswerken is met een web applicatie dan ook een stuk makkelijker.

Verhoogd gebruiksgemak

Omdat de ontwikkelomgevingen en programmeertalen zo ver gevorderd zijn, is de kloof tussen desktopsoftware en een web applicatie vrijwel geheel gedicht. De applicatie is platformonafhankelijk voor de gebruiker, of deze nou op een Windows, iOS of Linux omgeving werkt. De applicatie draait op één beheerd systeem. Updates worden direct uitgevoerd door de leverancier van de maatwerksoftware. Hierdoor zijn de onderhoudskosten van een webapplicatie een stuk goedkoper.

Voordelige licentiekosten

De licentiekosten van de web applicatie zijn flink lager, omdat slechts per gebruiker of bedrijf betaald hoeft te worden. Vooral wanneer elke desktop een aparte softwarelicentie moet hebben, scheelt dit behoorlijk in de kosten. Zeker als medewerkers ook thuis met de webapplicatie werken. Ambrero heeft ruime ervaring in het realiseren van een webapplicaties. Een webapplicatie behoort tot ons domein van uitstekende software op maat. Zo ontwikkelden wij o.a. een web applicatie voor Ziggo, een web applicatie voor GATSO en een web applicatie voor K-Swiss. Wilt u weten of een web applicatie voor u een passende oplossing kan zijn? Neem dan contact met ons op.

Bekijk wat wij voor u nog meer kunnen betekenen op het gebied van maatwerk software en software ontwikkeling.

Bart Matthaei

Software op maat: vijf misverstanden

Steeds meer bedrijven kiezen voor eigen software in plaats van een standaardpakket. Toch horen we nog regelmatig misverstanden over software op maat van ondernemers. Daarom zetten we een aantal feiten voor je op een rij.

Misverstand 1: Software op maat is duurder

Realiteit: in vergelijking met een standaardpakket is software op maat kosteneffectief.

Softwarepakketten kosten geld, of het nou software van Microsoft, SAP, of Atos betreft. Bij de meeste standaardpakketten betaalt u in de vorm van computerlicenties of per gebruiker. Het gebruik van eigen software is ongelimiteerd. Bovendien bespaar je met maatwerksoftware de kosten van het samenstellen en uitbreiden van een standaardpakket.

Misverstand 2: Ontwikkeling van eigen software kost veel tijd

Realiteit: software op maat kan juist erg veel tijd besparen

Aangezien software wordt gemodelleerd naar uw workflow, hoef je geen tijd te verspillen aan het aanpassen van jouw werkprocessen. Met het juiste team kun je in zeer beperkte tijd software laten ontwikkelen. Ambrero ontwikkelt de meeste software op maat binnen een half jaar of korter!

Misverstand 3: Software op maat bevat meer fouten dan een standaardpakket

Realiteit: de software op maat wordt specifiek getest voor jouw organisatie

Helaas bevat elke applicatie bugs. Software die je laat ontwikkelen wordt getest aan de hand van de werkwijze die je gewend bent. Dat maakt het testproces veel specifieker dan bij standaardsoftware dat alleen algemeen getest wordt. De meeste fouten in maatwerk software komen aan het licht na de ontwikkeling van de eerste versie. Omdat het ontwikkeltraject van de software op maat dan nog in volle gang is, zijn deze bugs snel verholpen. Bovendien kunnen verbeterpunten door de korte lijnen tussen ontwikkelaar en klant razendsnel worden doorgevoerd.

Misverstand 4: Support is duur en onhandig

Realiteit: de ontwikkelaar kan direct benaderd worden, waardoor software op maat vaak goedkoper en efficiënter is.

Als je een bestaand product koopt, betaal je in veel gevallen voor support voordat je hulp krijgt bij de installatie, integratie en configuratie van het pakket. Je bent één van de klanten die in de rij staan voor hulp. En wanneer je aan de beurt bent, blijk je contact te hebben met een helpdeskmedewerker.

Wanneer je door Ambrero software laat ontwikkelen, praat je voor technische zaken direct met de programmeur. Installatie, integratie en configuratie van de maatwerk software maakt standaard deel uit van het ontwikkeltraject.

Misverstand 5: Ontwikkeltrajecten voor software op maat brengen risico’s met zich mee

Realiteit: dat klopt, daarom moet je uitsluitend in zee gaan met een betrouwbare ontwikkelaar om deze risico’s zoveel mogelijk uit te sluiten.

Het ontwikkelteam van Ambrero biedt de expertise om risico’s bij het ontwikkelen van maatwerk software vroegtijdig in te schatten. Onze kennis van diverse technieken en platformen is groot.

We ontwikkelden onder meer software op maat voor Ziggo, Sensys Gatso en Brandweer Amsterdam-Amstelland. Wil je hier meer over weten? Neem dan vrijblijvend contact op.

Bart Matthaei

Unit testing van Java applicaties

Unit testing is een belangrijk onderdeel van Agile software ontwikkeling. Vooral de grotere projecten met afgeschermde componenten lenen zich uitstekend voor unit testing.

Het idee achter Unit Testing is dat deze individuele componenten in een zgn. Test Case getest worden, door de publieke methoden binnen deze componenten met bepaalde argumenten aan te roepen, en te controlleren of het resultaat correct is. Zie ook dit wikipedia artikel.

Unit testing klinkt altijd als een erg aantrekkelijke manier om een groot gedeelte van je testprocess te automatiseren. Maar bij de implementatie van Unit Tests loop je al snel tegen problemen aan.

Utility classes zijn makkelijk te testen met JUnit. Deze classes hebben immers weinig afhankelijkheden met andere onderdelen van je applicatie. Het wordt echter lastig op het moment dat je een EJB applicatie aan het ontwikkelen bent; veel classes binnen je applicatie kunnen alleen binnen een EJB container draaien (zoals JBoss). Een goed voorbeeld hiervan is de EntityManager, die je in je Session Beans gebruikt om entiteiten op te halen uit een database. De EntityManager is implementatie specifiek, en vereist dat de applicatie binnen een container draait.

Voorbeeld

Ik geef een klein rudimentair voorbeeld van een Session Bean:

@Stateless @LocalBinding(jndiBinding="RegistrationManager") public class RegistrationManagerBean implements RegistrationManager { @PersistenceContext(unitName="MyPersistenceUnit") private EntityManager em; public boolean registerEmailWithPassword(String email, String password) { User user = new User(); user.setEmail(email); user.setPassword(password); em.persist(user); } public boolean isEmailRegistered(String email) { Query query = em.createNamedQuery("User.findUserByEmail"); query.setParameter("email", email); query.setFirstResult(0); query.setMaxResults(1); List<User> list = query.getResultList(); if(list.isEmpty()) { return false; } return true; } }

Bovenstaande class heeft 2 publieke functies: het registreren van een nieuwe e-mail adres, en het checken of een bepaald e-mail adres al is geregistreerd.

JUnit test

Een simpele JUnit test voor deze 2 functies zou er als volgt uit kunnen zien:

public class SomeSimpleTest { @Test public void testRegisterNewUser() { // Ja, alsof dit gaat werken ;-) RegistrationManagerBean rm = new RegistrationManagerBean(); boolean result = rm.registerEmailWithPassword("test@test.nl", "test123"); } @Test public void testRegistered { RegistrationManagerBean rm = new RegistrationManagerBean(); if( !rm. isEmailRegistered("test@test.nl") ) { fail("Oh no! Missing user!"); } } }

Zoals je misschien zult verwachten zal deze test case niet werken. De session bean wordt direct geinstantieerd, zonder hem via zijn interface te benaderen. Alle EJB injections zullen niet plaatsvinden, dus de EntityManager is niet beschikbaar.

De enige manier om deze Session bean correct te testen is door de tests in een EJB container te draaien. Maar dat zou betekenen dat je voor elke JUnit test een JBoss server moet starten. Het starten van JBoss duurt lang, dus zo’n situatie is verre van ideaal.

Wat je eigenlijk wilt is op een test knop drukken in Eclipse, die je hele project voor je test. En dat kan, met OpenEJB. OpenEJB is een lichtgewicht EJB container, start binnen 10 seconden op, en blijft leven gedurende je test cases. Om die JUnit tests vanuit Eclipse uit te kunnen voeren, moet je wel eerst even OpenEJB in Eclipse integreren. Ik ga hier verder niet in op de details, Google kan je hier meer over vertellen.

Zodra je JUnit en OpenEJB in Eclipse hebt gehangen, kun je JUnit tests starten. Maar daarmee zijn we er nog niet. Het volgende probleem is de Persistency laag.

Persistency?

Een methode die we bij Ambrero veel gebruiken is het developen tegen een centrale development database. Op kantoor staat een server met een MySQL installatie, waar alle databases draaien voor onze projecten. Vaak worden deze databases ook gebruikt binnen EJB projecten.

Bij het draaien van bovenstaande JUnit test wordt er een nieuwe gebruiker weggeschreven in de database. Dat zou echter betekenen dat er voor elke JUnit run vervuilende records in de database terecht komen. Je zou dit op kunnen lossen door de database na het draaien van de tests weer op te schonen, maar los daarvan is het erg onhandig om een ontwikkeldatabase te vervuilen met testrecords.

Hier zijn 2 oplossingen voor:

  • Het gebruik van een In Memory database
  • Het gebruik van een aparte Test MySQL database

Idealiter gebruik je niet geen vendor specifieke SQL functionaliteiten, maar de meeste In Memory databases (zoals Derby en h2) zijn erg gelimiteerd qua datatypen en functies. Ik loop toch vaak tegen het probleem aan dat ik dusdanig veel MySQL specifieke dingen doe, dat het onmogelijk is om de tests op een Memory database uit te voeren (een embedded MySQL database, dat zou pas een oplossing zijn!).

Los van de oplossing die je kiest, zul je voordat je gaat testen je applicatie moeten vertellen dat hij niet met de gewoonlijke database moet communiceren, maar met een specifieke test database. Hieronder laat ik een Test Case zien die de Session beans via de container opzoekt (ipv zelf instantieren) en de juiste database gebruikt.

public class SomeSimpleTest { private static InitialContext initialContext; private static RegistrationManager rm; @BeforeClass public static void setUpBeforeClass() throws Exception { Properties p = new Properties(); // Voeg nieuwe persistency informatie toe. p.put("myDatabase", "new://Resource?type=DataSource"); p.put("myDatabase.JdbcDriver", com.mysql.jdbc.Driver"); p.put("myDatabase.JdbcUrl", mysql://testserver:3306/MyProject"); p.put("myDatabase.JdbcUser", test"); p.put("myDatabase.JdbcPass", "test123!"); initialContext = new InitialContext(p); // Zoek de RegistrationManager op d.m.v. de interface rm = (RegistrationManager)initialContext.lookup("RegistrationManager"); assertNotNull(rm); } @Test public void testRegisterNewUser() { boolean result = rm.registerEmailWithPassword("test@test.nl", "test123"); } @Test public void testRegistered { if( !rm. isEmailRegistered("test@test.nl") ) { fail("Oh no! Missing user!"); } } }

Bovenstaande test-case regelt een aantal zaken voordat de tests gaan draaien.

Eerst injecteert de test-case nieuwe informatie over myDatabase (de database die gebruikt wordt in de persistency unit ‘MyPersistenceUnit’, waarnaar verwezen wordt in de Session bean) en vervolgens zoekt de test-case de RegistrationManager op in de container.

Voor meer informatie over het injecteren van database informatie, zie openejb.apache.org/3.0/openjpa. Meer lezen over onze favoriete technieken kun je lezen op onze pagina over onze technische expertise.

Bart Matthaei

Scrum: de rol van de Scrum Master

Eerder schreef ik een korte introductie over de verschillende rollen en artifacts binnen een Scrum proces. In dit artikel ga ik verder in op de planning en uitvoering van een Scrum proces.

Ook ga ik verder in op de rol van de Scrum Master. Veel mensen denken dat dit een nieuw synomiem voor Project Manager is, maar niets is minder waar.

Wat doet een Scrum Master?

Zoals ik in het vorige artikel al schreef heeft de Scrum Master geen authoriteit binnen het Team. Een Scrum Master kan dus niet als projectmanager optreden, aangezien het team zelf bepaald welke features er in een iteratie worden opgepakt (zodirect meer hierover). Een Scrum Master treedt meer op als ‘Facilitator’; hij zorgt er voor dat het team niets in de weg staat om goed werk te kunnen verrichten. Ook begeleidt hij het team, Product owner en stakeholders tijdens de verschillende meetings en zorgt hij ervoor dat Scrum correct wordt geïmplementeerd.

Hoe plan je een Sprint?

Eerst nog even een reminder over het Scrum proces:

Ambrero Blog - Scrum de rol van Scrum Master - Sprintplanning

Voordat een Sprint gestart kan worden komen het team, de Scrum Master en de Product owner samen voor een Sprint planning meeting. Tijdens deze meeting geeft de Product owner zijn visie over het project en product en geeft hij toelichting op de features op het Product backlog. Het team classificeert de features op het backlog op basis van de benodigde hoeveelheid werk.

Als dit gedaan is kan de Product Owner samen met het team bepalen welke features binnen de komende sprint opgepakt kunnen worden. Het team committeert zich hieraan. Hierin verschilt Scrum van tradionele vormen; de tijd staat vast, de features niet.

Nadat er is bepaald welke features worden opgepakt, verlaat de Product Owner de meeting en gaat het Team de verschillende features opsplitsen in taken.

Tijdens een sprint

Nadat het plannen is voltooid begint de Sprint. Elke dag wordt er een Daily Scrum meeting gehouden, waarin de teamleden elkaar op de hoogte houden over de voortgang. Elk teamlid stelt zichzelf 3 vragen:

  • Wat heb ik gisteren gedaan?
  • Wat ga ik vandaag doen?
  • Wat staat mij in de weg?

Het is de verantwoordelijkheid van de Scrum Master om eventuele facilitaire problemen die naar voren komen op te lossen.

Na een sprint

Nadat de sprint is voltooid geeft het Team een demo aan de Product Owner en eventuele stakeholders. De product owner bepaalt welke features daadwerkelijk zijn opgeleverd en plaatst eventueel items terug op het backlog.

Ambrero Blog - Scrum de rol van Scrum Master - Cartoon Ook houden het Team en de Scrum Master een retrospective meeting, waarin ze bekijken hoe de Sprint is verlopen en welke verbeteringen er doorgevoerd zouden kunnen worden.

Hierna kan het process zich weer herhalen, totdat er in de ogen van de Product owner een product release gedaan kan worden. Vaak volgt er dan nog een ‘polish’ sprint, waarin de puntjes op de i worden gezet.

Wat is de rol van de Scrum Master; conclusie

Het is de rol van de Scrum Master om het team te beschermen tegen externe invloeden en om te zorgen dat iedereen zich aan de regels houdt. Het team wordt door de Scrum Master afgeschermd van de Product owner en andere stakeholders, waardoor het zich volledig kan richten op de software ontwikkeling.

Hierdoor is het risico op ‘Scope Creep’ een stuk kleiner, waardoor het team eerder geneigd is om gestelde deadlines te halen.

Meer informatie nodig?

Onze gecertificeerde Scrum Masters hebben brede ervaring in het introduceren van Scrum binnen ontwikkelteams. Met hun een technische achtergrond kunnen ze effectief en to-the-point communiceren met de ontwikkelaars binnen uw organisatie. Lees meer over onze Agile werkwijze of neem geheel vrijblijvend contact met ons op.

Bart Matthaei

Scrum: een korte introductie

Een aantal weken geleden hebben we deelgenomen aan een Scrum Master cursus van Danube Technologies in het Radisson SAS hotel in Amsterdam. Naast de smakelijke snacks en lunches was de inhoud van de 2 daagse cursus goed geregeld.

De cursus bestond uit een theoretisch en een praktisch deel. De theorie werd goed onderbouwd met interessante historische feiten over het software ontwikkelings process en leuke anekdotes over gelukte en mislukte Agile implementaties bij kleine en grote bedrijven.

Scrum?

Scrum is een term uit de Rugbysport, waarbij de spelers in een grote groep de bal naar voren proberen te duwen.

Ambrero Blog - Scrum-introductie - scrum team

De term Scrum in de software ontwikkeling verwijst echter naar een Agile ontwikkelingmethodiek.

Scrum is een simpel raamwerk voor software ontwikkeling, waarbij het Team en het Product centraal staan. Het bestaat uit een aantal vaste activiteiten en rollen, maar het belangrijkste gegeven van Scrum is dat het team ‘self-managing’ is. Een Scrum Master is dus geen Project Manager, maar een Facilitator.

Het proces

Het werk wordt verdeeld in korte Sprints (iteraties). Elke sprint heeft een relatief korte tijdsduur, idealiter tussen de 2 en 4 weken. Het doel van elke sprint is om een potentieel verkoopbaar product op te leveren. Dat wil zeggen dat het product na elke sprint volledig getest moet zijn en alle features correct moeten functioneren.

Ambrero Blog - Scrum introductie - Sprintplanning

De rollen

Scrum bestaat uit 3 rollen: de Product Owner, de Scrum Master en het Dev-Team.

  • Product owner; verantwoordelijk voor het zakelijke aspect van het project. Bepaalt de benodigde features, prioritiseerd het backlog. Single wringable neck, oftewel, degene die de verantwoording moet afleggen.
  • Scrum Master; verantwoordelijk voor het goed functioneren van het team. Zorgt ervoor dat het team geen last heeft van externe factoren en dat eventuele drempels worden verwijderd. Heeft geen authoriteit binnen het team.
  • Het Team; multidisciplinair en bestaat idealiter uit 5 tot 9 personen. Bevat alle specialiteiten die nodig zijn om een werkend product op te leveren, dus ook designers en testers. Organizeert zichzelf.

De artifacts

Scrum bevat 3 artifacts die tijdens het ontwikkelprocess gebruikt worden.

  • Product backlog; bevat de benodigde features. De product owner is verantwoordelijk voor de prioritisering.
  • Sprint backlog; bevat de items van het product backlog waaraan het team zich voor deze sprint heeft gecommitteert. De items zijn uitgesplitst in specifieke taken.
  • Burndown chart; toont de voortgang van het project.

Volgende week zal ik een artikel schrijven dat verder in gaat op de planning en uitvoering van het process en de rol van de Scrum Master.

Update: lees meer over de planning en uitvoering in dit artikel.

Links

Korte engelstalige inleiding over Scrum
Handige handout

Bart Matthaei