Malotaux Mantras

Mantra:
A word or phrase that is repeated often, or that expresses someone's basic beliefs

During my coaching in projects I hear myself often repeating these sentences. If after a year I return to these projects, I usually hear them repeated in the corridors and at the coffee machine. Once someone called these the Malotaux Mantras. They remind us of important things we should not forget.

If I find time I may add some more explanation.
The links point you to a page where this mantra is used.
If you are puzzled about the background of one or more of these Mantras, feel free to ask!

Some more in "Sentences" and "Aphorisms".

Mantras, in no specific order:

• If you need a tool for defect tracking, you have too many defects.
• Modulating on a subject is much easier than generating the subject.
• If you're not prepared to respond to a metric, don't measure it.
• If the requirements make no sense, the implementation will not be any different.
• If you don't know how to do something, it doesn't mean it's impossible.
• Telling people what to do creates resistance. Using a question invites a response.
  I we try to convince someone, or suggest someone to do things differently, better use the question form.
  (added Mar 2021)
• First develop the problem, then the solution, and only then the implementation.
  Some people think I'm referring here to BDUF (Big Design Up Front). That's just a bold assumption (see the mantra about assumptions). After all, we can use this on any, even the smallest activity of work.
• The user is always right, even if he's not
  Used when a developer is surprised when a user doesn't do what the developer thinks the user should do.
  or, when a developer thinks he knows what the users want:
  • Guys, we already are so deformed that we cannot imagine what normal people find normal. We should find out.
  • We better assume that any of our assumptions can be wrong. We should check.
  • The proof of the pudding is when it's eaten and found tasty by them, not just by us.
• Don't work for a tool (nor for a process). It doesn't pay your salary. Only if it works for you, then you may.
  We see so many people spending time on a tool like MS-Project, Jira, or similar, without thinking about the Return on Investment of spending that time.
• Working more than half an hour per week with MS-Project is wasting your time
  You may use MS-Project to show some TimeLine, but if you spend more than half an hour per week on it, you're putting in too much detail.
  Don't let MS-Project do anything for you. It doesn't know what you should be doing. It only likes to waste your time.
• If we put our planning data in a computer, we lose control.
  Some people don't like the visibility and transparency of whiteboard planning. Hence they rather put their data in a computer, so that it's less visible what they are doing, and whether it is up to date. This indicates uncertainty whether what they're doing is right. If they really know what they are doing and why, they won't be afraid to show it to themselves and to anyone else.
• The planning on the whiteboard should reflect reality at least once a week.
  It doesn't have to reflect reality every second. After all, we're not 'working for the tool'. But at least once a week making sure that the planning shows the truth, and nothing but the ugly truth. Transparency of reality often shows that we 're not progressing like we wish we should. This urges us to do something about it, to make what we do a success.
  If anyone asks, we can immediately explain what's on the whiteboard and why it is as it is.
• What we deliver, simply works
  Question by the PM: "Does that mean without bugs ?" Answer: "It simply works. Did I use a strange language?"
• No Questions - No Issues (nqni)
  At (least at) the final test before delivery, the testers should have no questions and find no issues. If they have just one question to ask, or find one issue: the test is aborted as failed. After all, once our software is out there, we're not there to help the computer. It should simply work!
  "No questions, no issues" proved to be a good technique for turning the Zero Defects concept into practice quickly.
• Testing shouldn't delay a delivery, but the testers don't cause the delay!
  Deming:
  
  • Quality comes not from inspection (V&V), but from improvement of the production process
  • Inspection (testing) does not improve quality, nor guarantee quality
  • It's too late
  • The quality, good or bad, is already in the product
  • You cannot inspect quality into a product
  Developers caused the delay. Testing can only show that the developers did a good job, or not.
• We are not perfect, but the customer shouldn't find out
  People make mistakes, we are people, so if we do something we're introducing imperfections.
  The customer, also being human, is also making mistakes. If we both play macho, as if we never make mistakes, only seeing the mistakes of the other side, we will perpetuate these mistakes. If we're humble enough to admit that we are human and therefore making mistakes being a risk for the success of the work we do, that's the start of doing something about it.
  Of course the customer will find out and knows we're human after all. That's why I use as an alternative:
  We are not perfect, but the customer shouldn't be affected, however, that sounds less nice, I think.
