Van Scrum team naar agile organisatie - vierde ontwikkelingsfase

Ontwikkelingsfase 4: DevOps binnen IT

In mijn blog over 'Agile Ontwikkelingsfase 3: Fysieke product teams' heb ik toegelicht dat het efficiënter werkt als men de IT reorganiseert naar business domeinen of business producten. Deze structuurwijziging ondersteunt implementatie van het Scaled Agile Framework optimaal, en rendementen van 50% zijn bij adequate implementatie makkelijk haalbaar.

De volgende stap is een stap die volgens mij niet veel grote organisaties kunnen maken, en is weer een structuurwijziging. Namelijk het fysiek toevoegen van operations medewerkers aan de afdeling met ontwikkelmedewerkers. Dit levert in vele organisaties problemen op die in deze blog worden besproken. Vele organisaties zullen dan ook stoppen bij agile ontwikkelingsfase 3, en ik raad elke IT-organisatie ook aan om daarnaar te streven. De meeste IT-organisaties zijn het punt al voorbij waarbij ze nog de luxe hebben om te zeggen "we blijven op de bestaande voet doorwerken". De technische schuld neemt almaar toe en kan onhoudbare proporties aannemen, terwijl de vraag naar snellere time-to-market verder toeneemt.


Dit is de 4e blog in een serie van 5, over de 4e ontwikkelingsfase.

  1. Iteratief werken binnen projecten in de matrix
  2. Virtuele product teams over functie afdelingen heen
  3. Fysieke product teams, al dan niet virtueel aangevuld met Ops
  4. DevOps binnen IT
  5. Bedrijfsbrede product of domein teams

Structuur- en cultuurverandering

4e ontwikkelingsfase is weer een organisatieverandering, maar leidt ook naar een 'Organizational Culture Shift'.
fluency model

Het fluency model van James Shore en Diana Larsen (rechts) laat een andere view zien op het werken naar een complete agile organisatie. Je zou kunnen zeggen dat het iteratief werken in projecten vergelijkbaar is met de 'Start: Building code' van dit model, dat leidt tot een 'team culture shift'.
Ontwikkelingsfase 2 werkt aan de 'focus on value *', door virtuele product teams samen te stellen. Dit zou moeten leiden tot een 'skill shift' voor die teams.

Bij ontwikkelingsfase 3 gaan we naar 'Deliver Value'. Dit resulteert in een organizational structure shift. We gaan namelijk product- of domeinafdelingen creëren binnen de IT-organisatie. Binnen deze afdelingen kunnen één of meerdere agile delivery teams, of vaste product teams aan (sub) producten werken.

Bij ontwikkelingsfase 4 gaan we naar 'Optimize Value'. Vaste DevOps teams meten hun productiviteit en worden steeds voorspelbaarder. Het toebehoren aan een vast team geeft ook een betere intrinsieke motivatie voor leveren van software van hoge kwaliteit. Voorspelbaarheid op releaseniveau wordt hier behaald, inclusief deployment door Ops. Met als resultaat een nog beter zicht op portfolioniveau van wanneer bepaalde zaken in de markt kunnen worden gezet. Maar ook, een beter inzicht op portfolioniveau hoe de resources in de vaste teams uit te nutten, en dus, om aan efficiënter portfoliomanagement te kunnen doen. Wat doen we wel, wat doen we niet, wat levert ons als bedrijf de meeste business waarde op.

Feitelijk spreken we hier over een kanteling van een complexe organisatie met eenvoudige taken naar een eenvoudige organisatie met complexe taken. Het zijn nu juist die complexe taken, gepaard met een toenemende verantwoordelijkheid op de werkvloer, die de kwaliteit van arbeid doen toenemen. Inderdaad een cultuuromslag! Dit vergt niet alleen iets van de medewerkers, maar zeker ook van de managers (Kuipers, van Amelsfoort & Kramer (2010): 'Het nieuwe organiseren').

DevOps binnen IT

DevOps binnen IT (samenvoegen van de gespiegelde organisatie)

De IT bestaat uit domeinafdelingen waarbinnen vaste DevOps teams verantwoordelijk zijn voor ontwikkeling, onderhoud én operatie van (sub) business producten.

