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, while delivering more?
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

Every day we know a problem earlier, we have a day more to do something about it

Failure is not an option

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

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.

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

Who is the main customer of Testing ?
Development

Bug and Debug are dirty words. They should be deleted from our dictionary
If you don't know why or how, we can talk about it

Testing is to confirm the proper functioning of a workproduct
The goal of testing should never be fault finding. It should be finding the absence of faults. Any defects still found should be analysed: How can we avoid the occurrence of this type of defect in the future, and how could this type of defect have slipped through our inspection process?

Statistically, the customer will find as many defects as you found in the test.
How many defects would you like the customer to find? Source: Inevitable statistics

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

As soon as you accept that software development is a production process, you can exploit the wealth of quality control methods common in production
Only a small part (10%?) of the development is really creative work. The remainder is the types of activities that are common to every development project. That's production. That can be controlled. It leaves more time for creativity!

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. Why didn't we learn anything in the past 50 years ?

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 so complicated that our skull cannot really oversee it all. So we should seize all possible means trying to master the complexity

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.

Managements most important task is to provide work processes which allow their workers to realise optimum performance.
Manager, did you know this, and what are you doing about it? Do you have the time? We gladly can mentor you and coach you.

Philip Crosby puts it this way  (ref."Quality Without Tears: The Art of Hassle-Free Management" Q6, page 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
Philip Crosby (ref. "Quality Without Tears: The Art of Hassle-Free Management" Q6, page 59).
A variation  is:
Management get the results they deserve

The current most used way of developing software is inadequate for reaching Quality On Time ever.
The methods for achieving Quality On Time are known, proven and available.
If you are aware of this and still  not changing your development process, you are wronging your organisation.

If they say "We have no time now" because they are so busy, it is even more time to do something about it now.
By starting with the most important issues, they soon will get more time. If you don't start immediately, you keep postponing and it will never happen. This wrongs the organisation: The organisation has to keep paying for too long developments and for getting results too late, not to speak of the cost of defects appearing after the development phase.

The shortage of software professionals can be resolved by teaching them Quality On Time principles.
Quality On Time workmethods are most effective for raising productivity significantly (without sacrificing the fun; on the contrary!). Tools are a distant second.

Just In Time Training is a good implementation technique.
Much better that a workshop from time to time, is identifying at the start of every project which methods and techniques should be trained in order to get the project done most efficiently. By practicing by doing, you learn best (if well mentored). Don't invent the wheel every time again. Build on what others found before you. The results are much more rewarding!

As soon as the development budget is exhausted, the panic budget is addressed.
The panic budget usually is unlimited. If you can avoid needing the panic budget, the profit margin will grow significantly.

When 90% is ready, you start on the remaining 90%.
Many developments are "planned" based on "if everything goes well". As long as your methods are not fit for achieving this, everything does not go well and you will find this out only at the end of your project.

10% of the development time is needed to make a computer system do what it should do. 90% of the time is needed to make it not do what it should not do.
This is why software development takes a lot more time than laymen, hobbyists and hopeless optimists think.

If you think that regular overtime produces more, you are fooling yourself and your organisation.
Regular overtime is selfincreasing. It leads to fatigue, thus more errors, thus more work. So it leads to less quality in more time. This is the opposite of Quality On Time.

What the customer wants, he cannot afford.

What you write down can be changed. What you do not write down, evaporates immediately.
So, what you do not write down does not count.
You have to extract sense from the fuzzyness in your head. If you say it, it is still fuzzy. By writing things down, you talk to the paper. If you write it down, you see the fuzzyness and can start making it clear. Then you can start discussing it with others. Together you can change the text until it is clear to the intended readership.

Any data (requirement, specification, software code) may be defined in one place only.
If data are defined in more places, they will diverge (it will not stay the same, if it ever was). If data are changed while not in one place only, you never know whether you changed every instance. However, you need a method (document control) that assures that all places where the changed data is referenced from are informed of any change. Relational databases use this principle. The same applies to software: every function should be defined only once (it would have made the millennium problem a piece of cake!).

Marketing should establish a system of continuously collecting information about experience with the products by the customers.
ISO9004.

Service should establish a system of continuously collecting information about problems with the products.

Danger zones in software development (ref. Humphrey)
A red light should flash (= stop, what am I doing?...) if:

If you don't know where you are going, any road will do. Chinese
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

Tigger: "Piglet, come with me!"
Piglet: "Where are we going?"
Tigger: "I don't know, but we are taking the shortest road!"
heard at 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 (Philip Crosby Associates) (2004)

5. The purpose is to ensure customer success