• Any project that takes more than a year is doomed to fail
• Time is money and we don't have the right to waste it, unless it's our own
  We get paid a salary for what we're doing. So we better make sure that we deliver value in exchange. If we still want to do something that is not of value for our organization, but we still want to do it, we call it a hobby, to do at home in the weekend.
• Every day we know a problem earlier, we have a day more to do something about it
• How do we make sure that in the end we don't need an excuse
• Looking back we see that nobody could have done better, not even us
• Active Synchronization
• Interrupt Procedure: "We shall work only on planned Tasks"
• We failed
• What are we going to do about it
  Often people are stuck in the Check-phase of PDCA, talking about problems bothering us. The moment we say: "What could we do about it?" we move people to the Act-phase: "What are we going to do about it?" Usually we work with quite clever people and they always immediately come up with some suggestions. The next PDCA cycle we can check out the most promising suggestion, and in the next Check-phase check whether it worked out as expected.
• Because failure is not an option
• If the requirements aren't clear (which usually is the case), any schedule will do
• The fallacy of 'all' requirements
• If we add something, something else will not be done
• Delivery Time is a Requirement like all other Requirements. How come most projects are late ?
• The Requirements are what the Stakeholders require, however, for a project the Requirements are the set of stakeholder needs that the project is planning to satisfy
• Customer 'requirements': Nice Input, to be taken seriously
• What the customer wants, he cannot afford. If we start doing that, we fail from the beginning
• The only justifiable cost is the cost of developing the right things at the right time
• The Bullshit Stamp
• People aren't against change. Subconsciously they don't like uncertainty
• What is the cost of one day of (unnecessary) delay
• Important metric: The size of the smile of the customer
• About half of what people do in a project later proves to be unnecessary hence we have a huge budget to be on time
  If we can foresee half of that half, and decide not to waste time in that, we already are saving 25% of the time, allowing us to do 30% more in the same time.
• Can we do less, without doing too little ? Not doing what later proves to be superfluous
  Alternatively: Can we do less, while delivering more ?
• People make mistakes, we are people, therefore when we produce something, we're injecting defects
• The better focus, the less we'll waste time
• In any meeting with more than one person, we use a projector
• The owner of the text types
• Where are the whiteboards ?
• What you write down can be discussed and changed. What you don't write down, evaporates immediately
• Quality costs less
  Phil Crosby said "Quality is Free". 15 years later, he said "Quality is still free". My experience tells me: Quality costs even less!
• If this project is late, the next project will also be late
• As a rule, never work overtime, so that you have the energy to do it once or twice a year, when it's really necessary
• Very clever Systems Engineers, many documents to be reviewed within two weeks; people stressed: "stupid management", "impossible schedules", not meeting deadlines till now.
  • How many documents to review ?
  • How much time per document ?
  • How much time available ?
    • Needed time: 99 hrs
    • Available time: 46 hrs
  • So now we already know that we will be late. Failure is not an option. What will we do about it ?
  • Show some possible solutions
  • The puzzle of project planning is a design problem
    Now these engineers can use their bag of tricks, because they know how to design
  • Result ?
    Reviews done on time. Everybody content with the result. All subsequent deadlines met
• Why are we doing this ?
• Is it really necessary ?
• Is it really necessary now ?
• Who's waiting for it ?
  • Example: "It worked ! The magic sentence worked !"
• What does he need ?
• How much does he need ?
• Why ?
• How much time do we have available = gross available time
  • 2/3 is plannable time
  • What are the most important things to do
  • We work on the most important things only. We don't allow ourselves to work on anything less important
    1. How much time do these things take
    2. How much time do you have
    3. How much time do you need
    4. How much time should you use
    5. How much time do you give yourself
• What will fit the available plannable time
• What will be done by the end of the week
• What will not be done
• Will this be completely done by the end of the week? How do you know?
• It's ok if you promise to do nothing as long as that is done, completely done by the end of the week
• Definition of Done: "Done, 100% done, no need to think about it any more"