Het Agile principe dat elk Scrum team een gedeelde verantwoordelijkheid heeft, blijkt in de praktijk niet zo vanzelfsprekend te zijn. Het klinkt natuurlijk mooi en aanlokkelijk, maar de waarheid gebiedt te zeggen dat de meeste mensen niet zonder meer bereid zijn om zich in te zetten voor een gezamenlijk doel. Helaas: de menselijke natuur zit toch een beetje anders in elkaar.

Het begrip 'gedeelde verantwoordelijkheid' kan zelfs remmend werken - dat wordt 'sociaal luieren' genoemd. Een minder onschuldig voorbeeld hiervan is het 'Bystander Effect': terwijl 10 mensen op de kant staan toe te kijken verdrinkt er iemand en niemand steekt een hand uit. Wat betekent dit nu voor de samenwerking in Scrum teams, waarbij als beloning wordt gesteld dat onder de streep iedereen in het team effectiever is?

Scrum is een teamsport – maar je kunt een ander teamlid pas helpen of coachen als je je eigen zaken in orde hebt. Bovendien kun je een ander teamlid pas echt aanspreken op het uitvoeren van de taken als je je eigen taken op orde hebt. Kortom: je kunt alleen voor een ander zorgen als je voor jezelf kunt zorgen. Pas daarna kan het teamgevoel groeien, en zal er een voedingsbodem zijn voor de befaamde 'gedeelde verantwoordelijkheid' in Scrum. Lees meer over dit onderwerp in dit artikel met de veelzeggende titel: Gedeelde verantwoordelijkheid in een Scrum team is geen vanzelfsprekendheid.

Gedurende mijn Agile Scrum training sessies zijn er soms momenten dat ik de deelnemers vertel dat een bepaalde aanpak voortkomt uit mijn eigen praktijkervaring, en geen onderdeel is van de 'spelregels' zoals gedefinieerd in de Scrum Guide - waarin staat dat de omschreven Scrum rollen en regels onveranderbaar zijn (...). Derhalve moet ik deelnemers op het hart drukken om dergelijke afwijkende practische oplossingen 'tijdelijk te vergeten' als ze het Scrum certificerings examen afleggen.

Iedere keer als dat gebeurt, voel ik me ongemakkelijk. Nadat ik uitgebreid de essentie van het Agile gedachtengoed heb uitgelegd, is het in mijn ogen niet logisch een methode te presenteren die op de letter moet worden gevolgd. Agile is een prima benadering, maar ik hou me verre van kokerblik, dogma, of soms zelf religieus aandoend fanatisme... Naar mijn gevoel is Scrum niet een gereserveerde term voor een vooraf gedefinieerde manier van werken of een bepaalde 'school' - Scrum is zeker niet de enige ware weg. Lees meer in dit (engelstalige) artikel met de veelzeggende titel: Beware of the Scrum Police!.

Een regelmatig terugkerende uitdaging voor een Scrum team met leden van verschillende disciplines (b.v. hardware, software, mechatronica, firmware, optica, etc.) is de relatieve schatting van verschillende product backlog ites op basis van Story Points. Zeker voor een startend multidisciplinair team, kan het toepassen van Story Points lastig zijn, aangezien het moeilijk is een een referentie-punt te vinden dat geschikt is voor alle betrokken dsciplines. Voor je het weet zit je appels met peren tevergelijken als je de vershillende items op dezelfde schaal wilt scoren. In dit (engelstalige) artikel krijg je tips and tricks aangereikt om deze uitdaging aan te gaan.

Steeds meer organisaties overwegen over te stappen op Scrum, een effectieve werkwijze die al zo'n 15 jaar wordt toegepast in software ontwikkeling. Met name multidisciplinaire bedrijven, waarbij software niet de core business vormt, snuffelen de laatste tijd aan deze nieuwe manier van werken. Helaas bestaan er nogal wat misverstanden over de essentie van deze werkwijze. Dit leidt tot aarzelingen om met Scrum te starten, vaak ten onrechte! Dit artikel belicht een aantal veel voorkomende mythes en misverstanden over de Scrum manier van werken - ter leering en de vermaeck.

