Veel van wat wij it’ers doen, vinden we belangrijk. Of het nu infrastructuur, back-end development, front-end development, integratie, security, beheer of iets anders is, we zullen ons expertisegebied altijd in het midden van de PowerPoint plaatsen, met de rest er wat kleiner omheen. Logisch, toch?
Onze it-activiteiten zijn het middelpunt waar ons hele leventje omdraait, en we bekijken alles om ons heen vanuit dat oogpunt. Vaak ontwikkelen we deze dingen ook geïsoleerd van elkaar. Op zich is daar, technisch gezien, niets mis mee: met de contract first-aanpak zou het goed moeten komen. Maar vaak missen we hierdoor wel de essentie. En de bijbehorende passie. Het wordt een soort fabriekje met een paar slecht op elkaar aangesloten lopende banden waarvan niet duidelijk is waarvoor het dient.
Wat en hoe weten we wel
Hierdoor missen we meestal ook het mooiste resultaat. Het beheren en zo goed mogelijk in de lucht houden van de eindoplossing is daarbij in negen van de tien gevallen ook niet goed belegd. Hierdoor kan de gebruikerservaring ernstige deuken oplopen. De verantwoordelijkheid voor de oplossing als geheel en de verschillende onderliggende componenten blijkt dan een complex verhaal. Om het nog maar niet te hebben over ontwikkel-, implementatie- en exploitatiebudgetten en bijbehorende tijdsbesteding. Dit moet beter.
It’ers zijn techneuten. Wij concentreren ons op wat we moeten implementeren en hoe we dit technisch gezien het best kunnen doen. Meer vragen we ons ook meestal niet af, want al druk genoeg. Een watervalaanpak voor het ontwikkelen en implementeren van oplossingen werkt dit in de hand. De meeste oplossingen worden op dit moment op die manier gerealiseerd. Hoe vaak we ook horen dat bedrijven scrummen. Maar scrummen is meer dan sprints vullen.
Maar waarom?
We kennen ondertussen natuurlijk allemaal Simon Sinek en zijn beroemde gouden cirkel. De essentie hiervan is dat je altijd moet beginnen met the why. Waarom ontwikkelen we deze oplossing? Waarom geloven we er in? Wat is, behalve dat er geld mee verdiend wordt, het hogere doel?
Dit is de kern van de rol van de product owner. De product owner moet als hij wakker wordt gemaakt direct kunnen vertellen wat het waarom van zijn oplossing is. Het team moet dit beleven. En elke beslissing die wordt genomen over de prioriteit, functionaliteit, architectuur en gebruikerservaring moet dit als belangrijkste uitgangspunt hebben.
Belangrijk hierbij is dat het hele team zich verantwoordelijk voelt voor de oplossing en dat er geen zaken over de schutting gegooid worden. Lost in translation is het grootste gevaar met de watervalaanpak. Met een inspiratieloos product als gevolg.
De onvermijdelijke ijsberg
Uiteindelijk draait het allemaal dus om de business-app en met name zijn bestaansrecht. En met business-app bedoel ik functionaliteit in de breedste zin van het woord, in de vorm van een app, portal, applicatie, api, het maakt niet uit. Maar het draait dus om die app.
De app is ook waar budget voor is. De app heeft een product owner. Maar de app kan alleen bestaan bij de gratie van een goede onderliggende architectuur. Data. Integratie. Api’s. Platform. Het deel onder water, wat niet sexy is en wat ook je budgetten opvreet en waarop je schip kapot kan lopen; de onvermijdelijke ijsberg.
Door de app niet alleen als front-end te zien, maar als een geheel van componenten dat de verschijningsvorm en gebruikersfunctionaliteit mogelijk maakt, en waarbij al deze componenten door hetzelfde scrumteam ontwikkeld worden, kan het geheel als de app worden gezien. De app met de sterke product owner, de visionair die ook het bestaansrecht en dus het waarom kan verdedigen, en dus ook de bijbehorende budgetten en tijd. Inclusief de benodigde onderliggende motor, die zorgt dat de app echt kan vliegen. De app die door een team ontwikkeld wordt. De app die als team gedragen wordt. De app die de meeste waarde toevoegt. De app die continue evolueert. Of zelfs een revolutie ontketent. De app die het verschil maakt.
