Nietzsche contra Nietzsche

In 1869, nauwelijks 24 jaar oud en nog zonder doctoraat, wordt Friedrich Nietzsche (geboren te Röcken nabij Leipzig in Duitsland) na zijn studies in Bonn en Leipzig benoemd tot hoogleraar Klassieke Filologie aan de universiteit van Bazel in Zwitserland. Nietzsche was van opleiding namelijk classicus. Dit domein werd alsnog zijn ingangspoort tot de filosofie, zijn latere en finale bestemming.

Nauwelijks een jaar eerder, in 1868, had Nietzsche in Leipzig de componist Richard Wagner ontmoet.

Friedrich Nietzsche -  De Geboorte van de TragedieIn 1872 verschijnt het eerste boek van Nietzsche, “De Geboorte van de Tragedie“. Het is een onderzoek naar de bronnen, het ontstaan en de evolutie van de aard en de verschijning van de zogenaamde ‘klassieke tragedie’ in het oude Griekenland. Alhoewel geschreven vanuit zijn vakgebied bevat het boek heel duidelijk al de krijtlijnen van de latere filosofische wegen van Nietzsche. Kenmerkend is ook al de uitgesproken hamerende stijl van zijn geschriften, het afwijzen van doorgedreven structuur en retoriek. Finaal slaat hij de wegen van de filosofie pas exclusief in vanaf zijn terugtreden uit zijn universiteitspositie, wegens gezondheidsproblemen, in 1879.

De eerste versie van het boek heeft nog als ondertitel “uit de geest van de muziek“. Het bevat ook een voorwoord aan Richard Wagner en ettelijke, behoorlijk naiëf ogende idolatrische verwijzingen naar hem. Echter, de echte kern en waarde van het boek is Nietzsche’s diepgravende en oorspronkelijke analyse van de klassieke tragedie. De figuur van Wagner is eerder de projectie, een spiegel van Nietzsche’s hoop op de wedergeboorte ervan. Nietzsche hoopt op de herwaardering van de dionysische driften in de muziek en het theater, zodat de balans kan hersteld worden tussen het instinctieve (een dierlijke, natuurlijke levenslust) en het naïeve (hoopvolle, dromerige romantiek). Nietzsche meent dat de tijd gekomen is om de decadente ontsporing naar louter verschijning, louter woordenspel, ongedaan te maken. De onderliggende idee is het herstel van het pessimisme als levenslustige motivatie, erkenning ervan als oerbeweging, een wezensaard en levensbron.

Het is erg opvallend hoe dit eerste werk van Nietzsche quasi alle thema’s reeds bevat die blijvend zullen terug komen in zijn latere werken, alhoewel een voor een met meer diepgang behandeld in die werken en niet meer zo sterk tegen deze culturele achtergrond.

In de jaren van omgang met Wagner volgend op hun initiële ontmoeting en gesprekken ontwaakt Nietzsche geleidelijk uit het droombeeld dat hij heeft/had van Wagner en bij de derde druk van “De Geboorte van de Tragedie” in 1886 wijzigt hij de ondertitel naar “of: de Griekse geest en pessimisme” (ps. naar mijn mening zou het beter zijn “of: de Griekse geest en het pessimisme”) en vervangt hij het voorwoord aan Wagner door een ‘proeve van zelfkritiek’. In de meest recente Nederlandse vertalingen, steeds uitgegeven bij de Arbeiderspers, werden gelukkig genoeg beide inleidingen opgenomen, met de historische duiding ervan in het nawoord van Hans Driessen, de vertaler.

In zijn laatste actieve levensjaar (1889), dat wil zeggen net voor hij in de 10-jarige lethargie verzeilt die tot aan zijn dood in 1900 duurt, schrijft Nietzsche 2 pamfletten die de figuur van Wagner als expliciet onderwerp hebben, “Het geval Wagner” en “Nietzsche contra Wagner”. Het tweede pamflet wordt door Nietzsche zelf, net voor de intrede van zijn lethargie, niet vrijgegeven voor publicatie. Enkele maanden later, nadat Nietzsche is ingestort, wordt het alsnog gepubliceerd.

