Who's waiting for this?
If it's not clear who is waiting for a certain piece of work:

• Who will pay for it?
• How do we know we are doing the right things?
• How do we know when we're ready?

We work on the most important things only. We don't allow ourselves to work on anything less important.
Because we don't have enough time to do all we could do, we better constrain ourselves to doing only the most important things

What can we do less, without doing too little?
Conventional project management tries to do as much as possible. In Evo, we try to do as little as possible, because:

• If it turns out that we did something wrong, we'll have wasted as little time as possible and have to redo as little as possible
• Doing as little as possible takes less time, so we have more time left for the next most important things

What we deliver simply works
"Does that mean without any defects?" asked the project manager and the architect.
"It simply works." "Did I speak in a foreign language?" should be the answer

Question: "When can I go for certification?"
Answer: You should start any external assessment only if you are self convinced that the quality is there. If you don't know that yet, it probably isn't, so why go for certification?

You cannot certify quality into your organisation. It should be there in the first place.

Deming

Teaching of beginners should be done by a master, not by a hack.

Debuggen is een vies woord dat je moet schrappen uit je woordenboek.
Ik wil dat woord niet meer horen en heb daar goede redenen voor.

Testen is constateren dat het werkt.
Het doel van testen is dus niet het vinden van fouten, maar het constateren van de afwezigheid ervan. Toch gevonden defecten dienen te worden geanalyseerd: Hoe voorkomen we het ontstaan van dit type defect voortaan en hoe heeft dit type defect ons inspectieproces weten te ontsnappen?

Elk defect gevonden bij het testen betekent een defect gevonden door de gebruiker.
Vind je dat acceptabel? Bron: Ontontkoombare statistiek.

Quality comes not from inspection, but from improvement of the production process.
Deming.

Zodra je softwareontwikkeling als een productieproces beschouwt, kun je gebruik maken van een schat aan kwaliteitsmethodieken die bij productie al reeds lang gemeengoed zijn.
Als je goed oplet, zul je zien dat slechts een klein deel (10%?) van het ontwikkelproces creatief werk is. De rest is afdraaien van activiteiten die bij elk project vergelijkbaar zijn. Dat is productie. Dat is procesmatig beheersbaar. Dan heb je meer tijd voor de creativiteit!

If you want more effective programmers, you will discover that they should not waste their time debugging - they should not introduce the bugs to start with.
E. Dijkstra, The Humble Programmer, 1972. Waarom hebben we na 30 jaar nog niets geleerd??

The competent programmer is fully aware of the limited size of his own skull.
E. Dijkstra, Programming Considered as a Human Activity, 1965. Software is zo complex dat ons arme hoofd het met geen mogelijkheid kan bevatten. We moeten dus alle middelen aangrijpen om de beheersbaarheid van deze complexiteit te vergroten.

When an automatic computer produces results, why do we trust them, if we do so.
What measures can we take to increase our confidence that the results produced are indeed the results intended?
E. Dijkstra, Programming Considered as a Human Activity, 1965.

Het is de taak van het management om de werkers de processen te geven waardoor zij optimaal kunnen presteren.
Manager, wat doe je daaraan? Wij helpen graag als mentor en coach.

Philip Crosby zegt hierover (ref. Q6, pag 59):
Management has three basic tasks to perform:

1. Establish the requirements that employees are to meet
2. Supply the wherewithal that the employees need in order to meet those requirements
3. Spend all its time encouraging and helping the employees to meet those requirements

The employees will take requirements as seriously as the management takes requirements seriously
Philip Crosby (ref. Q6, pag 59).
Een variatie hierop is:
Management krijgt de resultaten die ze verdient

De gangbare wijze van softwareontwikkeling is ontoereikend om Kwaliteit op Tijd te leveren.
De methoden om Kwaliteit op Tijd te realiseren zijn bekend, bewezen en beschikbaar.
Indien je dit weet en vervolgens deze methoden niet toepast schiet je als management tekort.

Wanneer ze zeggen dat ze "nu geen tijd hebben" door de drukte, is het juist tijd om er iets aan te doen.
Door de manier van werken aan te pakken krijgen ze al gauw "lucht" en begint een betere beheersing van de inzet. Als ze het niet meteen doen, dan blijven ze uitstellen en komt het er dus nooit van. Dan doen ze hun organisatie tekort: de organisatie blijft betalen voor langer ontwikkelen en later met resultaten komen, om nog niet te spreken over de kosten van onvolkomenheden en defecten die ná de ontwikkelfase aan het licht komen.

Het tekort aan ITers is op te heffen door ze Kwaliteit op Tijd principes aan te leren.
Kwaliteit op Tijd werkmethoden zijn het effectiefst om de productiviteit (overigens niet ten koste van plezier in het werk, integendeel!) met stappen te verhogen. Pas veel later komen tools.