Er is een nieuwe planningsmethode speciaal voor communicatie professionals: Reflectieve Communicatie Scrum (RCS), in 2013 gelanceerd door emeritus hoogleraar communicatiewetenschap Betteke van Ruler. De naamgeving doet vermoeden dat het om een Scrum variant gaat - maar zoals we vaker bij modificaties of aanpassingen van Scrum zien, heeft het resultaat in essentie nog maar weinig met Scrum te maken. Het is niet ongewoon om Scrum aan te passen aan staande processen, of in te bedden in de bedrijfcultuur - maar dit moet altijd gebeuren vanuit het inzicht hoe de verschillende Scrum onderdelen geraffineerd in elkaar grijpen. Haal je één onderdeel weg (zoals in RCS de Product Owner, en daarmee ook de Product Backlog met User Stories), dan kan dit desastreuze gevolgen hebben voor de werkwijze als geheel.

Naast een onderbouwde kritiek op het ontbreken van essentiële zaken uit het Scrum framework, is de rode draad in dit artikel de vraag naar de onderbouwing van RCS. Want de redenen om zo ingrijpend van Scrum af te wijken worden nergens expliciet gemaakt, hetgeen uiteraard vragen oproept. Dit wordt nog versterkt door uitspraken zoals: 'communicatie is ingewikkelder dan het maken van software', of 'scrum is teveel naar binnen gericht'. Afijn, oordeelt u zelf - en wellicht kunt u een bijdrage leveren aan de discussie waarom scrum in zijn oorspronkelijke en onderhand volwassen vorm niet gewoon kan worden toegepast in het communicatie vakgebied - net zoals in een hele reeks andere (non-software) domeinen.

In het in 2001 verschenen artikel "Moving Upward in a Downturn", doet Darrell Rigby uit de doeken hoe bedrijven een economische neergang kunnen benutten in plaats van eraan ten onder te gaan. Het artikel heeft destijds weinig aandacht gekregen, want na 2001 volgden zeven vette jaren, en wie maakt zich dan druk om een recessie? Nu de angst voor een wereldwijde economische neergang snel om zich heen grijpt, lijkt de tijd rijp om Rigby's artikel nog eens onder de loupe te nemen.

De aanbevelingen in het artikel van Rigby lijken onverkort van toepassing te zijn op organisaties met software ontwikkeling als core business. Uiteraard worden er al veel langer pogingen ondernomen om tot een meer efficiente aanpak van softwareproductie te komen, iets dat met name speelt in de ontwikkeling van complexe, software-intensieve apparaten in een multidisciplinaire omgeving. Toch is het opvallend dat alle, door Rigby genoemde punten terugkomen in de Agile aanpak, met name in de Scrum methode voor project management. De voorliggende vraag is of het aanbeveling verdient om - juist in tijden van recessie – anticyclisch te investeren in de Agile Scrum manier van werken. Dit artikel geeft het antwoord op die vraag.

Indien u bij aanvang van een project van enige omvang en complexiteit alle relevante variabelen kent, alle consequenties van belangrijke beslissingen kunt overzien, (blijvend) kan beschikken over de juiste informatie en benodigde middelen (mensen,tijd en geld), en dus de voortgang en de uitkomst van het gehele traject nauwkeurig kunt voorspellen – dan is dit artikel niet interessant voor u. Ik neem namelijk afstand van het idee dat een project alleen kans van slagen heeft wanneer het controleerbaar is, en dat er methodiek bestaat die ervoor zorgt dat de geest van onvoorspelbaarheid weer terug in de fles kan worden gebracht.

De tijd van de volledig mechanische eenarmige bandiet ligt al weer ver achter ons. Embedded software vormt tegenwoordig een essentieel onderdeel van een gokkast. Dit artikel schetst een beeld van de recente ontwikkelingen bij JVH Gaming Products op het gebied van softwareontwikkeling voor kansspelen.