Friedrich Nietzsche - Nietzsche contra WagnerIn het Nederlandse taalgebied zijn deze teksten onder 2 verschillende vormen gebundeld en gepubliceerd, telkens in dezelfde vertaling. In de reeks Privé-domein (#194) werden ze beide uitgebracht onder de titel “Nietzsche contra Wagner”, naar het tweede pamflet. In de Nietzsche-bibliotheek werden ze samen uitgebracht onder de titel “Het geval Wagner”, naar het eerste pamflet.

Het is bijzonder opvallend hoe beide pamfletten sterk aansluiten bij het ideeëngoed van Nietzsche dat reeds zijn eerste werk domineerde, “De Geboorte van de Tragedie”. Ze zijn in die zin zelfs erg rijk omdat erin ook zijn denken rond cultuur en kunstenaarschap wordt hernomen, in het licht van het Dionysische en het Apolinische, en de verwerping en vervanging ervan door het Socratische. Het is in die zin ‘rijk’ omdat het die culturele oorsprong actief herneemt en behandelt, en niet de toepassing ervan in het louter filosofische is.

Het tweede pamflet, “Nietzsche contra Wagner”, hoort m.i. tot het meest autobiografische en oprechte dat Nietzsche heeft neergeschreven. Het staat, in tegenstelling tot wat de titel doet vermoeden, grotendeels los van de figuur van Richard Wagner. Het is eerder een strijd van Nietzsche tegen zichzelf, tegen de neigingen die hij vanuit de figuur Wagner ook in zichzelf herkent, en actief bekampt en aanvult. Het eerste pamflet, “Het Geval Wagner”, is veel duidelijker een rechtstreekse afrekening met de figuur van Wagner, alhoewel het een mengeling van afkeer en bewondering bevat.

In de boekuitgave “Nietzsche contra Wagner” worden de pamfletten aangevuld met citaten uit de dagboeken van Cosima Wagner, echtgenote van. Deze citaten ontbreken jammerlijk in de latere heruitgave onder de titel Friedrich Nietzsche - Het Geval Wagner“Het Geval Wagner”. Jammerlijk aan het ontbreken van de dagboekcitaten is dat deze citaten indirect toch een goed beeld van de relaties van de Wagners met Nietzsche schetsen. Alleen al de frequentie van vermelding van Nietzsche door mevr. Wagner is een goede indicator; de frequentie is bijzonder hoog gedurende de eerste 2-3 jaren maar neemt sterk af in de loop van de erop volgende jaren. De inhoud en de intensiteit van haar notities versterken dit effect. De aanvankelijke extreme genegenheid, bewondering en positieve toon slaan geleidelijk om in ergernis, afkeer en ontzetting. In hoofde van Cosima lijkt er toch heel wat heimwee aanwezig te blijven, daar waar bij R. de ergernis overheerst. Allengs, Nietzsche lijkt ondanks zijn lijfelijke afwezigheid toch een regelmatig onderwerp te zijn ten huize Wagner, inclusief een verschijning in een nachtmerrie van Richard.

Een mindere kritiek is dat in de latere uitgave ook het namenregister niet meer wordt opgenomen.

Het kernprobleem dat Nietzsche vaststelt en uitvoerig met zijn furieuze mokerhamer naar taal brengt, is de hang van Wagner naar zuiver effect en impact, naar enkel romantiek en decadentie, zonder Dyonisch tegengewicht en fundering, met daarenboven, in zijn latere werk, ook nog een uitgesproken christelijk-moralistisch karakter. Einde van de (hoop op de) wedergeboorte van de tragedie. For the time being.

Scrum Is A Stance (too)

-An inquiry into the expression of behaviors through Scrum-

Scrum is not a cookbook ‘process’ with detailed and exhaustive prescriptions for every imaginable situation. Scrum is a framework of principles, roles and rules that thrive on the people doing Scrum. The true potential of Scrum lies in the discovery and emergence of practices, tools and techniques and in optimizing them for each organization’s specific context. Scrum is very much about behavior, much more than it is about process.

(from the preface of „Scrum – A Pocket Guide“, Gunther Verheyen, 2013)

It is worthwhile elaborating on the importance of people and behavior in Scrum. Because, indeed:

Scrum is very much about behavior, much more than it is about process.

Introduction: the simplicity of Scrum

Presumably there are many reasons why Scrum turned into the leading framework for Agile software development during the past decade. One of the reasons may be the simplicity of Scrum. Or, perhaps it is the opposite, the wide adoption of Scrum is more like a miracle given that same simplicity.

Yet, the simplicity of Scrum is ESSENTIAL. The simplicity of Scrum reminds us of the fact that the real complexity to be tackled in software development lies outside of the rules and roles of Scrum. The real complexity resides in the specific context within which Scrum is applied. In software development, ‘context’ starts and ends with people; what people do, don’t do, like, dislike, prefer, hate; how people jell, feel and behave. The rules and roles of Scrum help people tackle complexity. But no ‘process’ can replace or compensate the people aspect of software development.

The simplicity of Scrum creates openness. It is an open invitation for discovery and emergence. Yet, the simplicity of Scrum gives rise to many frowns, emotions, reactions, debates. It is experienced as enticing, provocative, offensive, powerful, inadequate, a mystery, impossible. Is the beauty of Scrum, expressed through this simplicity, therefore in the eye of the beholder only? Or is there more to Scrum than meets the eye?

In the end, more than the rules and roles of Scrum, people have the key to Scrum. Behavior is the key to unleashing the potential of Scrum. Scrum is a stance, too.

The eye of the beholder

The rules and roles of Scrum are described in the Scrum Guide. The Scrum Guide was created and is maintained by Jeff Sutherland and Ken Schwaber, co-creators of Scrum. It is the definite body of knowledge to Scrum.

The rules and roles included in the Scrum Guide can be applied and followed as described, with no further inquiry into the why of these rules and roles. They can be regarded as ‘to be followed’ instructions, merely because the Scrum Guide prescribes them.

Blindly following the described roles and rules is for many in the industry of software development at least a great start to transform to Scrum. It helps. People, teams and organizations start, learn, and improve in creating and delivering software iterative-incrementally, with small steps of validated learning. However, sticking to, not transcending, such blind view and usage of Scrum is likely to turn Scrum into no more than yet another IT delivery process. As such it still leaves many holes, gaps, disconnects and waste. The rules and roles of Scrum, as described in the Scrum Guide, in themselves might not be enough to grasp the depth of Scrum and reap the full benefits of employing Scrum. The simplicity of Scrum may be somewhat deceptive.

It helps to dig deeper by:

  1. Reflecting on the definition of Scrum included in that same Scrum Guide document,
    “A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
    In the Scrum Guide this definition precedes the description of the rules and roles. This definition shows how Scrum is intended, i.e. an aid for the people employing Scrum, a way for people to structure and organize their own work. It sheds a different light on the subsequent roles and rules of the Scrum Guide. Yet, both are in the same document. Ultimately, the roles and rules described in the Scrum Guide can only be fully understood from the definition of Scrum and the clear intent expressed in that definition.
  2. Reading the description of the roles and rules again, e.g. some time after having started with Scrum. It often leads to the discovery that the Scrum Guide describes behavior more than it has technical prescriptions. A typical focus of many processes is on ceremonial technicalities like meetings, deliverables, timings, phases; i.e. on what is expected from people. Scrum is a framework that gives people the room to organize their own work, yet provides boundaries as every healthy ecosystem needs.
  3. Stepping back to a perspective that goes beyond the Scrum Guide document, the perspective offered in the Manifesto for Agile Software Development. The rules and roles described in the Scrum Guide, the behavior described, don’t just stand on their own. They are grounded in the values and principles expressed in the Agile Manifesto. Ultimately, the Scrum framework can only be fully comprehended when seen as an expression of these values and principles. Ultimately, the rules and roles of Scrum, the behavior described in the Scrum Guide, can only be fully understood in combination with the fundamental views expressed in the Agile Manifesto.

The intent and definition of Scrum, matched against the agile values and principles should ground and then drive the behavior expressed through Scrum.

The Stance of Scrum

Scrum has many facets. Scrum is a framework, not a methodology. The framework of Scrum is not just a set of technical prescriptions, but a recipe to deal with complex challenges. The rules and roles of Scrum support and complement, not replace, the intelligence and creativity of people. The framework of Scrum is an implementation of the values and principles of the Agile Manifesto. Scrum implements empiricism in software development.

The framework of Scrum thrives on implied principles, thinking and… behavior, on people taking a stance to product development through Scrum, a Scrum stance.

The definition of Scrum shows the way to the core of the stance typical to Scrum. If Scrum is an operating system for the values and principles expressed in the Agile Manifesto, the definition from the Scrum Guide shows the way to the kernel of the operating system.

The kernel is expressed as:

PEOPLE EMPLOY EMPIRICISM TO OPTIMIZE THE VALUE OF THEIR WORK.

Where:

  • People are respected for their intelligence, creativity and ability to organize their own work, to self-organize. People collaborate, thereby adhering to the values and principles of the Agile Manifesto and embodying the Scrum values of respect, focus, courage, openness, and commitment.
  • Empiricism serves to deal with the complexity typical to software development. In empiricism only reality and past results are accepted as certain. At a regular cadence outcomes and behaviors are transparently inspected for new and changed insights against set goals. These insights are used to adapt to observed reality.
  • The value of outcomes, work delivered to an ecosystem of creators, stakeholders and consumers, is constantly evaluated, optimized and maximized as a shared goal. Value comes in different shapes and appearances; satisfaction, money, improvement, credibility, risk. Optimizing value is very different from adhering to traditional development drivers like budget, tasks, scope, time, schedule.

In the end, Scrum has many appearances. In the end, Scrum -like all things agile- starts and ends with people. Scrum is a stance, too.

The Scrum Stance

A Software Development Profession

Creative, artful thinking and craftsmanship are ESSENTIAL QUALITIES for any software developer. But shouldn’t software development be about more than an act of art, a craft in best case? Isn’t there a need to add professionalism to it? Shouldn’t software development be a profession?

It is tempting to believe that software development already is a profession. After all, many people are employed in developing software, making a living out of creating and sustaining the working code of software products and services, as a team or as individuals. Many more are employed in and make a living out of all the side-activities in the wider software development industry; like funding, exploiting, selling, promoting software products and services. This however is not sufficient to state that software development already is a profession.

Some take their dreams for real and call software development a profession. For others it is more a matter of pride, status or ego to say they are part of a profession, instead of an artisan discipline. That still is not enough to state that software development already is a profession.

A profession has regulations, codes, expectations and rules, all building upon a recognized body of knowledge. A profession sets explicit expectations on ethics, conduct and behavior to be demonstrated by any member of the profession. Official exams are in place for members to demonstrate a level of required skills and knowledge before receiving an attestation, and the permission to bear an official title that is protected and reserved. A healthy profession’s regulations and standards have a purpose, a purpose that goes beyond self-serving the profession and the profession’s institute. All regulations and standards should serve to assure the best possible execution of work in order to protect the people and organizations taking part in or being subject to the profession’s activities and its outcomes, and the decisions taken as part of it.

It is difficult to predict if and when software development might transform into a profession. It seems unlikely in a short term. There is the gigantic amount of software development work, there are the endless variations of what might be considered ‚software development,’ the absence of a widely accepted definition and understanding of ‚software development,‘ disagreement over the work activities that should or should not be part of the profession.

Reasonable doubts may be expressed on whether being a profession will augment the quality of service, avoid charlatanism, etc.

Furthermore a variety of people and instances may have personal, political, career, financial or other interests in software development, possibly even outside of the activity itself. Such people and instances might see regulation as a threat to their interests. Or might see it just as a limitation to their artistic freedom. Not to speak of the difficulty in growing a body, ethics, assessments, instructional guidelines and a code of conduct that would be widely accepted within the industry.

Where there are many elements that probably impede software development from growing into a regulated profession, there are also very valid reasons why software development would be better off if it transformed into a profession.

Not the least reason is the overwhelming and crucial presence of software in society and our daily lives. Software has become increasingly vital to society. A major shift is happening. Software products and software services are at the front and at the back of many public, industrial and consumer services and facilities. Software no longer is a ‚nice to have,’ for amusement purposes only. Software is at the heart of the economy. Software is core to many, often even critical, services in the private and in the public domain; financial services, taxes, energy, retail, health care, education, defense, telecommunication, transport, the automotive industry, just to name a few. Numerous organizations thrive on software. Even when they are not software companies, their services largely depend on software.

The omnipresence of software leads to a huge demand for talented and skilled software development people. The demand for professionalism that goes beyond talent and skills is less acknowledged but equally important in the light of the crucial functions of software in society. It would be comforting to know that the level of professionalism shown in the industry grew at the same rate as the growth of presence and criticality of software products and services itself, although even a higher rate is required.

Software development deserves professionalism in doing and in managing it. Such professionalism would benefit much from being structured in a profession.

This post is one of the inquiries I have planned into the values of professionalism in software development and the potential of the scrum framework to induce the formation of a software development profession. A matter of incremental writing. I hope you enjoy it, and the future follow-ups and iterations.

Scrum – A Pocket Guide (3rd impression)

Gunther Verheyen, Scrum - A Pocket Guide (A Smart Travel Companion)Early 2013 I wrote the book “Scrum – A Pocket Guide“.

It was published in November 2013 by Van Haren Publishing. The pocket format used by my publisher coincides with the sub-title of the book “A Smart Travel Companion” and my views of Scrum as a journey, not a destination. Scrum is a journey toward increased agility, and my book is designed as a small guide that any traveler can easily take along.

Here’s what some of my best friends in the world of Scrum said about “Scrum – A Pocket Guide”:

Best description of Scrum currently available.

says Ken Schwaber, Scrum co-creator.

The book on Scrum I wished I had written.

says David Starr, also known as ‘Elegant Coder‘.

My publisher now informs me that the third impression is about to be produced (June 2014). It is still the first edition as the content is stable. The second impression dates from February 2014. I am humbled by this success and grateful for the appreciation.

If you have read the book, leave a review at Amazon UK, Amazon.com, GoodReads or one of the other shops where the book can be found. It provides me and potential readers with very valuable feedback.

Although Van Haren Publishing has its head quarters in the Netherlands, they have a great global distribution network. Here are some sources where “Scrum – A Pocket Guide (A Smart Travel Companion)” is available from, in varying formats:

And find many more search results at Google (24900 results), Bing (1110 results), Yahoo (1140 results).

Scrum Day Europe 2014

As from 2011 there has been a genuine boom of Scrum in the Netherlands. And it is still going on. A virus improving the lives of many people in the fascinating world of software development. I have worked with several Dutch organizations, of which ING is probably one of the biggest, one that I documented by the end of 2012.

In March 2012 Ken Schwaber, Scrum co-creator and my working partner at Scrum.org, asked whether I saw room for a Scrum event in the Netherlands. Yes, and we named it “Scrum Day Europe”. We set it up with 3 co-organizing companies around the ideas of “Software in 30 Days”. The goal was not to make it just another average agile event, so we went for a smaller event, with a clear management focus and much room for interaction. It turned out a great success, so a 2013 edition was organized with some small, incremental changes. Ken and I opened the 2013 edition with a keynote on the Agility Path framework for Enterprise Scrum that we were working on.

ScrumDay4Pros-logo_whiteThis year, 2014, will see the 3rd edition of the Scrum Day Europe event. The event is now part of Scrum.org’s prestigious Scrum Day for Professionals series. We have limited the co-organizing companies to our Scrum.org partner-in-principle Prowareness and have complemented that with a more substantial involvement of the communities. Because, in the end, Scrum.org’s role is to serve, help and facilitate the many Scrum practitioners out there, and this event is a great way to connect people and ideas.

The theme of 2014 will be “Evidence-Based Management”, on which I recently published a whitepaper called “Empirical Management Explored: Evidence-Based Management for Software Organizations“.  Ken and I will have the pleasure of opening the event again.

I look forward to meeting with great fellow Scrum travelers at the event, hoping YOU will be one of them. Have a look at the program and the speakers. Get your ticket via the Scrum Day Europe website, or directly at Scrum.org.

Scrum Day Europe 2014

Find all information on Evidence-Based Management at ebmgt.org.

Product Ownership in Scrum

A vast majority of software development work concerns new product development. Every software product is essentially unique. We create previously non-existing products, suites, integrations and product extensions. We never create the same product twice. We expand existing products into the new product area. Competition, market expectations and technologies move so fast that acquired concepts, practices and approaches are outdated by the time they become well adopted, forcing us de facto into new product development anyhow.

Software development, as new product development through and in complex conditions, requires a startup mindset, no matter the size or age of the product or the master company. The Product Owner, as promoted in the Scrum framework, becomes an Agile Product Manager, the product’s president, its mini-CEO, an entrepreneur. The rise in complexity and uncertainty renders big plans into meaningless waste. The Product Owner drives iterative development from an exploratory attitude, aiming at incremental progress through continuing discovery and validated learning.

Every Sprint has a Sprint Goal as next horizon to work against. The Sprint Goal describes a (business) challenge, from an assumption of (market) value for the (Increment of) product. The outcome of a Sprint provides an important learning option. But the learning is only meaningful when it can be assessed against the product’s external impact and adoption; in affirming or negating the assumption of value underlying the Sprint Goal. The goal of the learning is to find out whether an opportunity is real, whether there is an audience willing to use the product, whether the audience appreciates the delivered functions.

In the absence of a release, value remains an obscure assumption. It is a major unknown and a risk for further investments. The unknown remains unresolved, and the risk is out of control, until the product is brought to market; be it a contained market segment, be it a limited or the full user base. With every Sprint without an actual release, the risk increases exponentially that the Product Owner runs out of tune with the evolving market and is wasting money, time and creativity. Increments of product, seemingly incomplete but offering minimal usable feature sets, provide the foundation for validated learning. Users need it to provide the Product Owner with feedback on the actual value of the performed work, the base to decide on the best future direction of the product. No document, design, paper document or simulation provides the same, high level of validation. Without that ultimate validation no informed decision over strategies or tactics can be taken, not in the least the decision whether to continue on the chosen path or to change direction.

Learning requires not only goals and feedback loops, but also measurements and data to support the validation process. Evidence of value is needed to confirm or contradict the assumptions. Evidence-Based Management can guide the entrepreneur and the stakeholders in their investment decisions.

Scrum can be at the heart of such entrepreneurship. Scrum frames the creativity of people to better deal with complexity and uncertainty. The empirical foundation of Scrum is a structured way to steer experimentation and discovery through frequent validation. In a situation where uncertainty is too big to plan, it is a way to make real progress; progress that is founded in reality, not in plannified imagination.

Seeing the Product Owner in Scrum merely as a requirements engineer, a requirements provider or someone to prioritize a preset Product Backlog is unlikely to help organizations capitalize on the entrepreneurial potential of Scrum. Seeing Scrum as a goal in itself results in gazing at internal performance, volume (of features, of hours, of points) and productivity (velocity or derivatives). Scrum is designed as a mean, a mean to maximize the value of software; value to the market and value to the organization and its people. Scrum is designed to make progress, grow and prosper trough validated, incremental learning. The Product Owner, the owner of the product, takes up the essential role of entrepreneur.

In today’s complex and unpredictable world, Scrum can be the engine of innovation and exploration. It is a choice though. It is your call on how you want to use Scrum.

Thursday April 17

April 17 2014 was a Thursday. It brought back memories of another April 17 that was also a Thursday, i.e. in 1986.

The day was starting like every normal school day of a 16 year old high school student. I was riding to school by bike, a distance of about 12.5 mi, together with a couple of friends that joined me underway. However, that specific April 17 turned out a bit different. Me and my friends wanted to cross a certain road, as we always did, not to far after the road takes a turn. As I started crossing the road however a car came through the turn, which caused me to freeze. The car crashed full into me. My head smashed against the windshield and I got dragged along for over 18 yards hanging by my shoulder on the outside mirror, until the car came to a standstill.

Above all, it must have been terrible for my friends, seeing this happen right in front of them. I can only copy what I was told afterwards, as I have no memories of the event. I don’t even remember getting up in the morning, although I do remember the evening before. My brain only re-started generating memories 2 weeks later.

An ambulance takes me to a local hospital, where I am immediately transferred to a more specialized hospital with special transport. When my parents arrive, it is made clear that there is not much hope. I am in intensive care attached to lots of equipment, tubes and wires. I have no idea of what is going on as I am in a coma because of the pressure my skull has caused on my brains when hitting the windshield.

24 Hours later, Friday morning. Just before the surgeons want to relieve the pressure in my head by drilling my skull, I open my eyes shortly. The drilling is cancelled. 2 Weeks in coma follow, and in total 6 weeks in hospital. My collar-bone is broken, but that is nothing compared to the fact that my left leg has a dual, open fracture. A metal plate is attached to my bone to keep it together.

School is over. The advantage is that I can completely enjoy the soccer World Championship of 1986 in Mexico (night games included), where the Belgian national team performed so well. The problem is however that I am not entitled to pass on to the next grade. Up to today I am grateful that my teachers accomplished with the ministry of education that they were allowed to take that decision. As from September I went back to school. By bike. To the next grade. Walking was no problem, but running was impossible until the metal plate was removed from my leg one year later.

Some will probably state that this day, April 17 1986, and my bike accident, marks the start of my insanity. I officially deny. I was already pretty crazy before my accident. I am born an anarchist. More than 28 years after the accident I am more than ever convinced of this. I did have much luck, as it seems that chances to survive undamaged were non-existent.