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.
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 ! 🙂