Het is natuurlijk al mogelijk, en ook benoemd in agile ontwikkelingsfase 3, om virtueel mensen van operations toe te voegen aan, of aan te laten sluiten bij, vaste productteams. In fase 4 gaan we een stap verder en brengen we de operations mensen onder dezelfde management en HR-verantwoordelijkheid als de development medewerkers. In beide gevallen kunnen hand-offs worden geëlimineerd, zoals ook onder 'Optimize Value' te lezen valt in het model van Shore en Larsen. Het elimineren van deze hand-offs wordt mooi geïllustreerd in de figuur hieronder van Matt Watson. Het extra voordeel dat samenbrengen onder één management brengt is dat men slechts één baas heeft, die belang heeft bij een optimaal proces. Wat hierbij kan botsen is dat Development en Operations vaak verschillende belangen hebben. Maar uiteindelijk draait het allemaal om het snel en kwalitatief leveren van Business Waarde.

Matt Watson

Het figuur van Matt Watson, stackify.com, laat zien dat de hand-offs tussen development en operations wegvallen bij vaste devOps teams.

Voorbeeld structuur

Een voorbeeld operations afdeling van een groot bedrijf.

Operations kan gespiegeld zijn met development qua organisatie in eerste instantie, maar kan ook totaal anders zijn georganiseerd. Bovenstaand voorbeeld van een operations afdeling van een groot bedrijf geeft aan uit hoeveel subafdelingen het kan bestaan, met elk hun eigen specialisme en loket. En het zijn in het bijzonder die loketfuncties die een organisatie stroperig maken, en doorlooptijden voor deployment kunnen oprekken. Dat alles vergt veel indirecte coördinatiecapaciteit, die wellicht ingeruild zou kunnen worden voor directe ontwikkelcapaciteit.

Direct vs indirect

Maar dit brengt veel uitdagingen met zich mee. Want je kunt je voorstellen dat als je een gespecialiseerde afdeling van 5 personen wil gaan verdelen over 30 product teams, dat dit niet gaat. Ook zullen producten vaak van veel meer platformen gebruikmaken dan slechts één. Hoe ga je dan om met het formeren van DevOps teams? Vaak is er formatiestop op het aannemen van nieuw personeel. En je kunt specialisten, die toch al moeilijk te vinden zijn voor sommige platformen, niet opsplitsen.

Kortom, er is niet één oplossing te geven voor deze stap in de ontwikkeling. Voor kleine organisaties zal het makkelijker zijn om vaste DevOps team te formeren, voor grotere organisaties levert dit vooralsnog veel uitdagingen op. Beginnen met continu betrekken van de Operations medewerkers bij de vaste product teams in agile ontwikkelingsfase 3, is een goede start. Van daaruit kan men gaan inventariseren hoe men de loketten kan verminderen (reductie indirect personeel), en in aansluiting op de Development afdelingen de Operations afdeling beter kan laten aansluiten op het (business) product gericht werken, in plaats van alleen maar denken in eigen specialisme. Hierbij dienen combinaties van belangen zoals snellere time-to-market, en operational excellence, maar ook wederom intrinsieke motivatoren, tegen elkaar afgewogen te worden.

Voor en nadelen van Agile ontwikkelingsfase 4

Voor ontwikkelingsfase 4 gelden dezelfde voor- en nadelen als ontwikkelingsfase 3. De voor- en nadelen die specifiek voor fase 4 zijn te benoemen, bovenop die van fase 3, zijn schuingedrukt.

