Open for business
Het Coronavirus
Aangepaste dienstverlening
Categorieën

Common sense of in de Scrum – aandachtspunten bij softwareprojecten

Auteur
Thierry Lammers
Datum
februari 27, 2017

In AG Connect verscheen onlangs een artikel ‘de schone schijn van Scrum’. Het beschrijft de regelmatig voorkomende problemen die de Scrum aanpak met zich meebrengt. Conclusie: het zit hem in het groepsproces.rugby_scrum_1904

Het IT-landschap wordt met regelmaat geteisterd door nieuwe hippe acroniemen of methodieken. Voor de softwarewereld en de consultants die daar om een of andere reden omheen cirkelen is het heel erg hip om met Scrum bezig te zijn. The all new way of software development.  Vaak wordt deze methodiek toegepast om apps te ontwikkelen. Net alsof het ontwikkelen van apps echt zóveel anders is als ieder andere softwaretoepassing. Nou beste lezers, dat is het zeker niet, apps = software, software = sourcecode, sourcecode wordt door programmeurs gemaakt en de programmeurs moeten goede afspraken met de klant maken om tot een prettig eindresultaat te komen. Alles wat tussen developer en klant gebeurt is proces. Scrum moet dat proces nog makkelijker maken. Toch?

Van Scrum wordt verwacht dat het traject tussen programmeur en klant automagisch, in een gezellige hippe sfeer, ondersteund met vergezochte rituelen (pokeren…), tot ‘a walk in the park’ wordt omgetoverd. Helaas lopen bedrijven die vol in de Scrum duiken toch wat blauwe plekken en kneuzingen op. Apps worden niet of laat opgeleverd want een strakke planning, gebaseerd op afgesproken functionaliteit, heeft geen sterke focus, verwachtingen vs verwachtingsmanagement vindt niet goed plaats (ondanks dat er wel een daily stand-up wordt gedaan). Software ontwikkeling blijft mensenwerk, communicatie is zó noodzakelijk. Los daarvan heb je ook te maken te maken met diverse rollen, project (deel)opleveringen met verschillende snelheden en doorlooptijden etc. Een project bestaat vrijwel nooit uit projectsporen die allemaal netjes in mootjes van 2 weken zijn te hakken zodat het aan het eind van de sprint alles strak op elkaar aansluit. Er ontstaat dus vaak een inefficiënte (en dus kostbare) gatenkaasplanning van de teamleden.

BLAUD heeft in het development team veteranen en junioren rondlopen en ze leveren allemaal, in een goede samenwerking, succesvolle softwareproducten op. We hebben gaandeweg onze eigen ‘common sense’ aanpak ontwikkeld die ik graag met u deel. Het succes achter deze aanpak (zonder verdere hippe naam) zit hem volgens mij in de volgende aandachtspunten:

  • Het eindresultaat is voor de klant en dus het ontwikkelteam het hoogste doel.
  • Verslik je (samen met de klant) niet in een te groot project. Ga samen op zoek naar het ‘minimal lovable product’ voor de eerste release, de tweede release etc. etc. Klein maken en vooruitdenken dus!
  • Visualiseren zoveel en zo vroeg mogelijk, zelfs in de offertefase doen we bij BLAUD al aan verwachtingsmanagement met goede functionele en grafische beschrijvingen.
  • Ontwerp en ontwikkel vanuit een architectuur die in staat is om op te schalen.
  • Bekijk het ontwerp en de ontwikkeling ook vanuit een economisch perspectief. De prijs/prestatie/houdbaarheidsdatum van de oplossing moet afgestemd zijn. Wil je een Volkswagen Polo, Audi A6 of een Porsche 911? Alles kan!
  • Lever enkele keren tussentijds en snel op en bespreek samen met de klant het resultaat. Met compacte projecten kan dat en ben je in staat gewijzigd inzicht met beperkte/geen extra kosten door te voeren.

Succes met de projecten!

Klinkt goed,
Vertel me meer!
Bel me terug voor meer informatie.




--> --> --> --> --> --> --> --> --> --> --> --> --> -->