SCRUM @ AFC Ajax?

Hoe meer gedoe de laatste tijd bij Ajax (de voetbalclub), hoe meer interesse ik heb gekregen. Het leek wel alsof ik vanuit verschillende invalshoeken, uit mijn passie voor voetbal, mijn kennis als bedrijfskundige, mijn ervaringen als ICT’er en consument van sappig nieuws door de voetbalvereniging heen werd gesmeten.

Wim Jonk, Dennis Bergkamp, Bryan Roy, Ronald de Boer, John Bosman, Jaap Stam, Marc Overmars, Michel Kreek, Orlando Trustfull en Dean Gorré zijn niet alleen trainers bij AFC Ajax slechts fanatieke aanhangers van het Cruijff-isme. Ze zijn de eersten die SCRUM toepassen in het betaalde voetbal. Ga er maar eens aan staan, elk van hen heeft niet alleen een succesvolle carriere gehad maar ze bezitten ook elk specifieke kwaliteiten. Volgens Cruijff leer je voetbal door voetbal. Door deze voormalige spelers als trainers, coaches en begeleiders aan te stellen waarbij Jonk, Bergkamp en de Boer het technische hart vormen elimineer je de noodzaak van bureaucratische besluitvorming. Hoe meer nieuws hierover naar buiten kwam en hoe meer gedoe, hoe meer ik de gedachte gang van Cruijff ben gaan begrijpen. Ik denk dat ze zelfs aan SCRUM zouden kunnen doen. Daarom heb ik besloten om een fictief interview met Johan Cruijff te houden om te laten zien hoe dit er uit zou kunnen gaan zien, en dat het kan werken.

“Dag Johan.”

“Goedemorgen.”

“Wat is je doel eigenlijk?”

“Ajax op Europees top niveau krijgen.”

“Wat bedoel je precies?”

“Dat is logisch, elk jaar deelname aan de Champions League, dat is toch wel het hoogste niveau waar het beste voetbal wordt gespeeld.”

“Huh, alleen meedoen?”

“Nee, nee, regelmatig overwinteren, eens per twee jaar minimaal hoort daar bij. En wie weet stoot je dan eens een keer door.”

“En het gaat alleen over voetbal?”

“Voetbal is het hart van de club, de motor en de ziel. Maar we moeten wel financieel gezond blijven en de bedrijfsvoering moet optimaal zijn.”

“Ok, we hebben dus wat randvoorwaarden. Hoe gaat Ajax dit doen denk je?”

“We moeten investeren in de jeugd en de jeugdopleiding zo effectief als mogelijk is laten functioneren.”

“Hoe?”

“Nou, door oud voetballers als trainers, coaches en begeleiders aan te stellen.”

“Ah, dus Appie uit het derde van VV de Polderjongens gaat de B1 trainen?”

“Nee, zeker niet. We zoeken mensen met een Ajax hart en een Ajax verleden. En zelfs dat is niet genoeg, het moeten jongens zijn die zelf als voetballer op het allerhoogste niveau hebben meegedraaid en over specifieke kwaliteiten beschikken. Daar kan de jeugd ontzettend van leren.”

“Over wie heb je het?”

“Wim Jonk, Dennis Bergkamp, Bryan Roy, Ronald de Boer, John Bosman, Jaap Stam, Marc Overmars, Michel Kreek, Orlando Trustfull en Dean Gorré. En natuurlijk Frank niet vergeten als trainer van het eerste.”

“Zo, dus een heel elftal, met die namen zou je de Champions League nu ook kunnen winnen.

“Haha, dat is waar, alleen we missen een keeper.”

“Dus je mist toch nog een specifieke kwaliteit in je organisatie.”

“Ja dat klopt, maar we hebben wel goede keepertrainers hoor. En het is geen schande om af en toe iemand van buiten te halen. Cillissen is daar een mooi voorbeeld van. Echt een jongen voor de toekomst.”

“Ok, ok, maar nu even terug. We moeten een SCRUM team samen stellen en SCRUM schrijft een teamomvang van maximaal 9 personen voor. Als je er namelijk een tiende bij zet dan krijg je er weer 9 communicatie lijnen bij. Een elfde en het zijn er nog eens 10 extra.”

“Hmm, daar zit wel wat in. Communicatie is heel belangrijk en we willen de mannen zoveel mogelijk op het veld bij de jongens hebben. Het is niet de bedoeling dat ze eindeloos aan het vergaderen zijn.”