Het maken van software gaat zelden van een leien dakje. Veel producenten van software-intensieve apparaten willen de kwaliteit van de afgeleverde producten structureel verhogen. De daarvoor benodigde investering in menskracht kan vaak niet worden gedaan, omdat een aanzienlijk deel van de engineers druk bezig is om de zaak bij de klant draaiend te houden. In de meeste ontwikkeltrajecten is nauwelijks tijd voor bezinning. Er wordt zo druk gezaagd, dat er geen tijd is om de zaag te slijpen. In dit artikel, eerder verschenen in het tijdschrift Bits &Chips, wordt aangegeven hoe een structurele verhoging van de productiviteit van het ontwikkelteam de ruimte verschaft om uit die spiraal te komen.

De vermeende communicatieve handicap van ICT'ers blijft een dankbaar onderwerp van discussie. ICT'ers vormen zelfs een veiligheidsrisico van binnenuit vanwege hun introvertheid, zo lezen we op de voorpagina van Computable. Door hun cognitieve benadering van problemen verloopt de besluitvorming minder adequaat. Dit artikel plaatst vraagtekens bij deze nogal eenzijdige benadering. Gedragspatronen van de ICT'er zijn niet los te zien van het hardnekkige paradigma dat de software industrie al tientallen jaren in z'n greep heeft. Er is een paradigmaverschuiving nodig om het gedrag van ICT'ers blijvend te veranderen. Gelukkig wint het Agile gedachtengoed snel aan populariteit, een hoopvol teken dat deze paradigmaverschuiving al in gang is gezet. Lees hier meer over de evolutie van de ICT, geinspireerd door het gedachtengoed van Claire Graves en zijn model van 'value systems'.

De heilige graal van scrum is de oplevering van werkende software in een kort tijdbestek. Als de focus op functionaliteit overheerst, kan het project gemakkelijk veranderen in een ‘Feature Factory’, hetgeen het risico met zich meebrengt dat architecturele tekortkomingen zich gaan opstapelen, en dat de 'technical debt' een ongewenste impact heeft op de systeem prestaties en de product kwaliteit. Dit risico kan worden verminderd door zorg te dragen voor de juiste architecturele basis voor het te ontwikkelen systeem. Onderdeel van een agile manier van werken is het opnemen van een architecture spike om architecturele onderwerpen structureel aandacht te geven. Naast de tastbare en 'potentially shippable features' dient de aandacht gericht te worden op de werkelijke waardevermeerderende aspecten van het software systeem. In dit artikel wordt de 'spike' gepresenteert als een pragmatische wijze om kritische product kwaliteitsattributen te borgen, als onderdeel van de creatie van werkelijke waarde voor klanten en gebruikers van het opgeleverde systeem.

De opkomst van de agile methodiek heeft stevig aan de boom geschud van architecten die zich veilig waanden in de ivoren toren. Een nieuwe generatie van architecten dient zich aan.
Architectuur is in de sommige agile kringen controversieel. Er worden stevig discussies gevoerd of er vooraf een design gemaakt moet worden, tot welk detail, en hoe wordt voorkomen dat de architectuur de kant opgaat van een BDUF: de grote boze wolf van hard-core agilisten? Inderdaad zijn de traditionele architectuur processen topzwaar en bureaucratisch te noemen, niet zelden verantwoordelijk voor nodeloos ingewikkelde en tijdvretende ontwikkeltrajecten. Toch worden agile methodes in architecten kringen gezien als architectureel zwak, niet geschikt voor het opleveren van grote, multidisciplinaire software-intensieve systemen in complexe omgevingen. Agile Architecting is een poging om het beste van beide werelden te combineren, zoals verder uitgewerkt in dit artikel.

In meer traditionele kringen overheerst de opinie dat er in software ontwikkel trajecten altijd een spanning is tussen tijd, geld en kwaliteit. "You can't have all three", is nog altijd een wijdverspreide overtuiging in de wereld van software engineering, ook bekend als de fameuze 'devil's triangle'. Een vaak gehoorde mening is dat snijden in het budget onvermijdelijk resulteert in een lagere kwaliteit, of dat het strikt bewaken van product kwaliteit op gespannen voet staat met de project planning.

Het gebeurt maar zelden dat kwaliteit expliciet wordt gebruikt om een problematisch project weer op de rails te krijgen. Bestaande methoden van project planning concentreren zich vooral op tijd en kosten, en nemen kwaliteit niet mee in de afweging. In dit artikel breekt Erik Philippus een lans voor een belangrijkere rol van software product kwaliteit. Gebaseerd op zijn eigen ervaring als software en systeem architect, en als consultant in diverse software ontwikkel projecten, verdedigt hij de stelling dat het juist de afwezigheid is van de juiste kwaliteit die een hoop geld geld kost, meer dan de kwaliteitszorg zelf kost.

