How Quality is Assured by Evolutionary Methods
By: Malotaux, Niels
After several years of experience as a Project Coach introducing Evolutionary Project Management
Methods (Evo) in development projects, I think I can claim that Quality can be Assured if projects apply
these methods. Does this mean that the Quality Assurance function is not needed any more? No. QA is still
needed, because one of the main factors jeopardizing the Assured Quality is lack of discipline - discipline to
keep applying the methods in order to meet our commitments.
In many cases, people know the best way to do their work. However, if nobody is watching, people tend to
take shortcuts. If somebody is watching over their shoulder, people tend to take fewer shortcuts. The
Project Manager can watch over the shoulders of the team. The team can watch over each other’s
shoulders. But who’s watching over the Project Managers’ shoulder? This task is the responsibility of
management, but the Quality Assurance function can help.
Even with an assurance function in place, team members still have to know what is the best way to do their
work in the first place. Since there is no absolute “best way”, while the “best way” is even dynamically
changing, we must also provide the people with an ability to actively find out the best way while working in
Evo is actually rapidly and frequently applying the Plan-Do-Check-Act (or Deming) cycle, not just for the
development of the product, but at the same time for the organization of the project and even for
assessing and improving the methods used on the project. We need to continuously ask ourselves: “What
should we do now, in which order, to which level of detail for now”.
Working the Evo way means organizing the work in weekly (or even shorter) Task-cycles. In these Taskcycles
we optimize estimation, planning, and tracking. Task-cycles feed bi-weekly (or shorter) Deliverycycles
by which we optimize the requirements and our assumptions. We use a practice known as TimeLine
to create and maintain the total project scope and to connect the Project Result, through the Deliveries,
with the actual work organized in Tasks. Evo combines Estimation, Planning, Tracking, Requirements
Engineering, Requirements Management, and Risk Management into Result Management. Result is defined
as the combined value we provide to all the Stakeholders of our product, ultimately leading to customer
success. Evo has a fanatical view on ROI: Whatever we do should contribute to the Result and we try to
avoid whatever does not contribute.
In this paper I will explain the basics of this Evolutionary approach and practical details people can start
2 The Goal
Let’s assume that the purpose of development projects is to deliver what the customer needs, at the time
he needs it, to create substantially greater value than the cost of development and to enable customer
success. In short, we call this Quality On Time: the right things at the right time.
It is important to note that the functionality we are working on in most development projects already
exists. Usually, all we are supposed to do is enhance the performance of specified functionality to create
more value for the customer. The set of functions we are enhancing defines the scope of the project. The
scope should be chosen such that it provides more value for cost than another scope.
It would be nice if we could in one project develop the ultimate solution, creating the ultimate value. Apart
from the risk that, when done, we could be out of work, this is not possible because of limited resources
• The available time (time to market may strongly influence time to profit)
• The available money
• The available people and the capabilities of these people (it would be nice if we could hire the best
people. Normally, however, the challenge is to succeed with average people)
• The available experience on the subject
• The available technology
• The capability of the users to adopt the new system
In development projects we can only strive to optimize the compromise between value creation and the
available limited resources. If the results we can achieve, given these limited resources, are insufficient to
provide significant value for customer success, we shouldn’t even start the project. Given these limited
resources we are not even satisfied with good results, we actively want to maximize the Result created.
Looking back at the end of a project, not only should our customer have a big smile of satisfaction, we
should ourselves also be confident that we couldn’t have done better.
This implies that we should feel a Sense of Urgency to constantly optimize the results we are working on,
to constantly optimize our success. Without this Sense of Urgency, Evo doesn’t work.
Since childhood we learn intuitively through
experience. Besides learning from our own
experience, we also learn from accepting the
experience of others: at school, in workshops
and at conferences. This learning process is
rather slow. We can, however, stimulate the
learning process by actively using the Plan-Do-
Check-Act cycle, as presented by Deming:
What are we supposed to accomplish and
how are we going to accomplish it?
Carry out the Plan
Is the result and the way we achieved the result according to the Plan?
• If the result was not according to the Plan, what are we going to differently the next time to
achieve a better result?
• If the result was according to the Plan, was it accidental? How do we make sure next time the result
is equally according to Plan?
Do is never a problem: we “do” all the time. Plan we do more or less, usually less. For Check and Act,
however, we have no time because we think we want to go to the next Do. Well, that’s what I believed
until recently. Taking a closer look at what really is happening we can see that Check is often done: people
seem to be quite aware what is going wrong and often even know what should be done about it. The real
problem is that we don’t Act: taking what we know and doing something about it.
... to read more articles, visit http://sqa.fyicenter.com/art/