Het is al weer bijna 2010. Een jaar waarin ik in ieder geval weer hard ga werken aan alles wat me weer op mijn pad komt.
Helaas is dit ook de awareness op gebied van Agile en Scrum.
Het is me opgevallen dat veel mensen gehoord hebben van Agile en dat als men commercieel is aangelegd dit een goed nieuw woord vindt.
Jammer genoeg is dat vaak alles wat men weet. Als men engels onderlegd is kan je zelfs de vertaling om je oren krijgen. Echter is het woord niet een veelgebruikt woord. Dus ook de vertaling laat soms te wensen over en met komt aan me "oh, da's toch een hondensport?"
Yep, dat klopt, een heel leuke hondensport zelfs, maar da's niet wat ik ermee bedoel.
Bij mijn werkgever merk ik dat het nu vooral als buzzword veel genoemd wordt, en eerlijk is eerlijk, ik help ook niet met het woord te pas en te onpas te laten vallen ;)
Daarom bied ik regelmatig aan eens te praten over Agile, om uit de doeken te doen wat het nu precies is.
Maar wat is Agile?
Is het een buzzword? Is het gewoon een woord dat we gebruiken als we het hebben over een iteratieve methodiek?
Ik moet vaak vertellen wat het niet is. Veel vooroordelen komen naar boven als mensen al eens gelezen hebben over Agile. "Dat is toch als je geen requirements hebt en je dus als team zelf kunt uitmaken wat je maakt?"
Soms maakt me dit moedeloos om te zien hoe vaak ik zo'n misverstand tegen kom. En dan is het lekker om een met een groep mensen die WEL weten wat Agile is te praten.
Kun je het uitleggen? Wat Agile is?
Friday, December 25, 2009
Friday, December 18, 2009
Het einde van een coaching
Deze week werd het al duidelijk. Mijn opdracht hield op.
Ik ben de afgelopen maanden betrokken geweest bij een project als Scrum coach.
Het nadeel van de rol van scrum coach in deze was het feit dat ik daarbij geen bevoegdheden had. Natuurlijk kon ik met iedereen praten en adviezen geven, echter was het wat mij betreft makkelijker geweest als ik hierbij de rol van Scrum Master had gekregen en dan geleidelijk een Scrum master had kunnen inweiden.
Het had misschien niets uitgemaakt, want het bleek al heel snel dat we als team voornamelijk tegen een aantal standaard scrum smells aanliepen.
Een van de teamleden was bijna onmisbaar in zijn rol als troubleshooter voor voornamelijk belangrijke processen zoals applicaties die in productie draaiden. Troubleshooting bleek toch eigenlijk wel 75-80% van zijn tijd, en daarnaast een medezeggenschap rol in de organisatie.
Wel had hij een zeer belangrijke competentie voor het team welke niet kon worden overgenomen.
Een ander aspect binnen de organisatie was de indeling binnen het bedrijf van de verschillende afdelingen. Zo was er een afdeling die de requirements beheerde, een afdeling die de functionele ontwerpen deed, een testafdeling, etc. Ofwel, de verschillende V model rollen waren aanwezig in de organisatie als afdelingen, en daarbij hadden we volgens de procedure natuurlijk alle afdelingen nodig. In principe heb ik geen probleem met de indeling van afdelingen in de V model competenties. Echter verwacht ik dan wel een matrix organisatie waarbij ik dan van elke afdeling een "resource"kan verkrijgen voor het team (en voor 100%). Het nadeel van zo'n team zou natuurlijk wel de hele duidelijke differentiatie van disciplines zijn. Helaas was dat laatste ook voor het team in mijn opdracht van toepassing.
We hadden last van onbekendheid met Agile en Scrum, we hadden last van hoge mate van differentiatie in disciplines, we hadden last van de verschillende afdelingen in een waterval configuratie, maar wat er gelukkig goed ging was de drive van het team. Helaas mocht dat het proces niet redden.
eren
De volgende keer zal ik meer proberen af te dwingen wat betreft bevoegdheden, maar helaas heb ik ook dat niet altijd voor het zeggen, want laten we eerlijk wezen, de indeling van de organisatie waar ik voor werk is ook niet echt bevorderlijk voor een Agile opdracht.
Ik ben de afgelopen maanden betrokken geweest bij een project als Scrum coach.
Het nadeel van de rol van scrum coach in deze was het feit dat ik daarbij geen bevoegdheden had. Natuurlijk kon ik met iedereen praten en adviezen geven, echter was het wat mij betreft makkelijker geweest als ik hierbij de rol van Scrum Master had gekregen en dan geleidelijk een Scrum master had kunnen inweiden.
Het had misschien niets uitgemaakt, want het bleek al heel snel dat we als team voornamelijk tegen een aantal standaard scrum smells aanliepen.
Een van de teamleden was bijna onmisbaar in zijn rol als troubleshooter voor voornamelijk belangrijke processen zoals applicaties die in productie draaiden. Troubleshooting bleek toch eigenlijk wel 75-80% van zijn tijd, en daarnaast een medezeggenschap rol in de organisatie.
Wel had hij een zeer belangrijke competentie voor het team welke niet kon worden overgenomen.
Een ander aspect binnen de organisatie was de indeling binnen het bedrijf van de verschillende afdelingen. Zo was er een afdeling die de requirements beheerde, een afdeling die de functionele ontwerpen deed, een testafdeling, etc. Ofwel, de verschillende V model rollen waren aanwezig in de organisatie als afdelingen, en daarbij hadden we volgens de procedure natuurlijk alle afdelingen nodig. In principe heb ik geen probleem met de indeling van afdelingen in de V model competenties. Echter verwacht ik dan wel een matrix organisatie waarbij ik dan van elke afdeling een "resource"kan verkrijgen voor het team (en voor 100%). Het nadeel van zo'n team zou natuurlijk wel de hele duidelijke differentiatie van disciplines zijn. Helaas was dat laatste ook voor het team in mijn opdracht van toepassing.
We hadden last van onbekendheid met Agile en Scrum, we hadden last van hoge mate van differentiatie in disciplines, we hadden last van de verschillende afdelingen in een waterval configuratie, maar wat er gelukkig goed ging was de drive van het team. Helaas mocht dat het proces niet redden.
eren
De volgende keer zal ik meer proberen af te dwingen wat betreft bevoegdheden, maar helaas heb ik ook dat niet altijd voor het zeggen, want laten we eerlijk wezen, de indeling van de organisatie waar ik voor werk is ook niet echt bevorderlijk voor een Agile opdracht.
Thursday, December 10, 2009
Agile testen
Mijn werkgever Sogeti is een marktleider op het gebied van testen.
Vandaag heb ik een stukje geschreven voor een nieuw Agile magazine.
Hieronder wat ik schreef:
Is there such a thing as an Agile tester?
There has always been one aspect I have found obscure in Agile. Even though everyone knows it is part of the package, Agile testing has always been somewhat of a mystery. Agile is a very natural approach to our daily work in software engineering. It is also a very attractive approach and oftentimes it becomes a way of thinking.
With the advent of test awareness, with this i mean the realization testing is not something trivial anymore, we also realize that Agile testing has still not come of age. Even though testing itself has become a mature element within our field.
As software engineer and project manager I have seen this develop from the sidelines (yes, I used to work in teams where testing was mainly the work of testers and as software engineer you passed your package to a tester, not doing more than the happy flow yourself).
When I joined Sogeti I slowly realized how professional testing had become. Being an Agile advocate I now feel Agile testing has to develop along.
But with multidisciplinary teams within Agile, does the average team member also have to be able to do everything a tester does. Does an Agile developer also have to be an Agile tester?
This question has kept me busy a lot as I worked on developing my workshop and while I coached and advised clients on the Agile approach.
For myself i have developed the following view:
Within Agile, the teams are indeed as multidisciplinary as possible. Yet i have found in practice this means there's still a high level of differentiation within the team. This is only natural as every individual has different interests, passions and experiences. This is also beneficial to the project they are working on. Most of the time the experience and knowledge is part of the domain they work in, but sometimes it is more generally defined, like architecture, infrastructure, databases and of course testing. Within traditional approaches testing has been an underappreciated activity. Most of the time testing was the last part of a project for which not much time had been reserved on the planning or which, being the tail-end of the work, time had been cannibalized by more "important" activities.
I personally think differentiation within a team is not to be avoided. Within Scrum for instance a team is not larger than 9 people and with many disciplines needed to resolve complex problems it seems logical that one or the other will know more on certain subjects than others.
Due to previous approaches within information technology we have many specific differentiations, one of which is the tester.
Let's be honest, many times a tester is a different type of person. They are usually more precise, more consistent and analytical. Most are pitbulls and can be very stubborn when it comes to preventing the slipping of quality.
Within Agile the discipline testing has a very wonderful best practice that I am really fond of "Test Driven Development" it shows a very clear image of what position testing should take within a software engineering project. It has to saturate it, to be there from the beginning to the end.
Within an Agile team that is what i see for a tester, assisting and educating the developer. Especially the latter seems to be very important in current day and age.
An experienced tester within your Agile team is something that is needed for it to not fail. You can see it when you play planning poker with a new team. The developers, having done the task they see on the list before, estimating it to be inconsequential. Testers sometimes realize the importance of the change and will estimate it to be significant. This has opened the eyes of many developers. Within Agile things get more visible, also the consequences of the actions of a developer. This is usually very educational for the developer.
So to answer the title I gave to this piece. Is there such a thing as an Agile tester?
Yes, an Agile tester is an indispensable part of a team, and acts as a coach to the team concerning testing and quality.
What I expect for the future of Agile teams and the role of testing in it is that testing will more and more become a part of the work of developers. A dedicated tester within a team may more and more become a differentiation of a team member. With this I mean that every member of an Agile team will have to know more about testing than they currently do, but there will always be someone who knows testing as his or her speciality, as a passion . Will the Agile tester be replaced by a multidisciplinary teammember, who knows every aspect of software engineering and can take over from another teammember? This seems very unlikely. After all, one of the Agile principles is "Individuals and interactions over processes and tools", the word "Individuals" sticks out in this matter. Lets not lose that.
Vandaag heb ik een stukje geschreven voor een nieuw Agile magazine.
Hieronder wat ik schreef:
Is there such a thing as an Agile tester?
There has always been one aspect I have found obscure in Agile. Even though everyone knows it is part of the package, Agile testing has always been somewhat of a mystery. Agile is a very natural approach to our daily work in software engineering. It is also a very attractive approach and oftentimes it becomes a way of thinking.
With the advent of test awareness, with this i mean the realization testing is not something trivial anymore, we also realize that Agile testing has still not come of age. Even though testing itself has become a mature element within our field.
As software engineer and project manager I have seen this develop from the sidelines (yes, I used to work in teams where testing was mainly the work of testers and as software engineer you passed your package to a tester, not doing more than the happy flow yourself).
When I joined Sogeti I slowly realized how professional testing had become. Being an Agile advocate I now feel Agile testing has to develop along.
But with multidisciplinary teams within Agile, does the average team member also have to be able to do everything a tester does. Does an Agile developer also have to be an Agile tester?
This question has kept me busy a lot as I worked on developing my workshop and while I coached and advised clients on the Agile approach.
For myself i have developed the following view:
Within Agile, the teams are indeed as multidisciplinary as possible. Yet i have found in practice this means there's still a high level of differentiation within the team. This is only natural as every individual has different interests, passions and experiences. This is also beneficial to the project they are working on. Most of the time the experience and knowledge is part of the domain they work in, but sometimes it is more generally defined, like architecture, infrastructure, databases and of course testing. Within traditional approaches testing has been an underappreciated activity. Most of the time testing was the last part of a project for which not much time had been reserved on the planning or which, being the tail-end of the work, time had been cannibalized by more "important" activities.
I personally think differentiation within a team is not to be avoided. Within Scrum for instance a team is not larger than 9 people and with many disciplines needed to resolve complex problems it seems logical that one or the other will know more on certain subjects than others.
Due to previous approaches within information technology we have many specific differentiations, one of which is the tester.
Let's be honest, many times a tester is a different type of person. They are usually more precise, more consistent and analytical. Most are pitbulls and can be very stubborn when it comes to preventing the slipping of quality.
Within Agile the discipline testing has a very wonderful best practice that I am really fond of "Test Driven Development" it shows a very clear image of what position testing should take within a software engineering project. It has to saturate it, to be there from the beginning to the end.
Within an Agile team that is what i see for a tester, assisting and educating the developer. Especially the latter seems to be very important in current day and age.
An experienced tester within your Agile team is something that is needed for it to not fail. You can see it when you play planning poker with a new team. The developers, having done the task they see on the list before, estimating it to be inconsequential. Testers sometimes realize the importance of the change and will estimate it to be significant. This has opened the eyes of many developers. Within Agile things get more visible, also the consequences of the actions of a developer. This is usually very educational for the developer.
So to answer the title I gave to this piece. Is there such a thing as an Agile tester?
Yes, an Agile tester is an indispensable part of a team, and acts as a coach to the team concerning testing and quality.
What I expect for the future of Agile teams and the role of testing in it is that testing will more and more become a part of the work of developers. A dedicated tester within a team may more and more become a differentiation of a team member. With this I mean that every member of an Agile team will have to know more about testing than they currently do, but there will always be someone who knows testing as his or her speciality, as a passion . Will the Agile tester be replaced by a multidisciplinary teammember, who knows every aspect of software engineering and can take over from another teammember? This seems very unlikely. After all, one of the Agile principles is "Individuals and interactions over processes and tools", the word "Individuals" sticks out in this matter. Lets not lose that.
Friday, December 4, 2009
Nieuwe scrummers?
Er is de laatste tijd veel discussie op Scrum groepen over juist gebruik van Scrum na de invoering.
Ik heb een nogal duidelijk beeld hierop voor mezelf.
Indien ik aan de slag ga met een nieuwe Scrum invoer, dan zal ik deze zo puur mogelijk insteken.
Om iets goed te leren moet je het eerst goed doen. Scrum heeft een duidelijke samenhang. Indien je aan het begin al concessies doet met betrekking tot het framework dan zullen de deelnemers hieraan nooit weten hoe het eigenlijk moet.
Een goed begin is het halve werk. Dat geldt zeer zeker voor de invoer van een nieuw process.
Natuurlijk brengt zo'n verandering weerstand met zich mee. Dit is waar voor elke verandering.
Een organisatie die vraagt of je helpt met het invoeren van een nieuwe manier van werken geeft op zich al aan dat ze bepaalde verandering zullen accepteren. De weerstand zal aanwezig zijn, echter door de welwillendheid soepeler.
Als je het proces later recht wil buigen zul je meer weerstand tegen komen. Probeer het zuiver te houden is mijn devies.
Nadat een Team veel ervaring heeft opgedaan is het altijd mogelijk dat men door voortschrijdend inzicht proceswijzigingen verzoekt.
Indien dat gebeurd zijn er legio voorbeelden en adviezen in de literatuur en de "cloud" te vinden om uit te putten als je zo'n proceswijziging overweegt.
Hou het Agile.
Ik heb een nogal duidelijk beeld hierop voor mezelf.
Indien ik aan de slag ga met een nieuwe Scrum invoer, dan zal ik deze zo puur mogelijk insteken.
Om iets goed te leren moet je het eerst goed doen. Scrum heeft een duidelijke samenhang. Indien je aan het begin al concessies doet met betrekking tot het framework dan zullen de deelnemers hieraan nooit weten hoe het eigenlijk moet.
Een goed begin is het halve werk. Dat geldt zeer zeker voor de invoer van een nieuw process.
Natuurlijk brengt zo'n verandering weerstand met zich mee. Dit is waar voor elke verandering.
Een organisatie die vraagt of je helpt met het invoeren van een nieuwe manier van werken geeft op zich al aan dat ze bepaalde verandering zullen accepteren. De weerstand zal aanwezig zijn, echter door de welwillendheid soepeler.
Als je het proces later recht wil buigen zul je meer weerstand tegen komen. Probeer het zuiver te houden is mijn devies.
Nadat een Team veel ervaring heeft opgedaan is het altijd mogelijk dat men door voortschrijdend inzicht proceswijzigingen verzoekt.
Indien dat gebeurd zijn er legio voorbeelden en adviezen in de literatuur en de "cloud" te vinden om uit te putten als je zo'n proceswijziging overweegt.
Hou het Agile.
Friday, November 27, 2009
Scrum ontwikkelaars of Microsoft ontwikkelaars
In het laatste jaar heb ik me volledig op Scrum geworpen. En wat me daaraan bevalt is dat ik zo enorm veel geleerd heb.
Ik ben werkzaam bij Sogeti en ben daar een van de meest ervaren professionals op dit gebied. Dit heeft als gevolg dat je voor verschillende trajecten gevraagd wordt, presentaties, workshops, advies en sinds kort door een klant ook als coach op gebied van Scrum.
Ik heb in het scala aan trainingen op dit gebied dan ook een tekort opgemerkt. Meestal zal dit wel door de individuele Scrum Masters worden op gepakt. Maar er is, vind ik, te weinig beschikbaar voor de individu die in een Scrum Team terecht komt.
Uiteraard is Sogeti ook door Microsoft en de Scrum Alliance gevraagd om mee te werken aan de Scrum Professional certificering. Mijn probleem echter toen we werden toegesproken door Ken Schwaber om hen te helpen deze certificering op te zetten is een Agile principe. Individuen en interacties zijn belangrijker dan processen en tools.
En alhoewel ik geen probleem heb met het gebruik van de tool die Microsoft heeft ontwikkeld voor dit doel vond ik het nogal vreemd dat er van de Scrum Professional gevraagd wordt gedurende een flinke tijd te werken met de tool voordat de certificering volgt. Wat nu als men niet met Microsoft tooling werkt? Kun je dan geen certificering krijgen?
Binnen Sogeti heb ik daarom een Scrum cursus/workshop ontwikkeld precies voor deze doelgroep. Het was voor mij een streven Scrum Sogeti in te loodsen toen ik er kwam werken. En samen met een Competence Network (groep fanatiekelingen binnen Sogeti) is dit goed gelukt. Al is er nog veel winst te behalen in het opvoeden van de organisatie op het gebied van Scrum en Agile.
Ik ben werkzaam bij Sogeti en ben daar een van de meest ervaren professionals op dit gebied. Dit heeft als gevolg dat je voor verschillende trajecten gevraagd wordt, presentaties, workshops, advies en sinds kort door een klant ook als coach op gebied van Scrum.
Ik heb in het scala aan trainingen op dit gebied dan ook een tekort opgemerkt. Meestal zal dit wel door de individuele Scrum Masters worden op gepakt. Maar er is, vind ik, te weinig beschikbaar voor de individu die in een Scrum Team terecht komt.
Uiteraard is Sogeti ook door Microsoft en de Scrum Alliance gevraagd om mee te werken aan de Scrum Professional certificering. Mijn probleem echter toen we werden toegesproken door Ken Schwaber om hen te helpen deze certificering op te zetten is een Agile principe. Individuen en interacties zijn belangrijker dan processen en tools.
En alhoewel ik geen probleem heb met het gebruik van de tool die Microsoft heeft ontwikkeld voor dit doel vond ik het nogal vreemd dat er van de Scrum Professional gevraagd wordt gedurende een flinke tijd te werken met de tool voordat de certificering volgt. Wat nu als men niet met Microsoft tooling werkt? Kun je dan geen certificering krijgen?
Binnen Sogeti heb ik daarom een Scrum cursus/workshop ontwikkeld precies voor deze doelgroep. Het was voor mij een streven Scrum Sogeti in te loodsen toen ik er kwam werken. En samen met een Competence Network (groep fanatiekelingen binnen Sogeti) is dit goed gelukt. Al is er nog veel winst te behalen in het opvoeden van de organisatie op het gebied van Scrum en Agile.
Friday, November 20, 2009
Een nieuwe ster
Momenteel is er een ster aan het firmament die steeds helderder gaat stralen. Zoals het een ster betaamd is deze al best oud, echter nu krijgt men die pas in de gaten. Misschien door betere apparatuur waardoor men anders wil en kan gaan werken. Misschien omdat men eindelijk eens een andere kant op kijkt.
Sommigen hebben de ster al lang geleden ontdekt en andere eigenlijk gisteren pas. Maar allemaal zijn ze heel enthousiast, nu ja, allemaal, er zijn er altijd die het maar niets vinden.
Waar praat ik over? Het is niets astronomisch of zelf astrologisch, het heeft te maken met project management en voor een groot deel ook met informatie technologie.
Ik praat hier over Scrum.
Mijn ervaring met Scrum is gezien mijn verdere ervaring niet de langste, het is echter wel de felste. Er is niets waar ik op professioneel gebied momenteel meer passie voor heb als Scrum. Eigenlijk komt dat omdat Scrum zo geweldig past. Het is net als die schoen die je aantrekt in de winkel en waar je het liefste meteen mee de deur uit loopt.
Voor diegene die nog niet van Scrum heeft gehoord zal ik regelmatig hier wat over Scrum vertellen. En natuurlijk is er nog veel meer op het internet te vinden over Scrum. En bij net zo gepassioneerde mensen. Ik hoop dat ik net zo gepassioneerd ben als sommigen, die men ook wel een "Champion" noemt (een kampioen). Maar over mezelf zul je me dat nooit horen zeggen.
Evenmin zul je me horen zeggen dat ik een Guru ben. Om eigenlijk twee redenen, 1) het woord Guru is hopeloos uitgemolken, en 2) er is altijd wat te leren over je passie, Guru betekend "Zwaar" en ik ben altijd een lichtgewicht geweest.
De betekenis van gids wil ik me wel graag aanmeten. Op gebied van Scrum heb ik al veel mensen geenthousiasmeerd en dat is nu wat ik graag doe, en wat ik ook graag hier wil doen.
Mocht je vragen hebben over Scrum dan beantwoord ik ze graag.
Sommigen hebben de ster al lang geleden ontdekt en andere eigenlijk gisteren pas. Maar allemaal zijn ze heel enthousiast, nu ja, allemaal, er zijn er altijd die het maar niets vinden.
Waar praat ik over? Het is niets astronomisch of zelf astrologisch, het heeft te maken met project management en voor een groot deel ook met informatie technologie.
Ik praat hier over Scrum.
Mijn ervaring met Scrum is gezien mijn verdere ervaring niet de langste, het is echter wel de felste. Er is niets waar ik op professioneel gebied momenteel meer passie voor heb als Scrum. Eigenlijk komt dat omdat Scrum zo geweldig past. Het is net als die schoen die je aantrekt in de winkel en waar je het liefste meteen mee de deur uit loopt.
Voor diegene die nog niet van Scrum heeft gehoord zal ik regelmatig hier wat over Scrum vertellen. En natuurlijk is er nog veel meer op het internet te vinden over Scrum. En bij net zo gepassioneerde mensen. Ik hoop dat ik net zo gepassioneerd ben als sommigen, die men ook wel een "Champion" noemt (een kampioen). Maar over mezelf zul je me dat nooit horen zeggen.
Evenmin zul je me horen zeggen dat ik een Guru ben. Om eigenlijk twee redenen, 1) het woord Guru is hopeloos uitgemolken, en 2) er is altijd wat te leren over je passie, Guru betekend "Zwaar" en ik ben altijd een lichtgewicht geweest.
De betekenis van gids wil ik me wel graag aanmeten. Op gebied van Scrum heb ik al veel mensen geenthousiasmeerd en dat is nu wat ik graag doe, en wat ik ook graag hier wil doen.
Mocht je vragen hebben over Scrum dan beantwoord ik ze graag.
Subscribe to:
Posts (Atom)
