nl en nl en en en en nl en en ceb en en nl pt it en en en en en en en en en en nl en en en nl nl en nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl nl fr en nl fr nl nl fr nl nl nl nl en nl nl fi ca nl en nl
Bij Orange Juice hebben we er enkele jaren geleden voor gekozen om een agile (behendig, vlot) werkmethodiek te hanteren. Hiermee zijn we in staat om samen met onze opdrachtgevers de oplossingen nog flexibeler en efficiënter te realiseren door sneller te reageren op gebruikersfeedback en ontwikkelingen in de markt, zowel commercieel als technisch.
Voor het managen van de iteratieve en incrementele software ontwikkeling gebruiken we Scrum… en in de dagelijkse praktijk komen we daarbij enkele uitdagingen tegen.
Met Scrum werken zelf-organiserende, multidisciplinaire development teams met vereende inspanning aan een gezamenlijk doel. Hieronder heel kort een omschrijving van het Scrum proces.
Er is een lijst met werkzaamheden (backlog) waarvan een afgebakende hoeveelheid in een cyclus van twee weken (sprint) wordt verwerkt.  Bij het verwerken van de werkzaamheden, in een vooraf door de producteigenaar vastgestelde volgorde, doorloopt ieder item een aantal stadia; ToDo, Doing, Review en Done. De werkzaamheden worden gecontroleerd en getest door bij de review een document met richtlijnen te hanteren (Definition of Done) die mede bijdraagt aan de kwaliteitscontrole. Met een vast aantal bijeenkomsten wordt het proces in goede banen geleidt;
Refinement - inventariseren van de werkzaamheden.
Planning – vaststellen hoeveel werkzaamheden er in de sprint kunnen worden verwerkt.
Demo – demonstratie van gerealiseerd werk aan alle belanghebbenden.
Retro – retrospective, evaluatie van het verloop van de afgelopen sprint en verbeteringen voor toekomstige sprints.
Daily – dagelijkse bijeenkomst (standup) waarbij kort de voortgang en afhankelijkheden worden doorgenomen.
Het gehele proces is uitgebreider met diverse rollen, regels , etc. Zie Scrum Alliance.
Uitdaging #1 Variërend aantal projecten per team
Bij Orange Juice is er een grote verscheidenheid aan werkzaamheden; grote en kleine opdrachtgevers, grote en kleine projecten, uitbreidingen aan bestaande webapplicaties en onderhoudswerkzaamheden. De development teams werken niet per definitie voor een specifieke opdrachtgever of aan een specifiek project, maar een sprint kan bestaan uit werkzaamheden voor verschillende projecten en opdrachtgevers. Er zijn een aantal uitdagingen die hierbij ontstaan;
Overkoepelend bepalen van planning en prioriteit tussen de verschillende projecten.
Toewijzen van werkzaamheden aan een team. Hierbij spelen diverse factoren een rol met om te beginnen uiteraard planning en capaciteit. Maar ook het uitwisselen van projecten tussen teams ter bevordering van kennisoverdracht versus verwerkingssnelheid wanneer de werkzaamheden worden opgepakt door het team dat al ervaring heeft met het desbetreffende project.
Wanneer de opdrachtgever actief deelneemt aan het scrum proces maar de sprint is aangevuld met enkele items voor een ander project, dan komen deze items vanzelfsprekend niet terug in de refinements en demo’s met deze opdrachtgever. Ze zullen separaat nog moeten worden behandelt, mogelijk zijn er aanvullende refinements en demo’s. Uiteindelijk zal dit overall meer tijd kosten en is kritisch omgaan met de tijd voor diverse bijeenkomsten cruciaal.
Idealiter werkt ieder team volledige sprints aan een enkel project.
De (marketing) strategie van onze opdrachtgevers is bepalend in de uitwerking van alle facetten van een e-commerce oplossing, deze strategie stellen we desgewenst samen met hen vast. De vertaling van de strategie naar de e-commerce oplossing komt tot stand in het ‘concept’, waarbij o.a. design, interactie en technische architectuur door experts wordt uitgewerkt en dient als briefing voor de realisatie.
De uitdaging bij ieder project is vaststellen in welke mate het concept wordt uitgewerkt.
Onder andere de grens tussen design (huisstijl, mood, interactie) en webdesign (visuele uitwerking van het concept in een styleguide). In hoeverre wordt het concept uitgewerkt waarbij interactie invloed kan hebben op technische functionaliteit, bijvoorbeeld in de ondersteuning van verschillende devices (mobiele telefoon, tablet, desktop)? In hoeverre wordt de technische architectuur vooraf bepaald terwijl in er in komende sprints mogelijk nieuwe functionaliteit wordt geïntroduceerd waarbij een gewijzigde structuur noodzakelijk blijkt?
Het voordeel van vooraf een concept verregaand uitwerken is dat de kaders van het project al helder zijn voor het development team en er niet tot nauwelijks nog onduidelijkheid kan zijn over vorm en functie tijdens de realisatie. Hierbij bestaat echter het risico dat er onderdelen van het concept zijn die tijdens de realisatie door bijvoorbeeld een technische reden slecht haalbaar blijken. Indien het concept in mindere mate is uitgewerkt stelt dit hogere eisen aan het development team die tijdens de realisatie in grotere mate zelf de strategie van de opdrachtgever moeten vertalen tijdens de realisatie, dit vereist veel meer kennis, kunde en ervaring.
Afhankelijk van opdrachtgever en project is het zoeken naar de juiste balans in de uitwerking van  concepten. Bepalende factoren hierbij zijn o.a. de mate waarin de opdrachtgever … de strategie al heeft bepaald … het concept al (deels) heeft uitgewerkt …. deelneemt aan het scrum proces … de ‘productowner’ rol invult … het project agile aanpakt en iedere sprint bijstuurt.
Uitdaging #3 Specialisten per team
De development teams bij Orange Juice bestaan uit webdesigners, frontend- en backend developers. Binnen deze verschillende disciplines is er nog wel sprake van expertise, zoals bijvoorbeeld in de discipline frontend de expertise scripting (clientside development d.m.v. JavaScript).
Met individuele expertises komt de uitdaging dat de expertise benodigd is voor verschillende projecten, mogelijk in verschillende teams (aangenomen dat niet altijd de luxe bestaat om meerdere individuen te hebben voor alle expertises).
De vraag is vervolgens of het project moet worden ondergebracht in het team met de desbetreffende expert of in het team met beschikbare capaciteit en de expert die overstapt naar dat team?
Beide scenario’s zijn al eens in praktijk gebracht, maar er is nog geen duidelijke voorkeur.
Wisselingen in de team samenstelling heeft onder andere impact op velocity (gemiddelde hoeveelheid werk per sprint), dit maakt het lastig tot een gedegen spint planning te komen. Het werk altijd onderbrengen in het team met de expert zorgt ervoor dat het team veel vergelijkbare projecten realiseert. Met het risico dat dit eentonig wordt ervaren en er weinig tot geen overdracht is van (project)kennis tussen verschillende teams.
Momenteel wordt er een nieuw scenario in de praktijk gebracht waarbij een expert geen lid is van een team, maar meer als extern ‘task force’ wordt ingezet. Grote uitdaging hierbij voor het team is om commitment af te geven op de sprintplanning, aangezien er sprake is van een externe afhankelijkheid (items in de sprint kunnen pas worden afgerond indien een niet-teamlid bepaalde werkzaamheden afrondt).
Voorlopige conclusie: meer experts gezocht
Heb je na het lezen vragen of opmerkingen over dit onderwerp? Neem gerust contact met mij op om van gedachten te wisselen. Bel  +31 (0)26 327 40 45 of stuur een e-mail naar dion@orange-juice.nl.