Okay…
it has been a while since my last installment in this series. Aside
from my general inability to stay focused on a single topic (what was I
thinking committing to a nine part series) I got really swamped
preparing for Agile 2008. I've got two talks coming up in November on
this material, one of which has a presentation due in early September,
so I guess it is time to get busy and get this series wrapped up.
Last time we covered Communications Management, in this post we'll discuss Quality Management.
As
always, let's start with the PMI definition of Quality Management.
According to PMI, Project Quality Management includes all the
activities of the performing organization to determine quality
policies, objectives, and responsibilities so that the project will
satisfy the needs for which it was undertaken. There are three
processes included in this knowledge area: quality planning, perform
quality assurance, and perform quality control.
If you've been
following this series, you'll know that my general approach with the
PMI is to take guidance from the PMBOK and figure out how to satisfy
the intent of the process with a more agile practice or principle.
Agile is all over quality planning, quality assurance, and quality
control but we often use different language to describe how we satisfy
these objectives and we often plan for these activities in a pretty
different way.
Let's see what we can do to bridge the gap...
Quality Planning
PMI Definition: Identifying which quality standards are relevant to the project and determining how to satisfy them
Quality
planning is really about the initial set of assumptions (we make as an
agile team) about how we are going to manage quality on our projects.
As it relates to developing software, quality planning has mostly been
done for us… it is implicit… it is understood by virtue of the fact
that we are using an agile methodology.
When we have discussions
about doing test driven development, pair programming, or continuous
integration; we are making decisions about how we are going to handle
quality. The decision to make use of acceptance criteria is simply a
decision on how we will know we have met the requirements of our
stakeholders.
Are we going to do unit testing? How about manual
regression? Will we need to test for performance, scalability, or
security? How will we know we have met any applicable regulatory or
audit requirements? I would venture to say that most agile teams are
having these conversations. Even if your team is not writing this stuff
down or getting sign-off, you are implicitly developing your quality
plan.
It is up to the team to balance how much of this needs to
be documented. Ask yourself to what degree will a document facilitate
understanding or help with stakeholder communication? Consider how much
documentation is required by your organization. Keep things simple,
minimally prescriptive, and make provisions to adapt your plan as you
learn more about the emerging solution.
Perform Quality Assurance
PMI Definition: Applying
the planned, systematic quality activities to ensure that the project
employs all processes needed to meet the requirements
You've
made some initial decisions about how your team will meet the quality
expectations of the organization… now it is time to execute. Quality
assurance is about making sure we are building the right product from
the very beginning.
Early in the iteration, we meet as a team
with our customers to define exactly what is to be built. Every role on
the project has the opportunity and is encouraged to be involved. There
are people looking at the requirements from every conceivable angle:
system architecture, development, QA, analysis and design, and
usability. We explore the problem from all perspectives, before we set
off writing code, to ensure we are building a complete product.
Once
we get started building out the features, we immediately execute our
testing plans. At a minimum, agile teams are writing unit tests and
doing continuous integration. We know at every moment of the project
how well the code is performing against the requirements.
If
your team has dedicated QA members, the QA folks are testing right
along with the development team. Sometimes it is more exploratory and
we are not looking for sign-off, we are really looking for feedback.
Feedback from the QA team is essential to making sure that the product
is evolving according to the quality standards we agreed to at the
beginning of the iteration.
The team holds itself accountable by
meeting in a daily standup. This allows the team to stay plugged in,
assess progress, and identify impediments. In addition, the team has
constant access to the product owners. This constant visibility allows
the customer to fine tune the solution, as it is being built, to ensure
that the product will meet market requirements.
Perform Quality Control
PMI Definition: Monitoring
the specific project results to determine whether they comply with
relevant quality standards and identifying ways to eliminate causes of
unsatisfactory performance.
Even though quality is the
focus from the very beginning in an agile project, we still seek to
validate outcomes and formally track the quality of the product we are
building.
The advantage of automated testing is that we know the
health of the product in real time. We are able to measure and track
defects and get them resolved as soon as they are introduced into the
build. Manual testing, in parallel with the automated testing, gives a
more intuitive way to exercise aspects of the code the are difficult to
automate.
As a project manager I am constantly tracking burndown
at the project level to see how well the team is doing against the
backlog. Within the iteration, I am tracking task progress to make sure
that we can deliver on our commitments. Agile teams also track defects,
defect status, and test trends. All this gives the team a way to
continuously control the project quality.
Agile teams don't wait
until the end of the project to test, when we have the least amount of
time to actually fix a problem, or respond to a change. We know at all
times the health of the project, if the team is burning hot, if defects
counts are trending up or down, how well we are resolving issues, and
if those issues are becoming impediments to getting new product built.
Agile
teams review features with their customer as they are completed. They
do formal product demonstrations and retrospectives at the end of every
iteration. These processes allow the team to control, not only the
quality of the emerging product, but also of the processes we are using
to deliver that product.
All of this feedback gets folded back
into the plan, adjustments are made, and the team adapts based on what
they have learned from regularly delivering code.
Next up… Procurement and Human Resources. We'll save Risk Management and Integration Management for last!
