De meeste Agile-implementaties hebben de muur tussen development en business al geslecht, het logische vervolg is om ook de kloof tussen development en beheer te dichten, zodat op die manier een organisatie in staat is om software snel in productie te nemen en effectief te beheren.
Het nut
Organisaties zien dat er veel geld te besparen valt als de ontwikkel- en beheerorganisatie op elkaar zijn aangesloten. Doordat organisaties met Agile-ontwikkelingsmethoden snel en wendbaar wensen van de business kunnen vertalen naar een systeemoplossing, maar vervolgens veel tijd kwijt zijn met het in productie nemen en beheren van de software, is het paard een beetje achter de wagen gespannen.
Als de beheerorganisatie niet in staat is iteratief software in productie te nemen, loopt men nog steeds vertraging op. Devops is een manier om de beheerorganisatie bij het voortbrengingsproces te betrekken door ze een integraal onderdeel van het proces te maken. Hierdoor kan de keten sneller software in productie nemen, worden kosten bespaard en dit kan een groot concurrentievoordeel zijn binnen een markt waar een korte time-to-market van belang is.
Een andere reden voor bedrijven om over te stappen naar Devops is dat de eerder aangehaalde 'wall of confusion' een hoop frustraties oplevert die ten koste gaan van productiviteit, samenwerking en werksfeer. Als deze nadelen kunnen worden weggenomen, en hierdoor medewerkers meer werkplezier ervaren, is de opzet in ieder geval gedeeltelijk geslaagd.
Adoptie
Er zijn een aantal grote bedrijven in Nederland die Devops hebben aangenomen als voorkeursmethode voor softwareontwikkeling, het in productie nemen en beheren van software. Voordat je begint, moet eerst het Agile-transformatie- en Scrumproces op orde zijn, omdat de complexiteit van de organisatieverandering anders teveel toeneemt. Naast it en business (wat je in een 'standaard' Agile-transitie doet) moet namelijk óók de beheerorganisatie transformeren. Daarnaast is het belangrijk dat het Agile-gedachtengoed volledig is geland binnen de organisatie. Het is beter klein te beginnen en langzaam uit te bouwen om de organisatie te laten wennen en leren. Hierdoor kan je de feedback die je ontvangt gebruiken om het transitieproces te verbeteren waardoor een volgende transitie nog succesvoller kan zijn. Oefening baart kunst.
Vereiste veranderingen
Iedere organisatie zou in principe met Devops kunnen werken, mits je bereid bent de organisatie (ingrijpend) te veranderen. Het doel moet niet zijn op korte termijn een time-to-market probleem op te lossen, maar wel om een it-organisatie vorm te geven die voortdurend in staat is in samenspraak met de business systeemwijzigingen door te voeren en te beheren. Dit kan het verhelpen van incidenten zijn, of het toevoegen van (nieuwe) functionaliteit.
Om DevOps correct te implementeren zijn er op drie gebieden veranderingen nodig:
Meten van cultuurverandering
Als je een cultuur wilt veranderen moet je goed kijken hoe je het resultaat gaat meten en beoordelen. Wat gemeten wordt beïnvloedt het gedrag en vice versa. Het succes van individuen en groepen dient te worden gemeten binnen de context van het succes van de gehele development-beheer cyclus. Voor veel organisaties betekent dit een verandering van kpi’s per silo en/of afdeling vaststellen, naar kpi’s per proces vaststellen. Het is belangrijk dat aan iedereen die deel uitmaakt van een proces duidelijk wordt gemaakt wat hun bijdrage aan het uiteindelijke doel is en hoe hun activiteiten zich verhouden tot andere activiteiten binnen het proces.
Geïntegreerde processen
Binnen Devops dient de gehele development-beheer cyclus als één geïntegreerd proces te worden gezien en vormgegeven. Waarbij het ook als één geheel moet worden gemanaged. Hierbij kunnen verschillende segmenten of subprocessen hun eigen methodes hanteren zolang deze maar samen kunnen worden gevoegd tot één proces op hoofdniveau. In de praktijk betekent dit dat men het eigen 'eilandje' moet loslaten. Dit is niet gemakkelijk en zal met weerstand gepaard gaan omdat men bepaalde macht op zal moeten geven ten gunste van het grotere geheel.
Geïntegreerde tooling
Hier lijkt de Devops-discussie zich het meest op te richten. Dit is niet verwonderlijk aangezien het een bijna natuurlijke reflex van techneuten is om meteen een discussie over tooling te starten als er een probleem moet worden opgelost. Want er moet toch een ‘tooltje’ zijn dat helpt dit proces vlot te laten verlopen? Het is belangrijk dat alle individuele tools samenwerken om als keten van tools de procesketen volledig te ondersteunen. Tools moeten voorzien in het automatiseren van handmatige taken (testen, deployment, monitoring, et cetera), beschikken over een software library die onder versiebeheer staat, zodat men in de hele keten met dezelfde gedeelde software configuratie werkt. Daarnaast moet het mogelijk zijn om softwaresystemen zo te modelleren (alle componenten, policies en dependencies zijn beschreven) zodat deze op ieder moment kunnen worden geproduceerd zonder dat dit conflicten geeft met andere omgevingen. Vaak is het beheer binnen organisaties ook van elkaar gescheiden (functioneel applicatiebeheer, technisch beheer, infrastructuur en werkplekken), wat het extra lastig maakt om flexibel met omgevingen om te gaan of om tools uit verschillende domeinen aan elkaar te koppelen. Als organisatie moet je je ervan bewust zijn dat hier veel werk moet worden verricht om alle neuzen dezelfde kant op te krijgen.
Sander de Jonge, Agile-expert bij Bartosz ICT
Reacties
Bij de eerste zin begint het al te kriebelen, ontwikkeling loopt namelijk ook nog weleens voor de muziek uit zoals we kunnen zien bij veel projecten waarbij de front-office niet aansluit op de back-office. Integraal beheer gaat om een attitude vanuit de organisatie en niet de zoveelste belofte van een verzameling tools.
Natuurlijk kunnen we veel activiteiten binnen het beheer automatiseren mits er bij ontwikkeling al rekening meegehouden wordt. Helaas is dat dus niet het geval en kijken we tot op vandaag nog steeds tegen cryptische meldingen aan in de logfiles, missen essentiele meldingen over de gezondheid van een applicatie of ontbreekt elke overdracht van kennis naar beheer.
In 9 van de 10 gevallen is alle aandacht gericht op de functionele vereisten, er wordt niet of nauwelijk getest op de non-functionele eisen die vaak bepalend zijn voor de beheersbaarheid van een oplossing. Tel daarbij op dat snelle wisselingen ook niet zorgen voor continuiteit in het opbouwen van kennis en het is niet vreemd dat legacy een bewezen trackrecord heeft in betrouwbaarheid.
Nu zijn er gelukkig ook uitzonderingen die de regel bevestigen en de 10% van de projecten die wel rekening houden met beheer zorgen ervoor dat de events geformaliseerd zijn. Dat voorkomt namelijk een wildgroei aan tools, de meeste worden toch altijd weer later toegevoegd om een vergeten requirement rond beheer in te vullen met de genoemde 'eiland automatisering' tot gevolg.
Dit euvel is trouwens niet alleen verwijtbaar aan ontwikkeling want ook de business kiest nog weleens COTS software die onder de motorkap een oplossingen hebben die voor beheer problemen zorgt. Platform-, middleware en database keuzen zijn uiteindelijk ook mede bepalend voor de opdelingen die er gemaakt moeten worden in het beheer.
Ook een leuke is dat het technisch beheer in de vorm van infrastructuur steeds vaker uitbesteed is, er is organisatorisch een Chinese muur opgetrokken die het integraal beheer bemoeilijkt. Het is namelijk best lastig om problemen in applicaties te achterhalen als meldingen - al dan niet cryptisch - naar een systeemlog geschreven worden waar je geen toegang toe hebt.
Kortom, voor DevOps moeten uiteindelijk alle sterren in lijn staan en dat is in menige organisatie nog weleens lastig.
Goed verhaal Sander. Je legt wel de focus op puur het IT-stuk, terwijl het logischerwijs te verwachten is dat als Agile de business en Ontwikkeling uitlijnt en DevOps juist Ontwikkeling en Beheer uitlijnt, dat we terug gaan naar een soort lokale IT-voorziening die de primaire processen van de diverse afdelingen ondersteunt. Dus een volledige uitlijning van IT en business! :)
Zie ook mijn eerdere Opinie bijdrage over DevOps:
http://www.computable.nl/artikel/opinie/development/4629565/1277180/devops-maakt-af-wat-agile-begon.html
@Ewout: je betoog onderschrijft de noodzaak die Sander schetst. We moeten inderdaad toe naar uitlijning en samenwerking over afdelingen heen. Die uitlijning is er nu niet, en daarom is het zaak dat organisaties zich kritisch over de vraag moeten gaan buigen hoe dat te tackelen. De DevOps gedachte is mijns inziens een belangrijke katalysator daar in.
Echt interessant is natuurlijk wat het het tot nu toe concreet heeft opgelevert. Maken de grote bedrijven die Devops aan hebben genomen meer winst dan andere vergelijkbare bedrijven die nog niet volgens Devops werken? Of kunnen ze b.v. aantoonbaar sneller reageren op ontwikkelingen? Of kun je dat niet goed vaststellen?
@Ewout Kriebelen? Ik krijg overal jeuk als ik dit lees. Dat ontwikkeling en beheer, hoewel twee verschillende taken, gerelateerd zijn is duidelijk en overleg en afstemming is gewenst. Maar dit is vooral een organisatorisch probleem. Dat tools voor het uitrollen van nieuwe software handig kan zijn daaar kan ik het ook mee eens zijn.
Maar als ik ook nog lees dat er iteratief steeds nieuwe brokken snel en vaak in productie te nemen dan denk ik, dat lijkt me niet wenselijk. Iteratief betekent dat je een stap vooruit maakt, weer een stap achteruit maakt om er weer 2 vooruit te maken. Voortschrijdend inzicht. Dat is hoe softwareontwikkeling in elkaar steekt. Daar wil je de gebruiker/klant toch niet mee confronteren? Dat gedeelte aan de buitenkant zou juist incrementeel moeten zijn. Een stap voorwaarts. Maar wil je de gebruiker/klant te vaak steeds met nieuwe software confronteren die eigenlijk niet deugt? Buiten dat iedere uitrol een risico is ook al zet je de hele handel geautomatiseerd in productie. Je moet zeker van je zaak zijn. Dat is ook mijn kritiek op het maar vlug vlug snel snel werken, onzorvuldigheid werk je niet weg met een paar tools. Het is ook opvallend dat een organisatie die ik wat ken en die volgens deze vlug vlug snel hogedrukpan methode werkt grossiert in storingen.
Dat de business bij monde van de productowner de kadans van de softwareontwikkeling bepaalt vind ik al discutabel want er zijn ook gewenste werkzaamheden die geen direct resultaat aan de buitenkant geven. Maar om ook nog je hele ICT organisatie om te toveren tot een grote soep die zich met mantra's als samen, het team over 'alles' verantwoordelijk is? Een scheiding van taken heeft dan toch mijn voorkeur, zolang de organisorische barrieres maar niet in de weg staan.
Misschien toch nog een keer interessant om wat deze Agile specialist te zeggen heeft:
http://blog.cutter.com/2013/12/10/2014-the-failure-of-agile-software-development-is-taken-seriously/
Ook niet alles, incrementeel en iteratief worden naar mening niet helemaal correct gebruikt maar hij doet wel enkele interessante uitspraken over ontwikkeling en de op agile gebaseerde procesbegeleidings methoden.
@Louis DevOps is een heel interessant fenomeen. Even los of het goed of slecht is (en dan: voor wie?) en of het wel in elke situatie past: Waarschijnlijk niet. Denk maar aan belastingdienst of bijvoorbeeld een bank of ziekenhuis.
Wat je ziet is dat veel cloud computing diensten DevOps (succesvol) inzetten. Dat moeten ze ook wel, omdat het nu innovatie-tijd is. Te lang stil blijven staan betekent achteruitgang ten opzicht van concurrenten die wekelijks nieuwe functies toevoegen.
De belofte van DevOps is dan ook enorm. Als je DevOps toepast betekent dit dat je *heel erg* in control bent. Dat moet ook wel, anders is het bedrijfsrisico veel te groot. Maar met goede DevOps krijg je agile wat anders log zou zijn.
En denk niet dat DevOps roekeloos is, er is wel zeker A/B testing, Unit testing, et cetera. Soms heb je wel eens dat de userbase een wijziging totaal niet accepteert dan zie je dat juist door deze manier van werken ook dit weer teruggedraaid kan worden. DevOps is dus in veel gevallen the way to go en ik geloof er heilig in.
Continuous delivery is de bom :-)
Met Agile is Continuous Delivery en Integration een must en Operations moet in het tempo mee om Agile succesvol te laten zijn. Uiteraard zijn hier risico's aan verbonden en kwaliteitsborging door middel van testen, reviews en controle op standaards en richtlijnen vallen niet weg met de introductie van de Agile aanpak. Sterker nog, de kwaliteitsborging (Quality Assurance) is een belangrijk aspect in DevOps. Op DevOps.com staat een interessant artikel met 5 top tips:
http://devops.com/features/five-top-tips-cloud-devops-automation/
Louis, je moet toch echt wat meer golven om de business te begrijpen ;-)
@louis
Inderdaad is het meer een afstemmingsprobleem dan een tekort aan tools, de argumentatie in sommige reacties is als het paard achter de wagen spannen. Want Agile is soms gewoon een kruiwagen vol met kikkers wat de afstemming natuurlijk niet makkelijker maakt.
@Henri
Het is geen discussie tussen goed of slecht maar tussen passend of niet. DevOps is in mijn ogen niet veel anders als 'pipeline deployment' wat alleen werkt als je korte ketens hebt. En dat DevOps prima past bij Cloud Computing komt mede doordat die wereld plat is, een hoge mate van standaardisatie.
@Anko
Ja en nee, de samenwerking is er meestal wel alleen dan officieus. Probleem (of uitdaging) welke ik nog vaak zie is dat het beheer vooral aangestuurd wordt op contracten, de SLA die weinig flexibiliteit kent als je beheer uitbesteed hebt. DevOps is voor mij in de eerste plaats over schaduwen heen springen, iets wat veel managers werkeloos maakt.
Heel veel organisaties zijn nog maar net begonnen met Agile en dan vaak ook nog eens in hun eigen variant die een groot gedeelte van Agile denken en doen ondermijnt. Niet dat het ultieme doel zou moeten zijn om 100% netjes Agile te werken. Maar slechte gewoontes hebben een eigenschap om maar moeilijk te slijten.
Om dan maar meteen door te stoten naar een DevOps is misschien dan wel wat overmoedig. Wat dat betreft is het volgens mij meer een hype buzzword dan dat het daadwerkelijk ook concreet veel inhoud heeft waar organisaties wat aan hebben. Zoals altijd gaat het meer om de invulling.
De kwaliteit daarvan is vaak te herkennen in de volwassenheid van de QA. Bij menig bedrijf vaak toch wel het ondergeschoven kindje.
Vandaar ook mijn stelling.
Zonder een goed afdekkende QA is continuous delivery vrij zinloos. Dus vermijden dat QA het kritieke pad vormt voorkomt niet alleen afraffelen. Het voorkomt ook dat de hele pijplijn verstopt komt te zitten als QA de hoogste prioriteit gekregen heeft. Het is vrij goed uit te leggen dat het product wat later geleverd wordt omdat er nog eens goed naar gekeken word en er fouten uitgehaald worden. Daar heb je onderhoud sprints voor.
Agile en Devops zijn methodieken die, wanneer je er aan begint, er voor zorgen dat je organisatie op een andere manier tegen ontwikkeling (en beheer) aan gaat kijken.
De grote winst is dat, door er op een andere manier tegen aan te kijken, de "pijnpunten" van de huidige manier van werken zichtbaar worden.
Het veranderend vermogen (en bereidwilligheid uiteraard) van de organisatie is vervolgens bepalend voor het succes danwel falen van de methodiek.
Als, bijvoorbeeld, het totale beheer van jouw omgeving verdeeld is over diverse (externe) partijen, dan kun je "DevOps-en" tot je een ons weegt, maar dan zul je problemen blijven houden met het in productie brengen van wijzigingen. Pas als beheer als één geheel kan en wil werken zul je richting succes gaan.
@henri DevOps is zeker een interessant fenomeen al denk ik dat de clou van dit verhaal is dat het lastig is om de juiste mensen bij elkaar te krijgen in ICT trajecten zoals ontwikkeling of onderhoud. Want als de je de gebruiker/klant, ontwikkelaar en beheerder aan tafel hebt kan je het in principe met drie man af. Heel gechargeerd en idealiter, alleen zit zo de wereld niet elkaar, zeker niet in een grote organisatie.
Maar inmiddels heeft het DevOps een hele andere vaart genomen, in een adem wordt het genoemd met Agile, Scrum, continous delivery en integration. En daar kom mijn knorrigheid om de hoek kijken voor je het weet zijn het abstracte begrippen waar je van alles bij kunt bedenken. Dat blijkt ook wel als ik de artikelen en reacties over deze onderwerpen lees. Het zwabbert alle kanten op. En nog weet ik niet wat wat agile is, wat nu exact devops is en hoe de ware scrum in elkaar steekt. Maar we zijn wel agile hoor! Ik wacht nog steeds hier of in de reacties op iemand die nu exact kan uitleggen hoe het zit. Nog niet gelezen. Soms denk ik wel, ICT en alles wat er omheen hangt van vaagheden aan elkaar is spraakverwarring troef en misschien is dat ook wel zo prettig. Iedereen mag meedoen en meepraten, verstand van zaken of niet. Wel goed voor de werkverschaffing.
Bij DevOps denk ik dus voor mezelf maar dat het handig is om de juiste mensen bij elkaar te brengen zonder dat er van alles tussenzit en niet de organisatie, formele verhoudingen of de bureaucratie verstorend werken. Dat geldt misschien wel juist voor zulke organisaties als banken, ziekenhuizen, belastingdienst of wat voor grote logge organisaties ook. Projecten en trajecten die kwa afhankelijkheden over meerder afdelingen heenlopen. Ik meen dat die Belgische meneer juist op de DevOps is gekomen toen hij bij een overheidsorganisatie werkte.
Die cloud dienst leverancier valt naar mijn mening in een hele andere categorie, dit gaat over een software product, niet over de automatisering van een organisatie. En dat nieuwe features misschien in een iets hoger tempo opgeleverd worden en dat uitrollen naar een nieuwe versie gaautomatiseerd is, heel begrijpelijk. Dat hadden ze ook gedaan zonder dat continous delivery en integration te noemen.
@Felix Ik houd wel van mini golf, alleen is dat een sport voor toeristen en bejaarden en niet voor de ICT beslissers op de golfbaan die aan elkaar vragen: zijn jullie al agile? Maar het is een leuk artikel. Mensen boven processen (!) en meer vrijheid voor de ontwikkelteams. Dat spreekt aan en weg met de slavendrijvers en lopende band ict.
@Ewout en @PaVaKe Ja, Ewout denk dat het over afstemming gaat en ben het eens dat outsourcen helemaal de achterdeur uit is en je het dan helemaal niet meer over devops moet hebben. Als er iets is wat afstand creeert dan is het outsourcen wel.
Louis en anderen. Devops is een groeiend fenomeen. De traditionele chinese muur tussen ontwikkeling en beheer is al jaren een onneembare vesting, die bedrijven veel geld kost. Applicaties worden nog ontwikkelaars beheert of de infrastructuur is onbeheerd, wordt niet gepatched, etc.
Devops betekent dat je als team samenwerkt om het gehele systeem in een beheerde omgeving gestalte te geven en in productie te nemen. Dit kan ook in een outsourced omgeving. Er zal wel een regisseur moeten zijn, maar je zult verbaasd zijn van de kracht van een devops team dat goed samenwerkt. In plaats van elkaar te dwarsbomen helpt men elkaar en worden goede ideeen geleverd.
De manier waarop de reageerders erin zitten is wel heel behoudend en beperkt. Verdiep je eens in de materie.
@Willem
Wie heeft die Chinese muur opgeworpen, met welke doel is dat gedaan?
Natuurlijk zit de sleutel in samenwerken maar verdiep je eerst zelf maar eens in de materie, Chinese muur is ontstaan door het Excel(lente) management van zeemeeuwen die hard roepen, iedereen op hun kop schijten en dan snel weer wegvliegen. Even voor de duidelijkheid, eind jaren 90 deed ik al zoiets als DevOps door wereldwijd 6 major en 12 minor releases per jaar uit te rollen.
Toen nog voornamelijk met tapes en vliegtuigen omdat netwerk duur en traag was maar principes en processen waren hetzelfde. Met echter één verschil, als IT zei dat een release niet uitgerold kon of mocht worden dan gebeurde het ook niet.
Niet aangebrachte patches, niet goed ingerichte servers zijn in 9 van de 10 gevallen een business beslissing omdat time-to-market belangrijker geacht wordt dan de beveiliging. Aanbrengen van patches is namelijk iets dat vrijwel automatisch gedaan kan worden, net als rechttrekken van beveiliging met templates en scripts maar niet gedaan wordt omdat dan allerlei applicaties niet meer werken.
Agile is bug fixing, lean is problem solving;-)
@Willem Vraag is hoe die Chinese muur eruit ziet en wat je je daarbij moet voorstellen? Samenwerking is volgens mij iets wat iedereen die hier reageert wel noemt. Het team klinkt leuk maar dat betekent niet dat er geen taken en verantwoordelijkheden zijn en inhoudelijke leiding moet zijn.
Outsourcing werpt barrieres op en creeert afstand. Stel je besluit je ontwikkeling van een onderdeel uit te besteden, dat betekent afspraken maken en contracten opstellen. Nu bedenkt de klant na een een tijd dat hij toch zaken graag iets anders ziet, wat dan? Dan denk ik, dat betekent afspraken en contract herzien en opnieuw steggelen op hoger niveau. Als het ook nog outsourcing is waar de ontwikkeling in een land hier ver vandaan is dan is de afstand tussen ontwikkelteam en klant/gebruiker wel erg groot geworden met schijven daartussen. Als dan ook nog de beheerafdeling bijvoorbeeld intern of weer andere partij doet dan is ook die afstand tussen beheer en ontwikkeling groot. DevOps, gaat ook over korte lijnen en lijkt me zo lastig te bewerkstelligen. Er ligt in een extra probleem. Ook niet echt agile als ik naar het manifesto kijk.
Maar ik ben benieuwd naar je uitleg. Communiceren is inderdaad lastig in het uitgebreide ICT vakgebied met mensen met diverse achtergronden.
Moet ook denken aan dat bekende plaatje wat hier onlangs weer te zien was:
http://makingsoftware.foglo.com/wp-content/uploads/2011/01/PM_Build_Swing.gif
Naast dat ik de commerciële lijn en intentie wel kan en wil volgen, is die andere lijn weer onnavolgbaar. Sec IT gezien ga en wil ik de koppeling
tussen IT beheer en Devteam niet maken. De reden daarvoor is uiterst eenvoudig.
Devteams en veranderingen
Ik spreek nu even mijn praktijkervaringen uit over dit stukje. Tot nu toe heb ik nog geen enkel Devteam het volgende volmondig en helder horen verklaren: Helder, Transparant, Op tijd, Afgesproken, Conform Specs. Het resultaat: Heel veel hele hoge rekeningen. Gegarandeerd.
Devteams en veranderingen
In mijn beleving zijn er geen DevTeams nodig om IT wise veranderingen te bewerkstelligen. Je kunt ze er natuurlijk wel voor assignen en inzetten maar dan krijg je: Hele veel hele hoge rekeningen, gegarandeerd.
Waar je hier namelijk mee te maken hebt, zoals het artikel al beschrijft, twee verschillende werelden. IT - Statische en Non IT- Dynamisch.
Wall of Confusion
Leuk gevonden maar die 'wall of confusion' is helemaal niets meer en minder dan dat IT, nader nog, commercieel IT, het na x jaar KA, het nog niet eens voor elkaar heeft gekregen Non IT te vertellen wat nu IT is, hoe het werkt en beweegt, en het allerbelangrijkste, hoe je er als Non IT er tegen aan moet kijken en mee moet om gaan.
Daarvoor bedenk je dan volkomen overbodige en nutteloze zaken zoals DevOps, Agile, Scrum, Lean. (Are you kiddin' me? Keep trying) Vervolgens vervat je dat allemaal in een commercieel getint artikeltje, publiceer dat en...... zie hier, een totaal overbodige discussie is geboren.
Back to basics?
Beste IT professional, waar is IT nu eigenlijk voor bedoeld en wat wil je nu feitelijk met de inzet van IT bereiken? Dat iedereen als domme aapjes nieuwe trucjes leert zoals methoden die helemaal niets met de lineairiteit van IT op hebben en dan roepen, kijk ons eens lekker bezig. Geweldig. (Max 140 chs) #Agile #Scrum #Humptidum #Bunte Illustrierte
Of was het toch nou net niet zo dat de basis van IT gewoon het verhogen van productiviteit was met zo min mogelijk FTE?
Ik kan het natuurlijk volkomen mis hebben maar wist u dat de meesten die hard #Agile #Scrum #Humptidum #Bunte Illustrierte roepen het minste uit hebben staan met en in IT? Oh ja natuurlijk, de mensen met de volkomen frisse blik die..... Oh ja.
Natuurlijk.