Glossary of terms used by Malotaux with Evo.
Please send comments and suggestions to: niels @ malotaux.eu
|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|
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.
|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.|
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.|
|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.|
|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|
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.
|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.|