Deze week heb ik weer een workshop afgerond.
Een grote groep van 16 cursisten waren aanwezig. Er stonden er 18 op de lijst.
Gelukkig allemaal tevreden naar huis gestuurd. Ik heb helaas nog wat huiswerk meegekregen. Een lijst boektitels die ik al verstuurd heb. En nu nog wat cijfers over gebruik van Scrum in de praktijk.
Eigenlijk dingen die ik zowiezo al in mijn informatie mee wil geven, echter nooit de tijd voor heb gehad, of genomen om toe te voegen.
Voortschrijdend inzicht zeggen we maar.
Ik heb het idee dat de workshop beter wordt, echter komt dit de presentatie niet ten goede. Overigens is dat iets dat onvermijdelijk is. Ik probeer vragen te beantwoorden en niet te vaak te zeggen "dat komt later nog". Er is niets zo naar als mensen een zoveelste cliffhanger voor te schotelen.
Ik verwacht dan ook niet dat ik nooit meer door sheets heen zal swappen om tot de juiste informatie te komen om een vraag te beantwoorden. Dat is nu eenmaal de dynamiek van Scrum en Agile. Maar ik geef toe dat ik het kan beperken.
Binnenkort werk ik maar aan een Scrum Master voortraining. De behoefte neemt toe.
Friday, January 29, 2010
Wednesday, January 20, 2010
Lean!
Gisteravond hadden wij weer onze jaarlijkse Kick Off op het werk.
De hele HMH vol met collega's en een verhaaltje van al onze "executive officers".
Ik zal je de financiële en enthousiasmerende verhaaltjes besparen.
Waar ik wel over wil praten is de opmerking die onze CEO maakte over Lean.
We gaan Bottum Up, Lean introduceren.
Da's een dapper initiatief. Since de meeste mensen nog nooit van lean hadden gehoord. Of misschien wel.
Ik ben er al wel achter dat Lean-Six Sigma in ieder geval al wel bekend is en dat we verschillende kleuren banden al in onze Organizatie hebben rondlopen.
Dit was echter een signaal voor mij en mijn collega Hans-Jurgen om de CEO aan het jasje te trekken.
Ik verwachtte dat dit lastig zou zijn. Met meer dan 3000 medewerkers zullen er altijd collega's zijn die de CEO wilden spreken. Gelukkig ken ik hem via andere kanalen en ik kreeg al snel een hand.
Lean was niet slechts de productie lean zei hij. Het belangrijkste wat hij vertelde was Lean "Bottom Up". Het feit dat het van de professionals moet komen. Verbeteringen in het proces, of knelpunten signaleren en deze oplossen.
Hij gaf overigens aan dat hij specifiek voor Lean gekozen had, niet voor Lean-Six Sigma of een andere methodiek. Dat was wel wat geruststellender, aangezien we nu eenmaal geen productie omgeving kennen.
We hebben hem ook meteen uitgenodigd voor de Open Space die we in februari gepland hebben over Sogeti en Agile. Na wat uitleg van Hans-Jurgen over het concept Open Space zegde hij toe te komen.
Vannacht heb ik maar meteen een mailtje gestuurd met de uitnodiging en een voorstel om Mary Poppendieck eens uit te nodigen.
Lean is iets wat ik me maar snel wat meer eigen ga maken, het lijkt me dat daar vragen over gaan komen.
De hele HMH vol met collega's en een verhaaltje van al onze "executive officers".
Ik zal je de financiële en enthousiasmerende verhaaltjes besparen.
Waar ik wel over wil praten is de opmerking die onze CEO maakte over Lean.
We gaan Bottum Up, Lean introduceren.
Da's een dapper initiatief. Since de meeste mensen nog nooit van lean hadden gehoord. Of misschien wel.
Ik ben er al wel achter dat Lean-Six Sigma in ieder geval al wel bekend is en dat we verschillende kleuren banden al in onze Organizatie hebben rondlopen.
Dit was echter een signaal voor mij en mijn collega Hans-Jurgen om de CEO aan het jasje te trekken.
Ik verwachtte dat dit lastig zou zijn. Met meer dan 3000 medewerkers zullen er altijd collega's zijn die de CEO wilden spreken. Gelukkig ken ik hem via andere kanalen en ik kreeg al snel een hand.
Lean was niet slechts de productie lean zei hij. Het belangrijkste wat hij vertelde was Lean "Bottom Up". Het feit dat het van de professionals moet komen. Verbeteringen in het proces, of knelpunten signaleren en deze oplossen.
Hij gaf overigens aan dat hij specifiek voor Lean gekozen had, niet voor Lean-Six Sigma of een andere methodiek. Dat was wel wat geruststellender, aangezien we nu eenmaal geen productie omgeving kennen.
We hebben hem ook meteen uitgenodigd voor de Open Space die we in februari gepland hebben over Sogeti en Agile. Na wat uitleg van Hans-Jurgen over het concept Open Space zegde hij toe te komen.
Vannacht heb ik maar meteen een mailtje gestuurd met de uitnodiging en een voorstel om Mary Poppendieck eens uit te nodigen.
Lean is iets wat ik me maar snel wat meer eigen ga maken, het lijkt me dat daar vragen over gaan komen.
Tuesday, January 12, 2010
Stakeholders
Gisteren had ik de cursus "Stakeholder Management".
Op zich vond ik het heel interessant, echter probeerde ik het ook in een Agile licht te plaatsen.
Communicatie en interactie tussen mensen is bij Agile bijzonder belangrijk, stakeholders hebben veel inbreng.
Echter deze cursus ging ook in op persoonlijkheden van mensen en relaties tussen mensen.
De cursusleider was iemand die een dagtaak kon hebben aan staholder management. Ik dacht meteen aan dagen op de golfbaan, een hele dag onderweg in een gebouw om mensen te spreken, of bellend door de gang.
Ik heb zelf eigenlijk nooit formeel mijn stakeholders bijgehouden. Kennis die ik opdeed van mensen ging bij mij eigenlijk vaak vanzelf en ik behandel iedereen zoveel mogelijk hetzelfde. Met aandacht en interesse.
Gelukkig kom je daar een heel eind mee, maar ik heb al wel gemerkt dat dit niet voor iedereen zo is.
Agile stakeholder management ligt wat mij betreft vaak in de beperkte omgeving die bijvoorbeeld Scrum beschrijft. Maar je moet natuurlijk wel verder kijken dan Pig en Chickens. Uiteindelijk zijn er massa's belangrijke stakeholders tussen de kippen die je eigenlijk moet masseren.
De cursus vertelde em ook over Ratten, en eigenlijk zijn dat altijd Kippen...
Ik weet in ieder geval wel dat een Agile implementatie succesvoller is in een organizatie met weinig ratten, uiteindelijk gaat Agile niet uit van dubbele agenda's van managers en directeuren.
Laten we dat maar overlaten aan meer traditionele methodieken...
Op zich vond ik het heel interessant, echter probeerde ik het ook in een Agile licht te plaatsen.
Communicatie en interactie tussen mensen is bij Agile bijzonder belangrijk, stakeholders hebben veel inbreng.
Echter deze cursus ging ook in op persoonlijkheden van mensen en relaties tussen mensen.
De cursusleider was iemand die een dagtaak kon hebben aan staholder management. Ik dacht meteen aan dagen op de golfbaan, een hele dag onderweg in een gebouw om mensen te spreken, of bellend door de gang.
Ik heb zelf eigenlijk nooit formeel mijn stakeholders bijgehouden. Kennis die ik opdeed van mensen ging bij mij eigenlijk vaak vanzelf en ik behandel iedereen zoveel mogelijk hetzelfde. Met aandacht en interesse.
Gelukkig kom je daar een heel eind mee, maar ik heb al wel gemerkt dat dit niet voor iedereen zo is.
Agile stakeholder management ligt wat mij betreft vaak in de beperkte omgeving die bijvoorbeeld Scrum beschrijft. Maar je moet natuurlijk wel verder kijken dan Pig en Chickens. Uiteindelijk zijn er massa's belangrijke stakeholders tussen de kippen die je eigenlijk moet masseren.
De cursus vertelde em ook over Ratten, en eigenlijk zijn dat altijd Kippen...
Ik weet in ieder geval wel dat een Agile implementatie succesvoller is in een organizatie met weinig ratten, uiteindelijk gaat Agile niet uit van dubbele agenda's van managers en directeuren.
Laten we dat maar overlaten aan meer traditionele methodieken...
Monday, January 4, 2010
Open Space
In februari wordt er bij mijn werkgever door ons (Agile Competence Network) een Open Space georganiseerd. Het gaat over Agile en Sogeti, of Sogeti en Agile...in ieder geval gaan we stilstaan bij deze combinatie.
Een Open Space is een heel productieve en creatieve manier om ideëen te verzamelen en te brainstormen over problemen en issues.
Voor mij was dit heel nieuw en ik ben dan ook heel benieuwd wat ons dit gaat opleveren.
Een Open Space is een heel productieve en creatieve manier om ideëen te verzamelen en te brainstormen over problemen en issues.
Voor mij was dit heel nieuw en ik ben dan ook heel benieuwd wat ons dit gaat opleveren.
Friday, December 25, 2009
Een nieuw jaar met nieuwe uitdagingen
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?
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 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.
Subscribe to:
Posts (Atom)
