NRMC Glossary

Glossary

Glossary of terms used by Malotaux with Evo.
Please send comments and suggestions to: niels @ malotaux.eu

Term	Definition
Active Synchronisation	See Active Synchronisation page.
Architect	The "conductor" of the orchestra of the product (See Project Manager: conductor of the logistics). Architect is actually a management function: having vision, knowledge and experience of which product to make and how to make it, and creating the result through the minds and hands of others.
Bug, debug	A bug is a small creature, autonomously creeping into your product, causing trouble, and you cannot do anything about it. Wrong! People make mistakes and thus cause defects. The words bug and debug are dirty words and should be erased from our dictionary. By actively learning from our mistakes, we can learn to avoid many of them. In Evo, we actively catch our mistakes as early as possible and act upon them. Therefore, the impact of the defects caused by our mistakes is minimised. This leaves a bare minimum of defects at the end of the project. Evo projects do not need a special debugging phase. See also Zero Defects
CandidateTask	A Task that we could consider. See also Evoplanning
CandidateTaskList	A List of Tasks that we could consider, listed usually in order of priority
Complex	Once you think you know, it may already have changed.
Complicated	Once you know, you know.
Culture	Ingrained customs Culture is what we learnt by mimicking what we experienced around us: language, social behaviour, faith, religion, folklore, and how these things develop by our social interactions. We cannot change culture, but culture can change, if we change our habits (difficult!) and way of working.
Customer	The entity that orders our development and pays for it. Because he's paying, the Customer could be interested in a cost/benefit trade-off. Other stakeholders don't pay and may have other priorities.
Debug, debugging	Dirty words. Should be scratched from our dictionary. If you want to know how, we can talk about it. See also bug.
DeliveryCycle	What are we going to deliver. Never more than two weeks. See also Evoplanning
Defect	Cause of a problem experienced by a Stakeholder, ultimately by the Customer. Using this definition for software, most so called defects aren't defects, as about half of the software delivered is never used by any Stakeholder. The only defect is then that this part of the software was made.
Design	Design is finding the best compromise between the conflicting requirements and deciding how the product is realized.
DesignLog	See DesignLog page.
Developers	General description of people who work in development projects. Systems Engineers, Architects, Designers, Programmers, Testers, Project Managers. All those functions that together have to make the development project a success.
Discipline	With discipline we don't mean imposed discipline, but rather what you, yourself, know what is best to do. If nobody watches us, it is quite human to cut corners, or to do something else, even if we know it is wrong. We see ourselves doing a less optimal thing and we are unable to discipline ourselves. If somebody watches over our shoulder, keeping discipline is easier. Discipline is difficult, but we can help each other. Evo helps keeping discipline. Why do we want this? Because we enjoy being successful, doing the right things.
Done	100% done. Not to think about it anymore. Only 100% done is done. If 90% is done, we usually still have to do the other 90%. Therefore, done should better be binary: it's either done or not done.
Duration	see LeadTime
Effective	Producing a desired result with the intended properties
Efficient	Producing an effective result economically (with least waste of materials, time, or energy)
Effort	The net amount of time to accomplish something
Estimate	The tentative or approximate judgement of the numerical value of size, worth, significance or duration of something
FatalDate	A hard time limit upon we will deliver what we promised. If we do not deliver at the FatalDate we Fail. No finger-pointing to anybody, because we took the responsibility, and we didn't deliver. Even if really somebody else was the cause, we could have warned our customer earlier, escalated, or even given back the responsibility. At the FatalDate itself, nobody fails but us ourselves.
Focus	Developers tend to be easily distracted by many important or interesting things. Some things may even really be important, however, not at this moment. Keeping focus on the current priority goals, avoiding distractions, is not easy, but saves time.
Goal of a Project or 'Goal of our Work' (for those who don't like the word 'project')	Providing the customer with what he needs, at the time he needs it, to be satisfied, and to be more successful than he was without it ... If the customer is not satisfied, he may not want to pay. If he is not successful, he cannot pay. If he is not more successful than he already was, why should he pay anyway? Of course we have to add that what we do in a project is: ... constrained by what the customer can afford and what we mutually beneficially and satisfactorily can deliver in a reasonable period of time. See more at Goal of our Work
LeadTime	The time between planning a Task and delivering the result
ProcessLog	Similar to DesignLog, but now about the design of how we work
Product	A Result, something produced. Systems Engineers may use the word System.
Programmer	In software projects, programming is the function who transforms the software design into code, which subsequently is turned into computer executable code by a compiler, assembler and/or interpreter. When a person is performing this function, we call him/her a programmer.
Project	A planned endeavour with clear start and end conditions, where something not yet well known is done in between. If it's completely well-known, we call it production.
QA
Requirement	Requirements are what the Stakeholders require. However, for a project, the requirements are what the project is planning to satisfy. After all, what the Customer wants, he cannot afford. The other Stakeholders, who are not paying, are not interested to trade-off or to compromise, so they would want all they think they want. If the project is trying to satisfy that, it will fail from the beginning. Requirements define what is to be realized, not how it is realized (that is Design).
Result	Result is what the Project produces: the Right Result at the Right Time, produced efficiently, that is with minimum waste.
Risk	An event that may cause a Defect. (Others use: An uncertain event that, if it occurs, has a negative effect on project success)
Stakeholder	Anybody with a stake in what we are doing.
Synchronise	Every project interfaces with the world outside the project. Active synchronisation is needed to make sure that planned dates can be kept.
Systems Engineering	Producing the right product at the right time to provide the right solution to the right problem even if the problem changes (Thanks Joe Kasser)
Task	A defined piece of work to be finished within a certain time
TaskCycle	See weeklyplanning
Tester
TimeBox	A TimeBox is the maximum time available for a Task. When the time is up, the Task should be completely done: there is no more time! Coaching helps people to define their own timeboxes properly within a few weeks. See TimeBox
TimeLine	A technique for controlling longer periods of time. A line from Now to Then ('Then' being a defined date!)
User	General term for people who (will) use the system we develop. The value of the system only crystallizes when the system is successfully used by the users. Different users may use different parts of the system, and use the system differently. The combined user success will determine the value delivered.
Victim	Special type of Stakeholder. Is negatively affected by the results of our project. They want the project to fail, and they may succeed, unless you manage this group of stakeholders appropriately.