“Nee Johan, dat klopt. Hoogstens elke dag een kwartiertje om de belangrijkste punten te bespreken, wat is gisteren bereikt, wat wordt vandaag gedaan en is er iets dat me in de weg staat, de Daily SCRUM noemen we dat. Verder hebben we alleen een planning, oplever en een terugblik sessie die altijd plaats moeten vinden.”

“Potverdrie, een kwartiertje lullen en de rest van de dag met voetbal bezig zijn, heerlijk.”

“Ze moeten wel elke 4 weken een keer bij elkaar komen voor een bespreking van de Sprint planning.”

“Sprint?”

“In een sprint spreek je af wat de belangrijkste zaken zijn waar je de komende 2, 3 of 4 weken aan gaat werken. Je moet wel even afspreken dat je altijd een vast aantal weken voor je sprint hanteert. Het voordeel is dat iedereen weet wat er gebeuren moet, jullie als bestuur en commissarissen stellen op hoofdlijnen vast wat het belangrijkste is en hangen daar een budget aan, maar de mannen op de vloer, euh, veld bepalen vervolgens hoe dat gaat gebeuren. Zij stemmen dit af met de Product Owner, de eigenaar als het ware van het eindproduct. Dat kan jij als commissaris zijn maar misschien is het zelfs veel beter om dit aan Frank over te laten, hij zal uiteindelijk over de beste spelers moeten beschikken voor het eerste en jij kan veel meer op de achtergrond met adviseren en lange termijn bezig gaan. Een training van een dag en hij beschikt over alle noodzakelijk kennis.”

“Pff, dat lijk me wel wat, dat bureau en de vergaderkamer zijn niks voor mij en ik hoef ook eigenlijk niet veel in Amsterdam te zijn.”

“Precies, maar we dwalen weer af, je team is eigenlijk iets te groot.”

“Ik wil er geen een kwijt hoor.”

“Dat hoeft ook niet, we kunnen ze ook in tweeën splitsen. Misschien een groepje speciaal voor de jeugd en een ander wat dichter op het eerste. Wim en Dennis zitten toch ook in het technische hart. Je zou die twee als SCRUM Master in kunnen zetten. Dan is het lijntje met Frank gelijk heel kort.”

“Goeiedag, dat ziet er al aardig uit, kunnen we dan ook niet een scout aan de teams toevoegen? Het zint me niks dat die vanachter een bureau aangestuurd worden.”

“Dat is inderdaad niet gek, ze weten dan ook waar het aan kwaliteit ontbreekt en wat je allemaal in huis hebt. Ze kunnen dan veel specifieker selecteren. En niet door allerlei rapporten maar doordat ze de eigen spelers kennen en weten wat ze kunnen.”

“Het SCRUM team stuurt dus zijn eigen scouts aan. Maar hoe zit het dan met rapporteren, uiteindelijk moeten we wel verantwoording afleggen. Ik heb er eigenlijk een broertje dood aan maar we zijn een beursgenoteerd bedrijf en we hebben de Ledenraad, en je moet ze wel iets van beleid en zo laten zien.”

“Als de scouts weten wat de budgetten zijn dan kennen ze denk ik alle voorwaarden die nodig zijn om hun werk te doen, daar is toch wel informatie over?”

“Ha, aan financiele informatie is er geen gebrek en de voetbal academies in het buitenland gebruiken ze al als uitvalsbases.”

“Mooi, aan het einde van een Sprint komen de teams, dus inclusief scouts, bij elkaar en laten aan de Product Owner zien wat ze bereikt hebben op basis van wat aan het begin is afgesproken. Als de Product Owner merkt dat er te weinig gebeurd is kan hij voor een volgende sprint bijsturen, eigenlijk bieden de dagelijks SCRUMs daar ook al gelegenheid voor. Maar tijdens de oplevering bespreek je dus als het ware wat er gebeurd is en wat voor een volgende sprint afgesproken wordt. Vervolgens houd je ook een Retrospective, je blikt dan met z’n allen terug en kijkt wat er goed ging, want dat wil je blijven doen, en wat er fout ging, dat wil je verbeteren. Daarover kan de Product Owner elke vier weken richting welke betrokkene dan ook rapporteren. Als de Raad van Bestuur of de Raad van Commissarissen iets niet zint, dan kunnen ze dit via de Product Owner weer terug laten komen op de organisatie.”

“Ik wist het wel, we hebben geen aparte Technische Directeur nodig, en al helemaal niet een die zelf een nadrukkelijk profiel heeft.”

“Dat klopt Johan, je bestuur en commissarissen gaan alleen over de hoofdlijnen en zijn facilliterend en dienend aan je proces en product. Ze moeten optimale randvoorwaarden scheppen en je mensen op de vloer, euh veld, niet in de weg gaan zitten.”