De meeste organisaties komen door ernstige legacy problematiek in een negatieve spiraal terecht: steeds meer resources moeten worden gespendeerd aan het onderhouden van een obsoleet software systeem. Naast het herstellen van defecten, is de investering in nieuwe features nauwelijks kostendekkend te maken. Vroeger of later zal dit de organisatie in aanzienlijke problemen brengen, aangezien het ontwikkelingsbudget voornamelijk opgaat aan correctief onderhoud in plaats dat het wordt gespendeerd aan innovatie. Dit artikel beschrijft een pragmatische, incrementele aanpak voor de renovatie van legacy systemen.

Complexiteit is een hot issue als het gaat om de ontwikkeling van ingewikkelde, software-intensieve systemen. Gebaseerd op het reductionistische wereldbeeld, trachten vrijwel alle ontwikkelmethodieken complexiteit krampachtig onder de duim te krijgen. Complexiteit wordt gezien als onvermijdelijk gevolg van software evolutie, en op allerlei manieren moet worden voorkomen dat ongewenste complexiteit roet in het eten gooit. Dit is een vorm van doorgeschoten controle-denken, gebaseerd op het idee van de 'maakbare wereld'. De realiteit is echter dat turbulentie en onzekerheid een normaal en dagelijks onderdeel vormen van software projecten. Sterker nog: complexiteit is eerder een voorwaarde voor, dan een gevolg van evolutie!

In dit artikel wordt het gedrag van complexe systemen toegelicht aan de hand van de 'complex systems theory'. Het is een uitnodiging voor systeem architecten om eens een andere invalshoek te kiezen voor het bouwen van complexe software systemen.

Te pas en te onpas worden projecten in de civiele bouwwereld als analogie opgevoerd om software ontwikkel trajecten te verduidelijken. Het blijkt dat bij het al te gretig overnemen van concepten uit de fysieke bouwwereld, er nog wel wat addertjes onder het gras kunnen zitten. Lees in dit artikel meer over het (al dan niet terecht) toepassen in de IT van een metafoor uit de bouwwereld: de 'software bouwmanager'.

Hoe het een bouwproject kan vergaan zonder duidelijike doelstelling, wordt op wonderlijke wijze geillustreerd door het Winchester Mystery House. Elk systeem heeft een architectuur, maar in dit geval kost het enige moeite om de logica te ontdekken... Lees hier meer over dit wonderlijke project.

Uiteraard zal een architect oog moeten hebben voor (on-)gewenste gedragspatronen 'op de ontwikkelvloer', maar dat laat onverlet dat een architect ook in staat moet zijn hand in eigen boezem te steken. Het kunnen reflecteren op de invloed van het eigen handelen, is kenmerkend voor het volwassen worden van de software architect. Ter kennismaking en aanmoediging van dit proces volgen hier een aantal gedragspatronen 'ter leering ende vermaek'. Lees in dit artikel over de spiegel van/voor de architect.

Bij discussies over de ontwikkeling van software voeren technische en rationele zaken gewoonlijk de boventoon. Dit artikel is bedoeld om software ontwikkeling, in het bijzonder de relatie tussen software architectuur en de kwaliteit van software producten, in een breder kader te plaatsen – een kader waarin een plaats is ingeruimd voor de menselijke maat.

Erik Philippus is jarenlang columnist geweest voor het tijdschrift Bits & Chips. Hieronder een lijst met artikelen die in dit technische tijdschrift zijn verschenen:

• Op de rand van de chaos
• De overeenkomst tussen planologie en architectuur
• Rijkswaterstaat architectuur
• Waar is de architect gebleven?
• De agile parachute
• Een juiste diagnose
• Het huwelijk tussen agile en architectuur
• Zin en onzin van het lagen model
• Het belang van een informeel netwerk
• Hoe verkoop ik mijn architectuur?
• Door los te laten krijg je meer grip