Is, nu Agile succesvol is gebleken in de projectenwereld, het de beurt aan beheer? Anders gezegd, is beheer klaar voor Agile? Aan de ene kant volgen ontwikkelingen elkaar razendsnel op en deze moeten allemaal in beheer genomen worden. Dit vraagt om een zekere mate van wendbaarheid, maar wendbaarheid is niet echt het kenmerk van beheer. Aan de andere kant eisen klanten steeds meer flexibiliteit van hun beheerpartner.
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.
@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.