Voordelen:
• Directe betrokkenheid van operations medewerkers bij het agile traject van requirement tot in-productiename.
• DevOps teams houden veel beter rekening met de eisen waaraan het product dient te voldoen voor deployment.
• Reductie van overhead aan management-, plannings- aansturings- en loket capaciteit.
• Reductie van inspanning voor project gerelateerde documentatie (Projectplannen, Requirements management plannen, testplannen etc. hoeven of niet gemaakt te worden, of slechts bijgehouden te worden, en niet per project vervaardigd van scratch).
• Reductie van inspanning voor domein gerelateerde documentatie (Vision Documents, Domain Models, Use Case Models, SAD's, Supplementary Specs, Designs werden vaak per project opgetuigd, en aan het einde weer weggegooid, nu hoeven ze per product alleen maar onderhouden te worden). Nu zullen sommige agilisten zeggen hoezo documentatie bij agile? Ik ben ervan overtuigd dat goede domein- en ontwerpdocumentatie key is voor bedrijf kritische producten. Daarvoor vormen RUP artifacts een goede bodem. Wil je een tijdelijke campagne site bouwen?, dan kun je meeste documentatie achterwege laten idd.
• Permanente DevOps teams vormen een voedingsbodem voor intrinsieke motivatie.
• Een permanent DevOps kan domein kennis opbouwen.
• Een permanent DevOps team kan een referentiekader opbouwen en daarmee voorspelbaar worden.
• Een permanent DevOps team kan continu (in plaats van tijdelijk gedurende een project) aan productiviteitsverbetering werken.
• Een permanent DevOps team denkt eerder aan de totaal kwaliteit van een product, omdat het daarvoor verantwoordelijk is, en niet slechts voor de scope van een tijdelijk project.
• Wielen hoeven niet telkens uitgevonden te worden als er weer een project voor innovatie op hetzelfde product wordt opgestart.
• Testomgevingen worden permanent in de lucht gehouden versus het af laten breken en op laten bouwen per project.
• Eén manager verantwoordelijk voor HR van de DevOps teams geeft duidelijkheid en een gevoel van ergens bij horen .
• Er zal minder 'getrokken worden' aan, en 'geschoven worden' met resources, meer als een mammoet tanker dan per week je effort verdelen over meerdere projecten. Dus, bemensing DevOpsteams op lange termijn wel afstemmen op het opdrogen dan wel aanwassen van de portfolio backlog.

Nadelen:
• Bij grote IT afdelingen zal het moeilijk zijn de operations medewerkers te verdelen over fysieke DevOps teams, dit vergt verregaande reorganisatie, omscholing, acquisitie en herbeleggen van verantwoordelijkheden. Een kanteling van een verticaal georganiseerde organisatie naar een horizontaal georganiseerde organisatie.
• Er zal beter nagedacht dienen te worden over automated deployment, dit vergt vaak investering.
• Bij vaste DevOps teams of afdelingen zal resourcing een probleem vormen. Specialisten zijn soms schaars en management is niet geneigd om extra personeel aan te nemen om permanente teams te bemensen. Wat zij zich dan wel dienen te realiseren is dat bij opschaling veel indirect coördinatie personeel vrijkomt, en vervangen kan worden door inzet van meer specialistisch direct personeel.
• Configuratie management issues zullen optreden wanneer meerdere DevOps teams op dezelfde applicatielaag aanpassingen willen doen voor 'hun' business product.
• Bij grote IT landschappen zullen issues ontstaan rondom inrichting van component of feature teams, en de inhoudelijke coordinatie hierover die opgelost dienen te worden.
• Synchroniseren van backlogs om de tijdigheid van markt releases vast te kunnen stellen die overDevOps teams, of zelfs product afdelingen, heen stijgen, zal intensief dienen te zijn. Deze discipline is zeer moeilijk op te brengen.

Qua rendements percentage krijgt deze stap: 100%

In deel 5 van deze serie ga ik het hebben over Agile ontwikkelingsfase 5: Bedrijfsbrede product of domein afdelingen: terug naar decentralisatie en de silo's!

DEEL DIT ARTIKEL
VOLG ONZE BLOGS

Gerelateerde blog artikelen

  • SAFe een verkapte waterval? Echt niet!

    Erik Borgers blogt: "SAFe roept naar mijn ervaring regelmatig emotie op. Een terugkerend verwijt is dat het eigenlijk 'verkapte waterval' is."

    Lees verder
  • Het fysieke Kanban of Scrum bord

    Is er in een wereld met verregaande automatisering nog wel ruimte voor fysieke Kanban of Scrum borden? Dat is een vraag die ik mij regelmatig stel.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 2) - 'Solution intent’

    In dit tweede deel van mijn serie blogs over SAFe (Scaled Agile Framework) 4.0 bespreek ik een voor mij ondergeschoven kindje in agile: ‘Solution intent’.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 3) - Meer flexibiliteit met het 'Spanning palette'

    Brian Teunissen vertelt over het palet aan resources en items binnen SAFe die niet aan één team kunnen worden toegewezen.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 4) - Kanban op alle lagen

    De definitie van Kanban uit wikipedia luidt: Kanban (van het Japanse kan ‘visueel’ en ban ‘kaart of bord’) is een concept gebruikt in lean manufacturing en just-in-timeproductie.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 6) - Foundation layer

    SAFe 4.0 leunt op fundamenten zoals Lean and agile leaders en Communities of Practice, maar ook Core values en SAFe principles. Brian Teunissen licht deze toe.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 7) - Multiple portfolio’s

    In het 7e en laatste deel van de serie blogs over SAFe 4.0 gaat hij in op "Multiple portfolio’s". Een nauwelijks te vinden, maar significante aanvulling op het framework.

    Lees verder
  • Maak kennis met SAMM

    inspearit heeft samen met de Belastingdienst SAMM ontwikkeld.

    Lees verder
  • Eet je eigen hondenvoer!

    Eén van mijn principes luidt: Pas een agile werkwijze toe bij het implementeren van agile werkwijzen. "Ja, logisch toch?" zullen de meeste agilisten denken. Maar probeer dat maar eens vol te houden bij grootscheepse implementaties bij traditioneel aangestuurde organisaties. Toch loont het om de verandering zo snel mogelijk agile aan te pakken.

    Lees verder
  • De zwaluw die wél zomer maakt

    ‘Agile werken’ en ‘Scrummen’ worden steeds breder in de organisatie toegepast. Dat leidt tot doelgerichte zelforganisatie die berust op autonomie, meesterschap en zingeving.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 5) - Onderscheid ‘Business operation’ value stream en de ‘IT life cycle’

    In dit 5e deel van een serie blogs over SAFe 4.0 laat ik zien dat er nu beter onderscheid wordt gemaakt tussen de ‘Business operation’ value stream en de ‘IT life cycle’ value stream.

    Lees verder
  • Eerste antipatronen bij Scaling Agile

    Brian Teunissen vertelt over hoe in de praktijk de voordelen van SAFe worden ondermijnd door drie grote antipatronen.

    Lees verder
  • De Agile Architectuur Pizza

    Als agile architectuurcoach is er voor mij niets leukers om mensen met agile Frameworks te leren werken en daartoe soms diepgaande discussies te voeren over WIP limieten en WSJF-en.

    Lees verder
  • Hoe Agile en Security hand in hand gaan

    Beveiliging en agile ontwikkeling kunnen wél hand in hand gaan en vertrouwen geven dat producten naast functionaliteit ook veiligheid bieden

    Lees verder
  • Autorisaties binnen agile teams

    Michiel Broekhuijsen blogt over een oplossing voor dit veelgehoorde pijnpunt.

    Lees verder
  • Jongen, ben jij wel bang genoeg?

    Eric Nieuwland blogt: "Informatiebeveiligers zijn soms lastige zeurkousen. Uit angst voor incidenten zeggen ze al 'nee' voor ze begrijpen wat je wilt. Dat kan anders."

    Lees verder
  • De taaie kant van Scaling Agile

    Agile organisatiebreed implementeren is een hele kluif. Brian Teunissen raadt iedereen die van start gaat met het opschalen van Agile aan om zich vooral ook te verdiepen in verandermanagement.

    Lees verder
  • Scaling Agile, van trend naar gevestigde orde

    Blog van Brian Teunissen met zijn visie op de agile trend en de verschillende scaling frameworks

    Lees verder
  • ​Informatiebeveiliging versus Privacymanagement, wie wint de slag?

    In dit (gratis) event zullen de tegenstellingen tussen privacy - en informatiebeveiligingsmanagement onder een vergrootglas worden gelegd.

    Lees verder
  • 5 tips om je agile transformatie te laten mislukken

    In deze blog een vijftal concrete tips om de kans op een geslaagde agile transformatie flink te verkleinen of vertragen. Tip: stuur deze blog door naar je grootste concurrent! Of lees 'm zelf nog eens na voor alle zekerheid...

    Lees verder
  • Van Scrum team naar agile organisatie - vijfde ontwikkelingsfase

    Brian Teunissen blogt over de laatste van de vijf ontwikkelingsfasen om van Scrum team door te groeien naar een Agile organisatie.

    Lees verder
  • Pak die banaan!

    Blog van Brian Teunissen over het veel eenvoudiger budgetteren bij scaling agile.

    Lees verder
  • Melk produceren of poepscheppen

    Blog van Brian Teunissen over de productiviteit van Agile teams.

    Lees verder
  • Van Scrum team naar agile organisatie - eerste ontwikkelingsfase

    In een serie van 5 blogs gaat Brian Teunissen in op de ontwikkelingsfasen waarmee een (organisatie)structuur zich aan kan passen aan een agile werkwijze.

    Lees verder
  • Paradigmaverschuivingen bij Scaling Agile

    Brian Teunissen: In deze blog geef ik een overzicht van paradigma verschuivingen die een organisatie door moet bij het opschalen van agile werken

    Lees verder
  • Van Scrum team naar agile organisatie - derde ontwikkelingsfase

    Brian Teunissen vertelt over ontwikkelingsfase 3: fysieke product of domein afdelingen, al dan niet aangevuld met Operations.

    Lees verder
  • Van Scrum team naar agile organisatie - tweede ontwikkelingsfase

    Brian Teunissen beschrijft Agile ontwikkelingsfase 2: virtuele product teams over functie afdelingen heen.

    Lees verder
  • Is Agile werken voorspelbaar?

    Is Agile werken voorspelbaar? "Ja en nee", vindt Brian Teunissen.

    Lees verder
  • Luitenant Borgers

    Alhoewel je het uit de titel waarschijnlijk niet direct zult halen, deze blog gaat 'dus' over het schalen van Agile teams. De volhardend lezer beloon ik met concrete ideeën hoe mensen aan te zetten om een goed lopend team van teams te vormen.

    Lees verder
  • Ga goed voorbereid 2017 in!

    Ga goed voorbereid 2017 in! Je ontvangt nu nl. 17% korting op alle opleidingen die nog in 2016 gepland staan.

    Lees verder
  • Privacy

    Toen mijn grootmoeder mijn vader kwam inschrijven bij de burgerlijke stand, werd zijn achternaam voorgoed veranderd vanwege een defecte typemachine. De letter "Y" deed het niet meer, waarop de beste ambtenaar (behulpzaam als hij was) de letters "IJ" in plaats daarvan gebruikte (je hoort het verschil toch niet). Daarmee werd figuurlijk gezien een streep gezet door mijn familie stamboom.

    Lees verder
  • Het architectentheekransje

    Hier volgt een sprookje over een kennisgroep van architecten. Je kent ze wel, die clubjes die eens in de tijd bijeenkomen om gezamenlijke visies, strategieën en concrete doelen te definiëren en dan uit elkaar gaan om van alles te realiseren. Dit verhaal vertelt over hun Ups en Downs. Totdat ze samen nieuwe manieren van werken ontdekten. Herken je zaken? Doe er je voordeel mee!

    Lees verder
  • Vertrouwen: noodzakelijk bij informatiebeveiliging en cloud computing

    Informatiebeveiligers nemen op basis van risico's maatregelen het (bedrijfs)proces. Maar dat loopt spaak bij het uitbesteden naar de cloud. Hoe gaan we dit aanpakken?

    Lees verder
  • Security & DevOps: toekomstmuziek?

    Michiel Broekhuijsen wil je meenemen op een reis naar de nabije toekomst. We bezoeken een organisatie waarbij ontwikkeling, security en operations (z.g. DevSecOps) volledig zijn geïntegreerd...

    Lees verder
  • 10 eenvoudige verbetervoorstellen voor Agile architectenteams

    Ben je architect en doe je (in teamverband) voorbereidend werk voor één of meer Scrum ontwikkelteams? Hierbij 10 concrete tips die jou en je architectenteam verder helpen te verbeteren.

    Lees verder
  • Het "Juniper effect"

    Op 21 december 2015 liet Juniper (leverancier van o.a. firewall producten) weten dat ze ongeautoriseerde code hebben ontdekt, die door kwaadwillende als een backdoor kunnen worden gebruikt. Het is mogelijk dat via backdoor om versleutelde VPN verbindingen af te luisteren en/of toegang te krijgen de firewall een SSH verbinding te krijgen door middel van een ingebakken wachtwoord.


    Lees verder
  • De Agile Architect: de ultieme klimgeit?

    Agile werken lijkt voor de IT eerder regel dan uitzondering te worden. Maar bedreigen die "agile teams" het zo zorgvuldig door enterprise architecten bewaakte gedachtengoed niet? Hoe zorgen architecten ervoor dat de uiteindelijke architectuurdoelen anno 2013 geborgd blijven? In deze blog wil ik daar mijn inzichten met u over delen.

    Lees verder
  • TOGAF: radioactief materiaal voor organisaties?

    Ik geef al jaren les in TOGAF en dat kent een interessant aanvangspatroon. Op de eerste dag kom ik binnen met een hele grote doos met die vuistdikke TOGAF boeken.

    Lees verder
  • Rokjesdag voor architecten

    Waar gebeurd. Aan een door mij onlangs gegeven training voor architecten nam zowaar een vrouw deel. In mijn praktijk is dat behoorlijk zeldzaam! Gedurende de lunch dacht ik: daar wil ik wel iets meer van weten. We raakten aan de praat en ik vroeg naar haar rol.

    Lees verder
  • Round Table Scaling Agile zeer succesvol

    Op 5 oktober jl. vond op het landgoed ‘Zonheuvel’ een Round Table plaats met als thema: ‘Scaling Agile: Boardroom besluit of IT feestje?” O.l.v. Marco de Jong en Brian Teunissen werd deze vraag bediscussieerd door 16 genodigden van uiteenlopende organisaties.

    Lees verder
  • Scrum voor informatiemanagement: 5 hindernissen om te overkomen

    Ik coach informatiemanagement om Scrum te gebruiken. De verschillende rollen hebben elkaar veel te bieden en samen kunnen ze fantastische producten maken. De praktijk is echter weerbarstig. Wat zijn typische belemmeringen en wat doe je er tegen?

    Lees verder
  • Agile transformatie: het slechten van de grenzen

    "De agile en digital coaches en consultants van inspearit helpen de huidige grenzen aan agility te slechten en deze tot enablers te maken. Wij maken bij onze klanten aan den lijve mee wat het betekent om een organisatie te veranderen", blogt Sandra Schreppers.

    Lees verder
  • ​Agile Assessments: heaven or hell?

    Erik Borgers vertelt in zijn blog hoe een agile assessment best ingewikkeld kan zijn als je écht iets aan de resultaten wilt hebben.

    Lees verder
  • Op weg naar een High Performance Overheid

    Op initiatief van projectmanagers van UWV, de Belastingdienst, DUO en I-Interim Rijk werd op 10 mei jl. het seminar ‘op weg naar een High Performance Overheid’ gehouden voor medewerkers van de overheid.


    Lees verder
  • Faalangst-cultuur

    Gaat Agile tot een teleurstelling leiden als het organisaties niet lukt om hun faalangst-cultuur om te buigen?

    Lees verder
  • Werken Agile teams ook internationaal?

    Erik Borgers Blogt: Het toepassen van agile is vaak een stuk lastiger in grote internationale organisaties.Voor mij gaat het echt te ver als de globalisering dwars door teams gaat lopen.

    Lees verder
  • LeSS principes leggen de basis voor het Scaled Agile Model bij de Nationale Politie

    inspearit heeft samen met de Nationale Politie een agile samenwerkingsmodel ontwikkeld gericht op snelheid en wendbaarheid in een continue verbetercyclus.

    Lees verder
  • Aankondiging nieuwe cursussen Privacy en persoonsgegevens

    Om de ‘nieuwe’ Europese verordening gegevensbescherming (AVG) te kunnen vertalen naar de dagelijkse praktijk bieden we binnenkort twee nieuwe cursussen.

    Lees verder
  • Wat is nieuw in SAFe 4.0 (deel 1) - 'Value Stream'

    In dit 1e deel van een serie blogs over SAFe (Scaled Agile Framework) 4.0 bespreekt Brian de meest significante vernieuwing van deze versie; de 'Value Stream' laag.

    Lees verder
  • De scholingsvouchers van het UWV zijn helaas op, maar...

    De scholingsvouchers van het UWV zijn helaas op! Maar ben je werkzoekend en wil je je carrière vervolgen in de IT en heb je net misgegrepen? Wij helpen je toch graag verder.

    Lees verder
  • In the cloud we trust?

    Het nieuws dat de zgn. Safe Harbor Agreement door het Europese hof ongeldig is verklaard heeft voor een ware schokgolf gezorgd in de privacy- en informatiebeveiligingswereld.

    Lees verder
  • Round Table “De waarde van Agile: wie bepaalt dat?”

    Op donderdag 29 juni vond in Kasteel Sterkenburg een geslaagde Round Table discussie plaats rondom het thema “De waarde van Agile: wie bepaalt dat?”.

    Lees verder
  • Kerstwensboom

    December is dé maand om stil te staan bij het afgelopen jaar en vooruit te blikken op de toekomst. Maar ook om iets bijzonders te doen voor een ander. Wie in jouw omgeving wil jij verrassen met een opleiding naar keuze bij cibit academy?

    Lees verder
  • Digital Transformation en Business Analyse

    inspearit sponsorde het IIBA jaarcongres 2017. Het werd afgelopen dinsdag 14 november een goed bezochte en interessante bijeenkomst. Het thema: ‘Digital Transformation en Business Analyse’. Het vraagstuk werd door de sprekers uit verschillende invalshoeken belicht. 

    Lees verder
  • (ISC)² vernieuwt CISSP examen

    Belangrijk nieuws voor iedereen die aan het leren is voor het (ISC)² CISSP examen. Lees verder.

    Lees verder