Just In Time Training is een goede implementatietechniek.
Veel beter dan af en toe een workshop, is het aan het begin van een project identificeren in welke methoden en technieken getraind moet worden om het project zo efficient mogelijk te kunnen doen verlopen. Door het geleerde meteen toe te passen leert men (mits goed begeleid!) het best. Vind het wiel niet nog eens uit.

Wanneer het ontwikkelbudget is opgebruikt, wordt het paniekbudget opengetrokken.
Het paniekbudget is meestal onbeperkt. Het is de kunst om het paniekbudget niet te hoeven aanspreken. Dit heeft een significante impact op de winst.

In stead of reacting to the chaos of change we could respond to the rhythm of change.
Kim Caputo in CMM Implementation Guide (ref. SP16) commenting about the idea that people would naturally resist change.
If software people resist change, don't blame them: you failed in explaining why and how the change is desirable for them.

Bij Projectleiding onderscheiden we vier categorieën:
Om over projectleiding problemen te kunnen praten is het handzaam om typische projectleidercategorieën te onderscheiden. De meeste projectleiders plaatsen zichzelf in categorie 2 of 3. Ze weten het wel, maar juist als je je in deze categorieën bevindt, neem je geen actie om er iets aan te doen!

1. Er is geen projectleider.
   Dit zijn de meeste projecten: ze dobberen stuurloos rond. Denk aan die kapotte deurkruk in je huis: zonder projectleiding is hij volgend jaar nog niet gerepareerd.
2. Er is een projectleider aangewezen, maar hij weet het niet, men weet het niet, idereen wijst naar elkaar: niemand weet goed wat het betekent en wat er moet gebeuren.
3. De projectvolger.
   Volgt het project, ziet hoe het steeds verder uitloopt en hoop dat het vanzelf weer goed komt.
4. De echte projectleider.
   Visie, strategie, scenario's, projectdiscipline, direct goed, zero defects, time to market. Kortom: zorgt dat het gebeurt.

Wanneer 90% gereed is, begint men aan de volgende 90%.
Veel ontwikkelingen zijn "gepland" op basis van "als alles direct goed gaat". Zolang de methoden om dit ook werkelijk te bereiken niet worden beheerst, gaat niet alles goed en dat merkt men dan pas "op het eind".

10% van de ontwikkeltijd is nodig om te zorgen dat het computersysteem doet wat het moet doen en 90% om te zorgen dat het niet doet wat het niet moet doen.
Daarom duurt softwareontwikkeling een stuk langer dan leken, hobbyisten en onverbeterlijke optimisten denken.

Als je denkt dat je met regelmatig overwerk meer presteert, houd je jezelf (en je organisatie) voor de gek.
Regelmatig overwerk heeft een zichzelf versterkend effect. Het leidt tot vermoeidheid, dus meer fouten, dus meer defecten, dus meer werk. En dus een mindere kwaliteit in een langere tijd. Het tegendeel van Kwaliteit op Tijd.

Wat de klant wil kan hij zich niet veroorloven.

Wat je opschrijft kun je wijzigen. Wat je niet opschrijft verdampt waar je bij staat.
Wat je niet opschrijft geldt dus ook niet.

Gegevens mogen maar op één plaats staan.
Wanneer dezelfde gegevens op méér dan één plaats staan, gaan ze divergeren (ze blijven niet hetzelfde, als ze dat al waren). Bij wijzigen van gegevens die op meer dan één plaats staan weet je nooit of je alle voorkomende gevallen hebt gewijzigd. Er dient echter wel een methode (Document Control, Configuration Management) te zijn, die ervoor zorgt dat alle plaatsen waar de gewijzigde gegevens worden gebruikt op de hoogte worden gesteld van de wijziging. Relationele databases werken volgens dit principe. Bij software geldt hetzelfde: elke functie mag slechts éénmaal voorkomen (wat was het millenniumprobleem dan gemakkelijk op te lossen geweest!).

Marketing dient zorg te dragen voor een systeem van doorlopende informatie over gebruikservaring van de afnemers.
ISO9004.

Service dient zorg te dragen voor een systeem van doorlopende informatie over problemen in het product.
Als Service al een registratiesysteem heeft, dan worden de formulieren altijd goed opgeborgen. Dat je daar veel van kan leren dringt niet tot ze door.

If you don’t know where you are going, any road will do. Chinees
If you don’t know where you are, a map won’t help. Humphrey
If the requirements are not clear (which normally is the case), any schedule will do. Malotaux, june 2006

Teigetje: “Knorretje, kom gauw mee!”
Knorretje: "Waar gaan we dan naar toe?"
Teigetje: "Dat weet ik niet, maar we nemen de kortste weg!"
gehoord bij Winnie de Pooh

Absolutes of Quality (1970)

1. Quality is conformance to requirements
2. Obtained through prevention
3. The performance standard is zero defects
4. The measure is the price of nonconformance

Recently added by PCA (Philips Crosby Associates) (2004)

5. The purpose is to to ensure customer success