“SCRUM bevalt me wel denk ik.”

“Als je het eenmaal doet, dan wil je niet meer terug Johan.”

“Hoe kom je er eigenlijk aan.”

“We gebruiken het bij Luminis om technisch hoogwaardige ICT oplossingen tot stand te brengen, het komt dus uit de ICT maar je ziet dat je het ook binnen je betaald voetbal organisatie kunt gebruiken.”

“Dank je wel”

“Jij ook bedankt Johan, en veel succes.”

Share and Enjoy:
  • Digg
  • del.icio.us
  • Google Bookmarks
  • RSS
  • Twitter

, , ,

No Comments

Staying lean!

A while ago I posted here about the role of the architect when building lean software. Inspired by posts by Kirk, Hal and Joel, I’d like to build a case for selecting the right tools and frameworks in order to be able to sustain your agility in the long run.

Starting with the opening argument that Hal makes, we’ve all been in projects for long amounts of time, where at one point you start wondering what became of that once beautiful and comprehensible design, or those fast build and test cycles you started out with. As products evolve over time, they all seem to loose a lot of their initial “elegance” up to the point where people seriously start considering starting from scratch “because it’s easier than bolting on new features to the existing product”. Apart from the fact that that is very counter-productive from the point of view of the customer, you’re also throwing away a lot of experience, especially if the original authors of that code are no longer around (which sometimes is stated as a reason to start over). Joel made a case for not starting from scratch and raises some very valid points there.

So, if it’s not smart to start from scratch, and you really want to sustain that agility, how are you going to make that happen? There, going back to one of the points that Kirk makes, a lot depends on your architecture, especially if you look at it from his point of view:

The goal of architecture is to minimize the impact and cost of change. To do this requires we create flexible systems with the ability to adapt and evolve. But with flexibility comes complexity, presenting architects with a paradox. As we design more adaptable systems, the additional complexity reduces their ability to survive. Eventually, the software rots, the architecture crumbles, and the system fails. Therefore, we must find a way to increase adaptability without decreasing survivability.

Combining observations here it becomes increasingly important to stay modular and to really try hard to loosely couple your components because that has tremendous benefits in the long run. Doing that is not easy though, as it requires a lot of thought, and you might need to make some other trade-offs in favor of modularity and loose coupling. However, it is one of the few ways that allow you to make decisions that are always reversible, as ripping out a single component in an environment where there are as little dependencies as possible and where each of these dependencies have small and substitutable interfaces remains as easy as it was when you started the project. In practice it also means that it is worthwhile ensuring that these qualities in the overall architecture do not deteriorate and that you spend enough time making sure they don’t by refactoring and reviewing code as part of the normal development cycle.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Google Bookmarks
  • RSS
  • Twitter

, , ,

1 Comment

Scrum at University

A lot of companies are currently developing software in an agile way. Quite often universities stay behind in technologies and methodologies that are taught with respect to what’s hot in the working field. Luckily quite some universities do try to keep up with the ‘real world’, and try to deliver graduates with up-to-date knowledge that fits the needs of companies.

At Avans University of Applied Sciences in ’s Hertogenbosch, the project ‘Game Design’ was started, and the idea was to apply an agile development process to introduce this to the students as well. This project had a duration of about 14 weeks, fixed six-person teams, and quite some availability of all team members each week. Besides that, the lecturers were willing to play the role of Product Owner, preventing the students from creating whatever they liked. Good starting point of a project to apply Scrum to.

And as luminis has quite some experience in applying Scrum at various client projects, I was asked to give a lecture on the Scrum basics, and share some of our experiences.

Just before the summer holiday the project was finished, and the following experiences were the result:

  • Applying Scrum was quite hard in the beginning. They didn’t meet every day, and especially in the beginning they were working on large tasks like the design document and getting familar with technologies. It was difficult to split that up into smaller pieces.
  • In the second part of the project (more focused on implementation), the students were able to apply Scrum in a better way. Even though they didn’t meet at a daily basis, they were able to make well estimated tasks, and execute these in a one-week sprint. This provided a clear overview of the project and the progress. And the detailed planning worked out great.

Concluding: as an introduction to Scrum, it wasn’t a real success applying it in the first phase of the project (sprint 0 type of work). For the students it felt quite artificial, and they did not experience any benefits. On the other hand, looking at the second phase (implementation) of the project it was a success as they really experienced the usefulness of practices like detailed planning and weekly deliveries.

Result; the invitation for next years ‘Games’ project already stands.

Share and Enjoy:
  • Digg
  • del.icio.us
  • Google Bookmarks
  • RSS
  • Twitter

, , ,

1 Comment