Binnen beheer wordt driftig gezocht naar continuïteit en stabiliteit, gebaseerd op regels en structuur (ASL, BISL en ITIL). Leveranciers en klanten maken afspraken en leggen deze vast in sla’s met kpi’s en dergelijke. Terwijl we binnen Agile wendbaar en innovatief willen zijn. Vertrouwen en samenwerking zijn hierbij de sleutelwoorden. We zullen vertrouwen in elkaar en elkaars vakkennis moeten hebben en de samenwerking moeten zoeken. Dit lijkt ineens een heel stuk minder SMART. Daar waar traditioneel beheer vooral efficiënt moet gebeuren, willen we juist dat Agile beheer effectief is. Agile binnen beheer lijkt op een tegenstrijdigheid, misschien zelfs wel op een onmogelijkheid.
Is het dan wel mogelijk om Agile te beheren? Laten we uitgaan van het feit dat de behoefte van de business voorop staat, dit doen we immers binnen een Agile project ook. Hoe ziet Agile beheer eruit ten opzichte van incident-, problem- en change-management? In traditioneel beheer maken we keurige afspraken over reactie- en oplostijden. De vraag is echter wat het voordeel hiervan voor de business is. Waarom lossen we incidenten met een lage prioriteit eerder op dan die belangrijke wijziging waar de business zo’n behoefte aan heeft? Vanwege de sla-afspraak die gemaakt is? Dit gebeurt binnen beheer maar al te vaak en leidt tot frustratie en onbegrip bij de business.
Andere manier van werken
Agile loslaten op de beheer processen betekent niet dat je alle afspraken, tools en middelen los laat. Agile beheren betekent een andere manier van werken. De toegevoegde waarde voor de business moet voorop staan. De beheerder zal anders moeten gaan kijken naar de 'wereld van beheer'. De business moet betrokken worden. Er zal meer in een samenwerking moeten worden gewerkt waardoor er minder wordt gestuurd op input en meer op output.
Werkwijzen moeten gedereguleerd worden en contracten vereenvoudigd. De ‘zachte kant’ is cruciaal: wederzijds vertrouwen vormt de basis. Klant en leverancier zullen elkaar moeten vertrouwen. Doen ze dit niet of onvoldoende, dan is de kans van slagen nagenoeg nihil.
Tot slot. In de veranderde it-wereld verandert de business mee. De business van nu verwacht wendbaarheid en snelheid en met Agile kan aan deze wensen worden voldaan. Tot voor kort was dit alleen weggelegd voor de kant van ontwikkeling, de projecten. Deze wendbaarheid kan echter zeker binnen beheer geleverd worden! Houd er wel rekening mee dat Agile-beheer niet het volgende model is, dat simpel ingevoerd kan worden. Agile-beheer is een mindset, ervaar en doorleef het met elkaar, binnen het hele speelveld van beheer.
Reacties
Ik begrijp het concept achter agile. De vraag zal hier moeten worden gesteld in hoeverre zich dit zal gaan verhouden met de materie IT. De vraag die je je hier zal moeten stellen is de volgende;
Als de brug tussen IT en non IT management, nog steeds niet op stevige pijlers is gefundeerd, heeft dat voor alsnog de allerhoogste prioriteit.
Dat om twee redenen. IT onderhoud word nu nog steeds veel teveel bepaald door professionals die misschien juridisch aardig onderlegd zijn, maar geen pepernoot verstand hebben van IT. Doe in dat smeltkroesje nog even een eetlepel commercie en..... je hebt wat je nu hebt. IT beheer en materie niet op elkaar afgestemd.
Doe er nu even als component bij dat men de senior IT professional in vier jaar tijd aardig heeft afgeserveerd en nu staat te roepen de 'young upcoming professional' of dat 'talent' maar niet te kunnen vinden.....
De grootschalige incidenten nemen hand over hand toe doordat de ervaring van IT ketenwerking in vier jaar tijd volkomen is gereduceeerd met tal van gevolgen van dien. Lees hier even de perikelen zoals C2000, 112, EPD, niet werkende IT beheer bij Eneco, RWS, politie academie en vele andere overheids en corporate organisaties.
Met alle respect voor dhr. Martens hier. Wanneer men in het speelveld van o.m. beheer maar niet wil begrijpen dat afstemmen op de werking en wetmatigheden van IT veel essentiëler zijn dan men beseft, gaan die incidenten toenemen, ook in intentie en uitwerking.
Dat gaat u met een agile mindset niet oplossen doordat heel agile geen idee heeft van de niet zo flexibele maar statische werking van IT. Ik ben bang dat agile in IT niet echt een toegevoegde waarde zal hebben.
Michel,
Zolang de coding cowboys beheer als indianen blijft zien is Agile nog niet klaar voor beheer want release management is meer dan een versie opleveren. Wendbaarheid is leuk maar als dit zonder onderhoudbaarheid gaat blijft er altijd frictie zitten tussen ontwikkeling en beheer.
Even voor de duidelijkheid, wettelijke bewaartermijnen voor veel data overschrijden meermaals de levensduur van veel applicaties. En user interfaces zijn leuk voor gebruikers maar beheer wil gewoon een command-line hebben.
Eigenlijk wil ik de vraag omdraaien, gegeven het feit dat "beheer" een langer bestaansrecht kent dan "agile"
Is Agile wel geschikt voor alle omgevingen ???
Mijns inziens sterk omgevings-afhankelijk. Het maakt nogal een verschil of je enkele updates per week uit wil voeren op bijv. deze website, of dat meerdere updates per week uit wil voeren op bijvoorbeeld de software van een vliegtuig.
ICT kent vele vormen, en er is niet één methode die overal goed werkt, maar daarover binenkort meer :)
@Numoquest: "grootschalige incidenten nemen hand over hand"
deels komt dat niet alleen door gebrek aan kennis, maar vaak door de al jaren voortdurende technische en functionele integratie, waardoor "vroeger" een calamiteit een beperkte omvang had, maar nu heeft dat door die integratie een veel grotere impact, ook nog omdat we met minder verschillende toen nog deels overlappen de (communicatie) middelen zaten. Het is dus meer dan kennis gebrek alleen..
Grappig artikel, maar weinig concreet omdat de ene beheeromgeving de andere niet is. Ik denk dat het eventueel alleen kan werken als de business en de beheerpartij heel dichtbij elkaar staan, en als de scope heel erg beperkt is, bijvoorbeeld 1 applicatie of een set van applicaties van 1 business partij (bijvoorbeeld de HR applicaties).
"de" business bestaat namelijk niet: wat voor de ene business partij onbelangrijk is (een storing in een drukwerkprinter bijvoorbeeld) kan voor de andere business partij (in dit geval de marketing afdeling) juist heel belangrijk zijn. Wie bepaalt dan welke business partij als eerste geholpen wordt?
En hoe weet je vantevoren welke skills je de komende periode nodig hebt? In de ene "sprint" heb je veel crisis types nodig vanwege een groot incident (dat je meestal niet ziet aankomen) en de andere keer heb je juist bouwers en testers nodig die een wijziging tot een einde kunnen brengen. Dat succesvolle einde komt in gevaar als een incident opeens voorrang krijgt. Voor een prio-1 incident is het sowieso moeilijk "pokeren", je weet immers vaak niet wanneer het optreedt en wat de oorzaak is. Je hebt kortom veel verschillende (beheer)skills nodig en daarvoor ontbreekt vaak de flexibiliteit in de resource pool - en die flexibiliteit staat weer haaks op het agile uitgangspunt dat je met ervaren medewerkers/een ingespeeld team dient te werken.
Als project en beheer volledig bij dezelfde partij belegd zijn, dan kan er nog wel iets geschoven worden, maar als dat verschillende partijen zijn (beheer heb je bijvoorbeeld geheel of gedeeltelijk geoutsourced) dan wordt het - veel - lastiger.
In mijn (beheer)team hebben we inmiddels wel de daily standup ingevoerd: wat hebben we gisteren gedaan, welke activiteiten gaan we vandaag afhandelen, welke issues komen we tegen en welke procesverbeteringen ("user stories"!) zijn er nodig om deze issues op te lossen?
@ Maarten
Deels kan ik me wel in je visie vinden. Wanneer je ervaring laat verwateren door veravngng, zoals ik beschreef, dan is het een kwestie van wachten op. Het is maar net natuurlijk op welk niveau dat plaats vind. Sinds 2009, pak hem beet, is dat in de hele keten het geval.
Kijk dan ook even naar het 'door de strot proberen te duwen van commercie' en dat draagt dan eveneens bij tot. Laat men eerst maar eens zorgen voor een stabiele omgeving, dat is op zich al dynamisch genoeg om dan weer iets te 'roeptoeteren' over Agile in beheer.
Agile is domweg als 'mindset' niet eens geschikt voor iets statisch als IT. Zo eenvoudig is dat.
Ik snap niet wat een ondersteunende ontwikkelaar methodiek bij een beheer club zou moeten doen.
Hoeveel beheerders hebben Prince2, DSDM, RUP, RAD en andere soort certificeringen?
Zoals Ewout aangeeft met zijn Cowboys en Indianen, hebben de clubjes nogal verschillende belangen.
Beheerders willen continuïteit en stabiliteit en ontwikkelaars willen nieuwe features en mogelijkheden realiseren.
Doordat de vernieuwingen soms zo snel gaan dat de stabiliteit in geding komt, heeft men principes zoals de OTAP straat ingeregeld.
Het doet me denken aan een voorkant van een stripblad van vroeger "Wordt vervolgd". Hierop stond Dhr. Fortuin bij zijn buurman waar hij een 2de hands vaatwasmachine aan verkocht had, uit te leggen dat hij niet begreep waarom er iets mis zou zijn met het apparaat. "De scherven waren immers blinkend schoon!"
Ik vind het punt dat Michel aansnijdt zeer relevant. Het is echt een punt van aandacht aan het worden, ook bij mijn werkgever. Het gaat hier om twee belangrijke processen die nu qua tempo gaan verschillen. Dat geeft frictie bij beide. De fase waarin wij nu zijn is dat we nog verder standaardiseren op de wijze waarop we software opleveren aan de "beheerorganisatie". Tussen quotes omdat we enerzijds de software daarna nog uitleveren aan onze klanten of als cloud service inrichten.
We hebben nu te maken met 3 cycli: development in sprints, beheer in releases en klantorganisaties met een heel eigen dynamiek.
We kijken goed rond hoe we dat gaan afstemmen op elkaar, daarom dank voor dit artikel.
@PavaKe wat heeft de frequentie van releasen volgens jou te maken met de kwaliteit van de software? Ik zie er geen direct verband tussen. Je kunt minder vaak releasen en slecht testen en andersom.
Ik kom nog veel "oud denken" tegen: dat langzaam en handmatig werk goed is voor de beheer(s)baarheid. Maar er is een nieuwe ontwikkeling die het precies andersom doet: snel en geautomatiseerd, ondersteund door rigide configuratie management en geautomatiseerde testsuites. Dan loop je minder risico, gebeurt het sneller en is het vaak (uiteindelijk) nog goedkoper ook...
"De business van nu verwacht wendbaarheid en snelheid en met Agile kan aan deze wensen worden voldaan. Tot voor kort was dit alleen weggelegd voor de kant van ontwikkeling, de projecten. Deze wendbaarheid kan echter zeker binnen beheer geleverd worden!"
makkelijk gesteld, zonder onderbouwing.
Een van de fundamenten van Agile is dat je veranderingen zo vroeg mogelijk probeert te integreren in je product. Alleen bij ontwikkeling en projecten zit natuurlijk altijd in een proces dat bezig is met ontikkeling of verandering. Er mag dus mee (unit + integration) getest worden en het hoeft nog niet robust te zijn. Das nogal anders een IT infrastructuur met bedrijfskritische Servers en Netwerkcomponenten. Welk bedrijf financiert een goed werkende OTAP straat ?
zal wel op iets uitdraaien van : Waaat ? beheerders die niet Agile willen werken ? OUTsourcen die zooi ! :-)
@NumoQuest
"Agile is domweg als 'mindset' niet eens geschikt voor iets statisch als IT. Zo eenvoudig is dat."
Zo eenvoudig vind ik eigenlijk niet. Kun je deze stelling onderbouwen met bewijs? Hoezo is IT is statisch? Ik ben ook benieuwd welke definitie van 'statisch' je hier gebruikt en hoe dit samenhangt met IT.
@Anko ... ik heb het nergens over kwaliteit gehad volgens mij
Wat ik bedoel te zeggen is dat je als ontwikkelomgeving weliswaar in hoog tempo releases naar buiten kunt brengen (bijv. iedere 3 weken), maar je beheersomgeving een test-traject kent van bijv. 4 weken eer je iets uit kunt rollen, dan passen deze 2 omgevingen dus niet op elkaar.
Fijn artikel en dito reacties. Zoveel perspectieven en meningen, daar moet wat moois uit te halen zijn!
De doorlooptijden van in productie nemen van veranderingen in software moet dus korter worden. Je ziet dat veel start-ups, maar ook een traditioneel log bedrijf zoals Microsoft dit steeds beter lukt. Zo zijn er zeker maandelijks veranderingen bij Windows Azure en de veranderingen lijken steeds sneller te gaan.
Het falen van Windows Azure heeft gevolgen voor duizenden klanten, dus het is heel knap dat een groot bedrijf met een complex product blijkbaar agile beheer lijkt te hebben.
Doen ze dat door er veel geld tegenaan te gooien? Ik denk het niet. Zoals Michel schrijft, het is een mindset. En natuurlijk heb je de juiste mensen nodig die aan de ene kant "streng en robuust" zijn, maar aan de andere kant niet bang om snel te schakelen.
In een wereld waarbij cloud computing en uitbesteden van software de norm wordt, lijkt snelle releases steeds belangrijker te worden. Je beheer zal dus wel agile ofwel behendig moeten worden! En zo blijkt hoeft dat helemaal niet "quick and dirty" te zijn. Het is gewoon topsport en de lat wordt steeds hoger gelegd.
@Anko: Quote:
"Ik kom nog veel "oud denken" tegen: dat langzaam en handmatig werk goed is voor de beheer(s)baarheid."
Ik hoop dat dit 'oud denken' door niet IT personeel gedaan wordt?
Handmatig is naar mijn beleving gewoon een scheldwoord voor een beetje automatiseerder.
Coding cowboys die het over 'oud denken' hebben maar werken volgens het stramien van:
10 Develop
20 Test
30 Run
40 GOTO 10
Het begint steeds meer op een 'spaghettiwestern' te lijken;-)
Mooie discussie.
Mijn eigen ervaring: in een kleine, hechte omgeving kun je meer op "change" richting :wensen eigen club" spelen. Bij grote bureaucratische organisaties is alles zowel juridisch als politiek meer star, en is 't oplossen van incidenten gemakkelijker dan "het systeem" veranderen. Bovendien is "eigen club" dan vaak de IT club vs de rest.
Eens met Michel: mindset en dereguleren. Maar dat is idd, zoals velen hier betogen, niet overal mogelijk of zelfs maar wenselijk.
Overigens: beheer was in 't begin "agile". Alles begint klein en wendbaar. Beheerders waren de gebruikers en omgekeerd. ITIL was een reactie op groei en toenemende complexiteit. Die twee hebben kennelijk vaak een prijs...
@PaVaKe Vind dat een scherpe opmerking. Inderdaad is de nieuwste gril van het agile werken (Wat is dat eigenlijk?) de continous delivery. Als dat betekent dat je steeds op een korte termijn nieuwe releases in productie moet nemen dan ben ik het met je eens dat dat voor kritische applicaties niet geschikt is. Iedere nieuwe release die je invoert houdt een risico in, dat is niet wat je wilt in deze gevallen.
@Anko Dat is misschien oud denken maar ik denk dat het verstandig is om soms conservatief te zijn. Software is niet iets wat op een lopende band geproduceerd wordt ook al wekt de agile+ beweging een andere indruk. Het gaat niet om langzaam en handmatig, het gaat om risico en zorgvuldigheid. Kost misschien tijd. Minder risico is niet voldoende, je moet zeker van je zaak zijn. Zeker bij kritische applicaties.
@Henri Aan het beheer zal het niet liggen om snelle releases door te voeren. Vervelend is het als je als beheer geconfronteerd wordt met issues door nieuwe releases. En nog vervelender is dat voor de business. Dan is het zeker topsport. Nogmaals, je beheer is zo goed als je software.
@ mdv1984
http://www.numoquest.nl/Civile%20Matrix%20NL.pdf kun je geheel vrij de uitleg oppikken. Mocht je daarna nog vragen hebben dan zie ik die met interesse tegemoet.
Het lijkt erop dat Michel projecten ziet als iets dat los staat van IT beheer. Ik denk dat hij hierbij uitgaat van het gegeven dat iets dat ontwikkeld wordt pas “in beheer” wordt genomen als het klaar is, terwijl ontwikkeling juist onlosmakelijk met beheer is verbonden. Immers, verwijdering, wijziging, ontwikkeling of inkoop van (nieuwe) functionaliteit betekent een wijziging op het bestaande in beheer zijnde informatiesysteem. De grootte of complexiteit van een Change maakt daarbij niet uit, mits goed beschreven is wie wat doet op welk moment in die procedure.
Als in de uitvoering van de Changeprocedure is gekozen voor een agile aanpak dan komen er uit dat proces kleine stukjes werkende software die in hetzelfde tempo als ze ontwikkeld worden in beheer worden genomen. Minstens een agile in beheer name.
Het dagelijks beheer op een functionerend informatiesysteem kenmerkt zich door een groot aantal activiteiten waarvan de meeste, op basis van de vraag vanuit de gebruikersorganisatie, inderdaad geen hoge prioriteit hebben, maar wel snel afgehandeld worden. Als dat een bezwaar dan is de vraag relevant door wie ze afgehandeld worden. Als dat degenen zijn die eigenlijk bijvoorbeeld in je Changeprocedure actief zouden moeten zijn of stevige incidenten moeten oplossen, dan heb je inderdaad een probleem.
Agile beheer heeft daarom veel te maken met kennisoverdracht en het er voor zorgen dat de simpele veel voorkomende taken zo veel mogelijk aan de voorkant kunnen worden afgehandeld, bijvoorbeeld door een skilled Servicedesk.
Hoger opgeleide of meer ervaren beheerders kunnen zich dan concentreren op het realiseren van (niet-standaard) changes, hebben de tijd dit goed te documenteren en vervolgens te standaardiseren waardoor ze blijvend aan vernieuwing, verbetering en groot onderhoud kunnen blijven werken en de kennis in de vorm van gestandaardiseerde oplossingen middels werkinstructies beschikbaar komt voor Servicedesk en junior of medior beheerders.
Als dat principe goed functioneert kom je naar mijn smaak al aardig in de buurt van wat je agile beheer zou kunnen noemen. Voorwaarde is dan wel dat je je niet verliest in een al te uitgebreide inrichting van je procesorganisatie, maar je bedient van een geïntegreerde set basisprocessen en daarbinnen managet op het maken van afspraken en blijvend structureel verbeteren.
Nog even een toevoeging. Ik kan me voorstellen dat je in je ontwikkel en teststraat zo snel mogelijk nieuwe versies beschikbaar wilt stellen voor de testers. Dat zou je inderdaad continous delivery kunnen noemen en het is nog mooier als je dan met 1 druk op de knop kan doen. Als dit ook zo is voor je productieomgeving, hele korte releasetijden dan denk ik dat er iets grondig mis is met je project. Dan lijkt het erop dat je zaken in productie neemt die nog niet af zijn. Je neemt toch pas iets in productie als het getest en goed bevonden is door gebruikers/opdrachtgever? Nu zal het altijd van je applicatie afhangen of er continu wijzigingen noodzakelijk zijn. Zoals @PaVaKe het aangaf, bij websites valt daarbij iets voor te stellen. Als voor systemen geldt dat de werking 'continu' gewijzigd moet worden dan lijkt me dat meer een randvoorwaarde en zul je het meer moeten zoeken in configuratie van een systeem en niet in de software.
Vanuit beheer worden in de regel eisen gesteld aan de software die in productie genomen moeten. Wat verwacht de beheerafdeling hoe de software aangeleverd wordt, wat zijn bijvoorbeeld de eisen mbt logging, wat zijn de eisen met betrekking to systeemeisen om iets te noemen. Inderdaad dus wijs om de ook de beheerafdeling te betrekken in het ontwikkelproces, ook dat zijn eisen die meegenomen moeten worden in een ontwikkeltraject.
Verder vind ik het opvallend dat zich in de discussies zich steeds een een tegenstelling aftekent tussen de praat-IT en de uitvoerende-IT. Het valt me ook op dat als ik vacatures zie voor aansturende, procesbegeleidende IT zie dat daar nauwelijks technische eisen gesteld worden. Dat is toch wel vreemd, er wordt geoordeeld over iets waar eigenlijk geen inhoudelijke ervaring mee is.
Zo veel mensen zo veel meningen, leuk.
Zoals uit de vele reacties al blijkt: One size doesn't fit all! Wat ik in veel reacties ook denk te lezen, is dat er vooral wordt stil gestaan bij de project methodiek Agile en wat minder bij het idee om als beheer wendbaarderder te zijn, de "mindset". Dat gaat m.i. verder dan het in beheer nemen van projecten en changes. Bij dit "wendbaarder" zijn kijk je veel meer naar de vraag van de business, wat voegt nu echt waarde toe voor de business en op basis daarvan ga je aan de slag. En niet puur op basis van wat heb ik in een SLA afgesproken en wat zijn de KPI's
Als je kijkt naar devops, dan sla je vooral een brug tussen ontwikkeling en beheer. Wat ik met Agile binnen beheer probeer aan te duiden is ook het slaan van een brug tussen beheer en de business.
Ik denk toch dat er geen draagvlak voor zal zijn. Tuurlijk zal Best Effort van een creatieve beheerder soms veel mooiere oplossingen bieden dan een grijze doorgekauwde SLA.
Maar zonder die SLA kunnen de bureaucraten, legal en finance niet meer touwtrekken en komen een hoop banen op de tocht staan ;)