ASK Process Articles

ASK Process proudly makes all of these resources available to you to support your process improvement needs. Please tell us if you have questions or comments about any of these articles, or if there is a topic that you would like to see covered.

Title Abstract
"Agile" Means Disciplined SCM (Software Configuration Management) For many people, Agile software development congers up the thought of "undisciplined" software development.

The reality is that using an Agile approach to its greatest benefit requires discipline in a variety of ways. And none is more critical than the discipline of Software Configuration Management.

Agile teams are generally small, but their SCM needs are big - very big indeed! So big that all of the good things an Agile teams does could be rendered moot by a lack of SCM discipline.

This article is Mr. Koch's regular column, "From Here to High-Quality" in CM Crossroads.

The Essence of Agility: Part 1 of 3: Learning & Adaptation, and Collaboration The Agile approach is often panned as an excuse for lack of discipline. I've been told that Agility means, "We'll just wing it, and when we run out of money, we'll ask for more." This and other such statements show that many people don't understand what Agility is all about.

The confusion is understandable because there is a plethora of practices that people claim as "Agile." And unfortunately, some of them are indeed using the term "Agile" as an excuse for lack of discipline.

True Agility is based on a few distinct principles that are underpinned by a unique value system. The application of these values and principles results in a few indispensable behaviors that can be seen and judged objectively by any interested stakeholder of a project. It is those behaviors that we refer to as the Essence of Agility.

This article is Mr. Koch's regular column, "Connecting with Quality" in Project Connections.

The Essence of Agility: Part 2 of 4: Customer Focus Is the team 'Agile,' as they claim, or are they using that term as a cloak for a lack of discipline? One way to know is to observe what drives their activity: do they do what is cool, or do they do what the customer values? In this article, we will continue to explore the types of discipline that are the essence of being Agile. This time, we will focus on how the team relates to their customer.

It is all about our customer. All! An Agile team will do everything in their power to maintain continuous (or at least regular) contact with their customer, because that contact is essential to their ability to produce what the customer needs. An Agile team doesn't trust a Requirements Specification to tell the whole story. They know that if such a document was written, it contains errors, interpretations, and key omissions. They also know that even if it accurately represents what the customer thought they needed when they signed off, things are likely to change before the product is complete.

In order to ensure that they deliver what the customer really needs (and needs today), the team includes the customer in team activities as often as possible. The customer's input is important in each phase of the Agile lifecycle.

This article is Mr. Koch's regular column, "Connecting with Quality" in Project Connections.

Standards That Are Worth Following Conventional wisdom tells us that standards are a good thing. They are based on best practices, and they provide guidance to help people do their jobs well. They are so widely accepted that their worth almost goes without saying.

But as with most things that go without saying, standards are not always what they are billed to be. In spite of the plethora of standards in the software industry, we still struggle mightily to achieve successful projects. Even in organizations that are standard-centric, projects end up in challenged (or worse) states.

So let's explore what it is that constitutes a standard, and more importantly, what makes a standard worth following.

This article is Mr. Koch's regular column, "The Road to Quality" in CM Crossroads.

PM Network: Feedback: Dilbert Isn't Real & Agile Experience These two letters to the editor by Alan S Koch were published in the February 2008 issue of PM Network, the official publication of the Project Management Institute.

Dilbert Isn't Real :

As I read Michael Hatfield's piece ("To the Rescue", November 2007), I was waiting for the other shoe to drop. "Ha!" he would write, "I tricked you!" But no! He really was writing about senior executives plotting stupidity.

Oh, come on!

While this may have been intended as a humorous piece, it belies (and supports) the too-widely held idea that Dilbert's boss inhabits our boardrooms.

Agile Experience :

In complaining about Carol Hildebrand's article "Full Speed Ahead" (October 2007) in the December Feedback, Stephen Wilson, PMP, claimed his view was based on his experience using agile techniques. Clearly, if he has experience with techniques claiming to be "agile", they bear no resemblance to agility as it is intended.
Why Agile? Learning to develop software successes Software projects have been a problem area for a long time. For decades, researchers have bombarded us with grim statistics about the prevalence of challenged and failed projects, the rarity of truly successful ones, and the huge waste of time and money that results. And the sad truth is that our experience conforms to those statistics. This is a pain-point for us, and so we look for answers.

At the same time, new approaches have been introduced regularly and with great fanfare. Each of them has promised to solve our software project problems; to make our software projects predictable and successful. We canŐt remember the names of most of these approaches because for most of us, the reality was disappointing; the pain remains.

And now along comes "Agile". Why should we pay any attention? Why should we expect this is anything more than the latest brand of snake oil?

This article is Mr. KochŐs regular column, "Connecting with Quality" in Project Connections.

The Definition of "Done" "I thought you said you were done with the Cranfragle last week!" Sue demanded. "I just talked with Alan and he said that you haven't even started on the GreenFlop."

"Yes", Joe answered, "I'll be starting on that tomorrowies that have to do with the Cranfragle?"

Sue's jaw dropped. "How can you ask that? You're not done until the GreenFlop is done! "

What does it mean when a member of your team says that something is "done"? Taking the time to define this critical term does much more than avoid disagreements. It can also save critical project time and avoid embarrassing oversights.

This article is Mr. Koch's regular column, "The Road to Quality" in CM Crossroads.

Risk Management: It's not just a good idea... Risk management, identifying the things that might go wrong on your project and deciding what to do about them, is almost universally considered to be a good idea. In fact, I can't remember ever having someone tell me that they don't think it is a good idea. "Oh yes!" I am often told, "we should do that!"

"Should?"

Build Quality In: The Agile Methods are right! For decades, independent testing has been the accepted "best practice" in quality. Unfortunately, this supposed best practice has not proven to be effective in achieving better quality. Some organizations that have independent testers do well, but many do not. And some organizations that achieve high quality do so without independent testers.

So, what is the common thread? What differentiates those who achieve high quality from those who can't? It is the developers themselves! The old adage is proven true: "You can't test quality into the product; it must be built in."

And it is the Agile methods that have declared this adage to be "best practice".

This article is Mr. Koch's regular column, "The Road to Quality" in CM Crossroads.

Did That Process Change Work?: Four Steps to Better Processes There is an old saying that goes, "You can't manage what you don't measure." This saying has survived the test of time because it is an essential truth. And it applies to more than just organizational management or even project management. It is just as true for process change.

Coming up with good ideas for process changes is no different from coming up with good ideas for product requirements; it is only the first step. The real work follows that step. And that real work is what must be carefully managed--and carefully measured!

This article is Mr. Koch's regular column, "Connecting with Quality" in Project Connections .

The One Right Way to Achieve High Quality Requirements Don't expect there is one right way!

Many authorities have undertaken to lay out the One Right Way to engineer system requirements. Although there are similarities among them, what is most striking is the diversity in approaches, and in some cases, conflicting philosophies. What are we to make of these dueling authorities and their competing guidelines?

Each of the approaches has supporters and adherents because each works (at least in specific circumstances). From this, we can derive our most important lesson about Requirements Engineering; that there is not One Right Way to engineer requirements.

This article is Mr. Koch's regular column, "The Road to Quality" in CM Crossroads.

Lessons Learned: Its Not Just a Good Idea... Call them "Lessons Learned," "Retrospectives," "Postmortems," or whatever you wish; taking the time at the end of each project to look back is almost universally considered to be a good idea. In fact, I can't remember ever having someone tell me that they don't think it is a good idea. "Oh yes!" I am often told, "We should do them!"

"Should?"

Audit Trails, Traceability Because Sometimes Things Go Wrong: (And no, they are not to place the blame!) Any time we make a change to production, there is the risk that something will go wrong. Risk is a fact. The only way to eliminate risk is to never do anything. (But of course, that is not an option.) So we are left with actions we can take to mitigate those risks.

Configuration Management (CM) is mainly about risk mitigation. Everything we do in CM is designed to reduce the likelihood that things will go wrong, or to reduce the adverse impact when they do go wrong. CM helps us to avoid many failures, and to recover quickly from those few that we can't avoid.

But how do audit trails and traceability fit into this picture? Traceability doesn't prevent errors, and an audit trail does little to help me to recover from one. Does this mean they aren't valuable CM tools?

This article is Mr. Koch's regular column, "The Road to Quality" in CM Crossroads.

What is the BA's Role?: Four steps to a clear answer "So, where does the Business Analyst role end and the Project Manager role begin?" asked a concerned student in a recent Introduction to Business Analysis class. "I see lots of opportunity for toes to be stepped on if we implement these things in my organization!"

Business Analysis has only recently gained recognition as its own discipline, and many organizations are learning about it in an attempt to make it a part of their project structures. As the student above realized, making this new role work in any organization will include determining precisely who should be responsible for what activities, and where the limits of each person's responsibilities and authority lie. This should not be surprising; although the role is new, the activities that it represents are not.

The Business Analyst role can overlap several others in your organization, but this simple approach will minimize conflicts over responsibilities.

This article is Mr. Koch's regular column, "Connecting with Quality" in the 19 July issue of Project Connections.

Meeting Customer Requirements: First Time, Every Time Using TQM Total Quality Management is a commitment to the continuous improvement of work processes with the goal of satisfying internal and external customers. It's the customer that matters in TQM, the process is the means to satisfying the customer.

This article by James A Ward provides a good summary of the principles behind TQM; a "fad" that has run its course, but none-the-less embodies principles that will never go out of style!

The QA Catchall Years ago, I gave a presentation that I called "A is for Assurance: A Broad View of SQA." It explored the variety of activities that are necessary to actually assure quality. During the question-and-answer period, I had this conversation:

Audience Member (AM): I would love to do those sorts of things, but I can't see how I can get them to happen in my QA department.
Me: What is your role?
AM: QA analyst
Me: And what do you do?
AM: I develop test plans and test cases, and I test our product.
Me: And what are the other quality roles in your company?
AM: The QA manager manages the testing.
Me: Sigh! (the heavy variety)

I didn't have the heart to tell that audience member what I would say today: "You don't work in a QA department, your manager isn't in charge of QA, and what you do has nothing to do with quality assurance."

My talk resulted in frustration for people like that audience member because the software industry has made achieving quality a frustrating job. The QA people I have met and worked with are excited about quality, but they are usually in positions where they have little opportunity to assure quality.

This Article was published in Better Software Magazine

Personal Quality Management With the Personal Software Process Software development organizations have a variety of mechanisms at their disposal to help in managing and improving the quality of the products they produce. Quality Assurance organizations, problem reporting systems, software process improvement and peer reviews (to name just a few) are important tools for product quality enhancement. But an often-overlooked piece of the quality puzzle may well provide the most effective means to improve product quality: the individual software engineer.

After a short introduction to what the Personal Software Process (PSP) is, we will highlight the ways in which individual engineers (and their organizations) can benefit from adding the PSP's Personal Quality Management techniques to their professional repertoires. We will take a brief look at the benefits that have been achieved by those who have already learned to apply these principles in their work. Then we will examine in more detail the specific activities PSP-trained engineers engage in to manage the quality of the software they produce. We will look at everything from simple defect logging, to personal and peer reviews, to developing a personal quality plan and using it to guide your work.

Investing in Quality: When is "Enough" Enough? There is no doubt that we need to invest in producing a quality product. But it is not clear how much we should invest. Invest too much and we waste precious resources; invest too little and our product will be judged as poor-quality, and our project may be labeled a "failure." (Yikes!)

So, how do we find that sweet spot? How do we determine the "right" amount of quality investment?

You already have the information you need to answer that question. It is in the records from your prior projects. Both the projects that produced "good" quality and those that did not set the stage for you to make the right quality investment decisions this time around.

This article was Mr. Koch's regular column, "Connecting With Quality" in the 27 February 2007 issue of Project Connections.

Ensuring "Good Enough" Project Quality Management, Part 3: Quality Control I don't need to ask if you test and debug your products. We all do! But we are not all successful at ensuring that our products are "good enough"! In fact, many of us find that, in spite of our best efforts, the products that we put into production are disappointing. We are doing Quality Control activities only to find that they have been less than effective.

Ensuring that our product is "good enough" takes more than just trying hard! It requires that we do the right things, and that we do them well.

Is Your Metrics Database Write-Only? A "Write-Only" database? Yes, I have seen them, and many of you probably have seen them as well! Those are the cases where organizations are constantly collecting metrics and writing them to a database, but not using that data.

There is no question that a write-only metrics database is unhealthy for the organization. But collecting no metrics at all is also unhealthy. Of course, the ideal would be for us to collect metrics that we actually can use - and then to actually use them! And GQM (Goal-Question-Metric) can get us there!

This article was Mr. Koch's regular column, "The Road to Quality" in the March 2007 issue of CM Crossroads.

Assuring Quality: Beyond Testing & Reviews "Test? Of course we test! It seems like we spend way too much time testing. And we review designs and code, too. But all we are doing is finding defects. Lots and lots of defects! Isn't there more to QA than finding all of these defects?"

Yes, there is much more to QA than that. In fact, testing and reviews should really be called "Quality Control", or QC for precisely that reason. They don't really assure quality; they merely check the quality and keep the product from going into production if it is too bad.

Quality Assurance involves the proactive activities that can actually assure that we will build better quality than we have in the past. The bottom line on QA is paying attention to how we do the work we do, and how effective that work is.

This article was Mr. Koch's regular column, "The Road to Quality" in the February 2007 issue of CM Crossroads.

Gettin' Better, Project Quality Management, Part 2: Quality Assurance Quality Assurance (QA) is the application of planned, systematic quality activities to ensure that the project will employ all processes needed to meet requirements. QA also provides an umbrella for another important quality activity, continuous process improvement.

Even with that quote from the Project Management Body of Knowledge (PMBOK®), many readers, seeing "Quality Assurance" (QA) in the title of this article, will expect to read about testing and reviews. Sorry! That will be next month when we talk about Quality Control.

Quality Assurance has nothing to do with testing or reviews. QA is the proactive things we do before and while we are building the product to assure that we will achieve our quality goals.

Yes, You Can Negotiate Project Constraints! "This is what we need. You can use these resources. And you must deliver it by that date."

Does this sound familiar? If so, you are not alone. Many project managers find themselves in just such a situation. There are lots of dictates, no flexibility, and more often than not little realism in the demands.

What value is there in estimation when your sponsor seems to have no interest in finding out what it will really take to do the project? The constraints have been chiseled in stone and we can't change them. End of story. Our job boils down to trying to keep the project from being too much of a disaster.

Although it may not seem to be true, we can negotiate unrealistic project expectations. And the key is to do a good job of estimating what it really will take to do the project.

This article was Mr. Koch's regular column, "Connecting With Quality" in the 2 January 2007 issue of Project Connections.

What is "Good Enough"? Project Quality Management, Part 1: Quality Planning Quality planning involves identifying which quality standards are relevant to the project and determining how to satisfy them.[1]

The PMBOK® Guide makes it sound simple enough. But for many of us, the relevant quality standards are not immediately obvious. In fact, many of us find ourselves with little other than the vague impression that the quality of prior projects was not good enough.

If we are to do appropriate Quality Planning, we must figure out how to answer these two pressing questions:

  1. What does it mean for our product to be "good enough"?
  2. How can we ensure that our product will be "good enough"?
We will discuss how to find the answers to those two questions in this first of three articles on the PMBOK's "Project Quality Management" Knowledge Area.

[1] A Guide to the Project Management Body of Knowledge (PMBOK Guide), Third Edition, Project Management Institute, Inc, 2004, Section 8.1.

Who Does QA? Hint: Not Your Testers! Many of us have Quality Assurance (QA) groups in our organizations, and the natural assumption might be that these groups are responsible for the quality of our products. For a few of us, that assumption might hold true, but for most organizations, the QA group cannot be held responsible for quality because they don't actually assure quality. All they do is test.
ITIL: A Foundation for Project Success At its heart, quality is a matter of meeting the business need. In most projects, obtaining a clear understanding of the business need and translating that understanding into product specifications and a project plan can be one of our biggest challenges.

The Information Technology Infrastructure Library (ITIL®) is a process model for IT Service Management, just as the Capability Maturity Model Integration (CMMI®) is a process model for product engineering projects.

Can a model that is not about projects help us with our development projects? Absolutely! ITIL can help us to assure the quality of the systems we develop by providing the basis for understanding the business need and taking action on that understanding. ITIL can be our foundation for project success by defining the context for our project and for the product we will build!

This article was Mr. Koch's regular column, "Connecting With Quality" in the 9 October 2006 issue of Project Connections.

Software Quality - Service Quality: What's the Difference? We have spent so many years talking about building high-quality software products that it is easy for us to lose sight of one very important fact: The software products that we build do not stand alone. They are only parts of the IT Services on which our customers depend to be able to do their jobs.

And what is the important message that we need to learn? It is that a high-quality application will not meet the needs of our customers if it exists in a context that is otherwise quality-challenged. And more importantly, we are unlikely to understand all of the quality attributes that are required of our software unless we examine them while considering the entirety of those IT Services. ITIL shows us how to do this.

This article was Mr. Koch's monthly column, "The Road To Quality" in the October 2006 issue of Configuration Management Journal.

Does Senior Management Really Care About Quality? "Sometimes", Bob mused, "It seems like senior management doesn't care about the quality of the systems we build. I wonder if they care about quality at all!"

"Oh, there is no question in my mind!" Sue assured him. "I know that they don't care. All they care about it hitting a schedule. They couldn't care less about how well the software works!"

Meanwhile, in the boardroom...

"What's wrong with your people?" the COO barked at the CIO. "They can never seem to deliver a system the works right. Between the bugs that have to be fixed and the difficulty that people have with figuring out how to use it, I wonder if we might be better off using pencil and paper!"

Any executive will tell you that they want (no, they need) high-quality software systems. And yet from the vantage point of those of us who are tasked with building those systems, the opposite can seem to be true. Why the disconnect? And what can we do about it?

This article was Mr. Koch's monthly column, "The Road To Quality" in the September 2006 issue of Configuration Management Journal.

Testing is NOT Quality Assurance When the Capability Maturity Model® first came out, it confused a lot of people. It had a Key Process Area (KPA) named "Software Quality Assurance," but that KPA didn't have the first thing to do with testing, or with peer reviews of technical artifacts. And those topics were addressed in KPAs that don't even mention Quality Assurance!

Wait a minute! What's going on here? Why is this getting so confusing?

It's confusing because we in the software industry have gotten into a bad habit of using the term "Quality Assurance" to refer to things like testing and technical reviews, which are actually Quality Control activities. We've been doing this for so long, and so consistently that most of us don't even know what true Quality Assurance is!

This article was Mr. Koch's regular column, "Connecting With Quality" in the 2 August 2006 issue of Project Connections.

High-Maturity Project Management We initiate, plan, execute, control, and close our projects. We manage our projects' human resources, integration, time, scope, quality, communications, cost, risk, and procurement. We are doing all of the things that the Project Management Body of Knowledge (PMBOK®) tells us to do. Now what? Have we reached the pinnacle of project management?

Hardly! We have laid the foundation of good project management practice. With this foundation in place, we are ready to embark on our journey toward excellence in project management. We are ready to move into the area that the Capability Maturity Model Integration (CMMI®) refers to as "higher maturity levels."

Quality is Not My Job Thank you, Henry Ford, for making the assembly line the driving force in business. It was so successful in manufacturing that we have adopted assembly line principles into many other domains, even software development! Although different software organizations split up the jobs in different ways, it is not uncommon (in fact, it is considered to be "best practice") to make a clear division between developers and testers.

Although this division of work makes a lot of sense from both a skills and an objectives point of view, it can lead to some counterproductive attitudes. Its most pernicious effect is the attitude that because the testers focus on quality, other people donŐt need to. "Our job as developers is to make it work. The TestersŐ job is to assure Quality!"

How can we combat the attitude that "Quality is not my job"?

This article was Mr. Koch's monthly column, "The Road to Quality" in the August 2006 issue of Configuration Management Journal.

No Risk of Defects!: Making Quality-Related Risks Actionable It never fails! While I am facilitating a Risk Planning workshop, one of the risks that a team member suggests during the brainstorming session is that there will be defects in the product. Later, when we are critiquing and consolidating the list, the team is surprised when I suggest that this one be dropped from the list!

The Project Management Body of Knowledge (PMBOK®) defines a risk as "an uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives." The key word for this discussion is "uncertain". Defects are a certainty, so this item does not belong on our risk list. In fact, we should be planning for the fact that there will be defects.

Does that mean that quality-related risks don't belong on our risk list? Not at all! There are many potential quality-related risks, but we must be much more specific if we are to make them an actionable part of our risk planning.

Making Quality Planning Concrete Most of what you do while planning a project is concrete. For example, there are specific objectives the project must meet, a list of tasks to do, explicit costs to consider, and contractual relationships to maintain.

But is a "soft" concept that it is difficult to think about it in concrete terms. This makes it harder to plan for than budgeting and scheduling. This challenge, comes from the difficulty in measuring quality with the same precision as other project variables.

Therefore, if you want to plan for and manage quality with the same focus as you do for budget and schedule, then you must learn to measure it with the same precision. And measuring quality is within your reach.

Quality That Is Worth the Cost How can I figure out if the QA work has real value to my project? Are we doing things that are valuable? Are we doing things that don't have value? Are we not doing things that would have value? How can I tell? It is true that QA activities do not produce any tangible products. The Cost of Quality (CoQ) is an overhead cost, and like any overhead cost, it should be minimized. But without a clear understanding of all of the things that should be counted, many organizations do the wrong things and actually end up increasing their total CoQ.

Quality may be an intangible, but that doesn't meant it has to be invisible. Here's how to manage quality by the numbers.

This article was Mr. Koch's regular column, "Connecting With Quality" in the June 5 2006 issue of Project Connections.

Negotiating the Triple Constraints We've all experienced it! "Here is what I need. I need it by the first of June, and it canŐt cost any more than this." The project Sponsor dictates Scope, Cost and Time and tells us that nothing is negotiable. That is what and when we must deliver, and "Oh, by the way, of course the quality must be good, too!"

The Project Management Body of Knowledge (PMBOK)(R) tells us that every project is governed by the "Triple Constraints" of Scope, Cost and Time, and that these three must be balanced with each other to achieve project success. But our project Sponsor either doesn't know about the Triple Constraints, or doesn't care. He or she gives us the mandate, and we are stuck with it!

Or are we?

The Risk of Regression But it was just a tiny little change! How could we have known it would cause such big problems?

How, indeed!

Regression (going backward) is a fact of life in software systems. Even though something worked before, there is no guarantee that it will work after the latest "minor" change. Yes, modular design and sound system architecture can limit the likelihood of unintended effects, but they won't eliminate them all together.

Regression testing will always be necessary. But with the very limited amount of time we have for testing a "minor" change, how can we do sufficient regression testing? How can we know where to look? How can we reduce the risk that there will be problems?

This article was Mr. Koch's monthly column, "The Road to Quality" in the June 2006 issue of Configuration Management Journal.

Testing vs. Quality Assurance What does your Quality Assurance group do?" I have asked many executives. And too often they answer, "QA is responsible for testing our software to ensure it is ready for release." "Anything else?" I push, hoping for more. But usually, the response is little more than, "Well, they manage the defect tracking system. What else would they do?"

What more, indeed!

Just as there is much more to Configuration Management than merely doing good version control, Quality Assurance goes far beyond mere testing. Indeed, I have seen companies where the QA group doesn't do testing at all! (That is the purview of the Testing, or Quality Control group.) Their QA groups are responsible for all of the other activities that are necessary to really assure quality.

Agility and Quality What is "Quality"? There are many competing definitions, mainly because the one that makes the most sense, "Quality is in the eye of the beholder," is hard to make workable in a real business situation. Some would say it is impossible to use. But the Agile methods beg to differ. The Agile methods take just such an approach to quality by letting the customer mould the quality of the product that is being built. They acknowledge that different people might see things in different ways, so the one party to the project whose opinion counts most (the ultimate customer) is the one to whom the Agile methods look.

What constitutes high quality on this project? Don't ask me! Ask your customer!

Placing the Quality Bet Most of us have heard the logic: Invest in quality early in the project, and it will pay back later. Specifically, if we take the time to do peer reviews of designs and code, we will save even more time during testing. But when it's time to plan a new project, there is always a reason why that logic just doesn't seem to apply. The schedule is too tight. The customer's demands are too large. The project team is not ready. Many things conspire together to convince us that although reviews are a good idea, we just can't afford to do them this time. Regardless of how compelling they seem to us, these "reasons" are illusions.

Expert columnist Alan Koch details where to find the time for reviews in your project schedule. (Hint: look under "testing.")

This article was Mr. Koch's regular column, "Connecting With Quality" in the April 11 2006 issue of Project Connections.

High-Quality Processes All of us can think of examples of bad processes. They seem to be indelibly burned into our memories. But it may be hard to think of what a high-quality process looks like, because it seems like we've never seen one. Of course, that's not really true. All of us have experienced good processes -- they are the ones that were invisible! Processes that are helpful, efficient and effective also seem to disappear into the background. Unless something draws our attention to them, we may not notice them at all!

So, what is it that makes a process "high-quality"? And what is it about high-quality processes that makes them invisible? There are actually a variety of attributes that all must be present in order for a process to be truly good. We will discuss each of them in this column. The sum total of those attributes is that the process helps people to do their jobs well without getting in the way.

Adopting an Agile Method The argument has been made: "We should be using an Agile software development method." And the command has rung out: "Make it so!" Now what do you do? How do you take that one-line "requirement", and make it so?

Adopting an Agile method is no different from any other change we might make to the methods and tools we use. We must determine why we are embarking on this course, choose the method that will satisfy the need most closely, then map out the path from where we are today to where we need to be. Then we can "make it so".

We Cannot Trade Quality for Budget or Schedule It is not uncommon for people to say, "Fast, cheap, or good; choose two." Most people interpret this to mean that if you want a short schedule and a low budget, you must sacrifice quality. And the corollary is that if you want quality, you must expect a longer schedule or higher costs.

But "quality" is not one of the "Triple Constraints"! The PMBOK teaches us that every project must balance time, cost and scope. When budget and schedule are constrained, it is scope that must be given up, not quality! And it is increasing scope (not quality) that increases costs or schedules.

Help! The Testers Want to Break the Bank! I analyzed the project, I figured out what needs to be done, and I laid out an aggressive but achievable schedule. And then the testers cried "foul!" They tell me that they need three times as much time to ensure a quality product, and that the project is doomed to failure if their demands are denied.

Their claims sound like hyperbole to me, but how can I know? They are the experts in testing! Am I really stuck with a choice between delivering late and delivering poor quality? How can I make the best decision for the project?

This article was Mr. Koch's regular column, "Connecting With Quality" in the 2 February 2006 issue of Project Connections.

Affordable Peer Reviews Many people know that peer reviews can help them to produce better-quality products. But most organizations do not use this potent tool. Why? Because although they would like to experience the quality benefits, they can't justify the costs they would incur.

But peer reviews need not be an expensive proposition. In fact, the right methods can pay back more than they cost. How can we do this? We can do it by ensuring that peer reviews are focused on finding the kinds of defects that are difficult and much more expensive to find using other methods.

This article was Mr. Koch's monthly column, "The Road to Quality" in the February 2006 issue of Configuration Management Journal.

High-Quality Unit Tests Most software developers are not good at unit testing. This is not surprising for many reasons. First, they have generally never been trained in how to do it. Then there is the fact that they would rather be writing new code than testing what they already wrote. And of course, we must consider that most programmers are not judged on the testing they do.

However, if we look at all of the reasons for programmers' reluctance to focus on unit testing, it becomes evident that these reasons feed on each other. Who likes to do something he has never learned to do well? And who wants to invest the effort to learn to do something she is not judged on? When our programmers' jobs are to "write code", why would we expect that they would work at being good testers?

This article was Mr. Koch's regular column, "Connecting With Quality" in the 8 December 2005 issue of Project Connections.

Establishing Unit Test Criteria It is time for a new build. What should be included in it? Obviously, it should include the latest and greatest versions of each module. Right?

The phrase "latest and greatest" belies an assumption that the latest version of something is automatically the greatest. The latest version adds features, corrects problems, and in short, improves on the versions that preceded it. How could it be anything other than the greatest?

But, in fact, things are often not as great as they seem to be. Those new features may be incompatible with other existing functionality. Things that the users relied upon may have disappeared. The new features may impair usability (especially for novice users). And then there are the bugs that invariably crop up in all of that new and changed code.

This article was Mr. Koch's monthly column, "The Road to Quality" in the November 2005 issue of Configuration Management Journal.

Partnership For Success No one wants to deliver a poor-quality product. But our projects often seem like a struggle between the Quality Assurance personnel and those who have other jobs. Do some people really not care about quality? If that is not the case, then why does it so often seem that way?

How can we get all of the players on our projects to work together? How can we change our mode of operation from that of warring factions into that of a partnership for success? The key is to be sure that we all understand the meaning of "success"! Only then will we be able to work together to achieve it.

This article was Mr. Koch's monthly column, "The Road to Quality" in the October 2005 issue of Configuration Management Journal.

Planning For Quality With all of the things we must worry about while planning a project, it is easy to miss the one thing that everyone expects so automatically that it goes without saying: Quality! The customer, management, even the development team expects that the software we produce will be "good" quality. But without proper attention to defining what we mean by "good" and then planning for it, achieving the levels of quality we need is far from assured.

This article was Mr. Koch's regular column, "Quality Connections" in the October 2005 issue of Project Connections.

People, Processes and Tools Part 1: The People Premium
Republished by ONESIXSIGMA Banner 		Every project is dependent upon people, processes and tools. They are how the work gets done. But these three essential elements are not equal. Each has its own strengths and weaknesses, and provides a different value to our projects.

This three-part series explores the relative value of people, of process, and of tools. We will look at the strengths of each, their weaknesses, and how they provide value to our projects. Is one of the three more important than the others? We will see, as we investigate people, processes, and tools.

People, Processes and Tools Part 2: Processes For People
Republished by ONESIXSIGMA Banner 		Good processes mitigate people's shortcomings while freeing them up to do what they do best on projects -- think, create, improvise. The best processes don't create extra work. Instead, they serve specific purposes, ensure efficiency and consistency, and tend to become "invisible" to those who use them.

This is the second article in a three-part series exploring the relative project value of people, process and tools. The first installment, "The People Premium" discussed the attributes of people that make them indispensable to project work, but can also cause problems. This article looks at the role of processes in compensating for human shortcomings.

People, Processes and Tools Part 3: The Role of Tools
Republished by ONESIXSIGMA Banner 		On the best-run projects, people provide the creativity and intellect, while processes help ensure consistency and efficiency without getting in the way. Striking the right balance between the two can be a powerful combination. And supporting tools, adopted wisely, can make both people and processes even better.

This is the final article in a three-part series exploring the relative project value of people, process and tools. The first installment, "The People Premium" discussed the attributes of people that make them indispensable to project work, but can also cause problems. The second article, "Processes for People" looked at the role of processes in compensating for human shortcomings. This final installment explores the role of tools in making people and the processes that support them more efficient.

A High-Quality Plan What does it take to produce a high-quality product? A clear understanding of the customers' needs? Of course! Solid engineering work? Yes! Intensive testing? Naturally! Consistent practices? You bet! A committed, cohesive team? Without a doubt! Anything else?

What about good plans? Do they affect the quality of the products you produce? Absolutely! Although it may not be obvious at first glance, the quality of your plans is one of the primary drivers of the quality of the products your project produces. Let's take a look at some examples of plans contributing to the quality of projects' products--or the lack thereof!

This article was Mr. Koch's monthly column, "The Road to Quality" in the September 2005 issue of Configuration Management Journal.

Tool Choice as a Quality Issue We need to choose an SCM tool. It will mean some work to make the choice, and then more work to put it into practice. But at least we don't have to worry about it from a quality perspective. After all, the tools we choose to employ don't affect the quality of the software we produce.

Right?

Do they?

Well, let's think about this a bit. Hmmmmmm...

This article was Mr. Koch's monthly column, "The Road to Quality" in the August 2005 issue of Configuration Management Journal.

Consistent Quality Requires Consistent Processes Why is it that a business can do so well some of the time, and mess up so badly at other times? Inconsistency in quality--of food, of service, of products, of software--of anything is almost always caused by inconsistency in the way those things are done. Both the traditional plan-based CMMI, and the new Agile methods agree that consistency in the way processes are used is so important that a proactive approach is necessary to ensure that consistency is there.

This article was Mr. Koch's monthly column, "The Road to Quality" in the July 2005 issue of Configuration Management Journal.

Quality is Conformance OF Requirements What is your definition of "quality"? We in the software industry prefer to measure quality in terms of conformance to requirements. But there is one very large and glaring problem with defining quality in terms of the specification. Anything that people produce may be defective, and that includes the specifications that they write. And if the specification is wrong, then how can we say that a system that conforms to it is "high-quality"?

This article was Mr. Koch's monthly column, "Connecting with Quality" in the August 2005 issue of Project Connections E-zine.

Yes, You Can Review Your Own Work! In last month's column, "Reducing Your Cost of Quality", I listed "Structured Personal Reviews" as being a highly effective appraisal method. This resulted in e-mails from multiple people asking me about that topic. So this month, I explain what I mean by this term, and explain how you can make your reviews effective.

This article was Mr. Koch's monthly column, "The Road to Quality" in the June 2005 issue of Configuration Management Journal.

Building High-Quality Software: Building a Culture of Quality When there is a quality problem with our products, where do we look to solve it? If we look to Quality Assurance, we will be disappointed. QA can measure the problem, and maybe even identify possible causes. But they cannot add quality to our products.

Quality must be built into our products; it can never be tested in after the fact. Although QA has an important role in assuring the quality of our products, their work is entirely indirect. Their role is to influence others in the organization. It is those other people who will build quality into our products. (Or not.)

Read this article at
StickyMinds.com Scroll down to Date Posted: Jun 1 2005
ProjectConnections.com
ITtoolbox.com

Reducing Your Cost of Quality How high is your Cost of Quality? The answer might surprise you. Yes, it includes reviews, the QA infrastructure, and preparing testsŃthose are your "Appraisal Costs". But how high are your "Failure Costs"-the cost of defects?

Your engineers spend time in diagnosis and rework, development schedules slip, support costs climb, and your company's and products' reputations sink. These Failure Costs, which are the more significant Cost of Quality, are beyond your direct control. But you can gain control over them indirectly, by investing in Appraisal Costs that minimize Failure Costs, reducing your total Cost of Quality and making it more predictable.

This article was Mr. Koch's monthly column, "The Road to Quality" in the May 2005 issue of Configuration Management Journal.

Also read this article at ProjectConnections.com

CMM® and CMMI®: Show Me the Value!

Select Your Category:Project Management & Professional Skills

Download the PDF file, "CMM and CMMI: Show Me the Value!"

Most organizations seek a rating against the Capability Maturity Model (CMM) or Capability Maturity Model Integration (CMMI) because their customers require it of them. But what about the majority of us for whom no such requirement exists? Is there any value in the CMM? Is there any reason why we should pay attention to what the CMMI says?

In two words, Yes, and Yes!

The Software Engineering Institute (SEI) created the CMM as a result of research into organizations that had proven to be successful in delivering quality software on time and within budget. They sought to find out what it was that differentiated these successful organizations from the majority who were inconsistent in their results, or were just plain failures. The CMM documents the attributes of these successful organizationsŃattributes that any organization can adopt. In addition, it lays these important attributes out on a path of increasing maturity that any organization can follow if it wants to join the ranks of the successful.

The CMM is designed to be a roadmap to successful software and systems development. Organizations that use it as a guide to process improvement can expect to reap significant rewards.

This white paper wass published by Global Knowledge Networks, Inc.

TSP Can Be the Building Blocks for CMMI Your organization has a mandate to achieve Capability Maturity Model® Integration (CMMI®) Level 3. Why would you even consider adding the Team Software ProcessSM (TSPSM) to your plate when it is already overflowing? In this article, I will discuss how TSP - far from adding work to a CMMI initiative - can potentially reduce the time and effort that will be required to achieve your goals. Simultaneously, TSP will engage your engineers in disciplined processes, giving them an appreciation for good processes along with the desire to adopt improved processes in every area of the organization.

This article is published in the March 2005 issue of CrossTalk, the Journal of Defense Software Engineering.

Using Earned Value, Part 1: Planning Software Projects We've all experienced it too often. The first 90% of the project takes 90% of the time, and the last 10% of the project takes 90% of the time again. How can 90% of our projects be 90% complete 90% of the time? This happens because we use planning and tracking methods that allow far too much subjectivity.

Earned Value is a project planning and tracking method that removes much of the subjectivity from the process.

In this first article (of two), we will discuss the principles behind Earned Value planning and tracking, and learn how to create an Earned Value plan for a software project.

In the second article, we will learn how to track status against that plan, and how to handle problems like accounting for unplanned tasks.

Using Earned Value, Part 2: Tracking Software Projects We've all experienced it too often. The first 90% of the project takes 90% of the time, and the last 10% of the project takes 90% of the time again. How can 90% of our projects be 90% complete 90% of the time? This happens because we use planning and tracking methods that allow far too much subjectivity.

Earned Value is a project planning and tracking method that removes much of the subjectivity from the process.

In the first article, we discussed the principles behind Earned Value planning and tracking, and learned how to create an Earned Value plan for a software project.

In this second article (of two), we will learn how to track status against that plan, and how to handle problems like accounting for unplanned tasks.

Software Quality Data, Part 1: Basic and Derived Metrics We measure, quantify and report on software quality. But can we control it? Can we actually assure quality (as opposed to just measuring it)? This is the first of three papers in which we will learn how we can go beyond just quantifying the quality of the software after it has been built.

In this "Part 1 Basic and Derived Metrics", we will discuss:

  • The three basic metrics from which the most important quality measures can be derived (Defects, Effort, and Size).
  • Several important metrics that can be derived from those basic three:
    • Defect Injection Rate
    • Defect Removal Yield
    • Defect Removal Efficiency
    • Review Rate

In "Part 2: Quantitative Quality Planning", we will look at how to use this information to produce a Quality Plan that we can use to understand our quality performance before the project is complete.

Finally, in "Part 3: Quality Control Using In-Process Data" we will discuss how to use our Quality Plan and the data we are collecting to actually control the quality of the software we are producing.

Software Quality Data, Part 2: Quantitative Quality Planning We measure, quantify and report on software quality. But can we control it? Can we actually assure quality (as opposed to just measuring it)? This is the second of three articles in which we will learn how we can go beyond just quantifying the quality of the software after it has been built.

In "Part 1 Basic and Derived Metrics", we discussed the three basic metrics of software quality and four important metrics that can be derived from those basic three.

In this "Part 2: Quantitative Quality Planning", we will look at

  • Benchmark data for the measures discussed in Part 1, and
  • How to use this information to produce a quantitative Quality Plan that we can use to understand our quality performance before the project is complete.
    • Setting Quality Objectives we can check status against,
    • Establishing size estimates for the products to be produced, and
    • Determining the Defect Removal activities that will help us to reach our objectives.

Finally, in "Part 3: Quality Control Using In-Process Data" we will discuss how to use our Quality Plan and the data we are collecting to actually control the quality of the software we are producing.

Software Quality Data, Part 3: Quality Control Using In-Process Data We measure, quantify and report on software quality. But can we control it? Can we actually assure quality (as opposed to just measuring it)? This is the third of three papers in which we will learn how we can go beyond just quantifying the quality of the software after it has been built.

In "Part 1 Basic and Derived Metrics", we discussed the three basic metrics of software quality and four important metrics that can be derived from those basic three.

In "Part 2: Quantitative Quality Planning", we looked at how to use this information to produce a Quality Plan that we can use to understand our quality performance before the project is complete.

Now, in "Part 3: Quality Control Using In-Process Data" we will discuss:

  • Using in-process metrics to track against our quaity plan, and
  • Taking corrective action when the in-process data suggest it.
Reducing Your Cost of Quality How high is your Cost of Quality? The answer might surprise you. Yes, it includes doing reviews, maintaining the QA infrastructure, preparing tests, and so forth - those are called your "Appraisal Costs". But how high are your "Failure Costs"? ... the costs that you incur every time a defect in your software comes to light?

How badly is your budget busted by the effort your engineers spend diagnosing and fixing defects, both during testing and after release? How badly does your development schedule slip because of the constant parade of defects turned up during testing? How costly is it to provide support for your customers as they deal with the defects that you shipped to them? And what effect do those cost, schedule and support issues have on your product's reputation in the marketplace?

Clearly, your Failure Costs are your more significant Costs of Quality, but how can you gain control over them? Although your Failure Costs are beyond your direct control, you can gain control over them indirectly through your Appraisal activities. By focusing on activities that remove defects most effectively, you can reduce your total Cost of Quality, making your budget better, your schedule stable, your customers cheerful, and your market magnificent.

CMM®-Compliant XP Extreme Programming (XP) and the other "Agile Methods" have recently burst onto the scene, and many people are talking and asking lots of questions. Those questions take many forms, but in some organizations, they include, "Should we do XP? Or CMM?" This question seems natural, since XP and CMM appear to be incompatible.
  • Light vs. Rigorous
  • People-oriented vs. process-centric
  • Change-embracing vs. change-controlling
  • Barely-adequate process vs. Repeatable, Defined, Managed and Optimizing process
  • 12 practices vs. 368 Key Practices
But incompatibility need not be a foregone conclusion. The proponents of XP readily acknowledge that it is not appropriate for every project. In fact, they recommend XP for a very specific subset of projects, those that are small and exploratory in nature. At the same time, the CMM recognizes that different projects may require different processes. An OrganizationŐs Standard Software Process (OSSP) may, in fact be a suite of options, in which case, establishing a ProjectŐs Defined Software Process would involve choosing from among those options. (Refer to the Level 3 KPAs OPD and ISM for more information.)

Interestingly, the types of projects for which XP was designed, are precisely the ones with which organizations engaged in CMM-based process improvement programs have the most trouble. These "odd" projects are too small, too fast moving, and the results are too ill defined for the "normal" processes. But at the same time, we recognize that careful management is as important with these innovative projects as with any other.

So, could XP be one of the available options in your OSSP? No, and Yes. XP, as defined "out of the box" does not satisfy a number of the Goals of the CMM. However, with a few minor extensions, it can be made goal-compliant without sacrificing most of its "agility".

XP--An Overview Extreme Programming (XP) and the other "Agile Methods" have recently burst onto the scene, and many people are talking and asking lots of questions. This article is designed for the uninitiated, to provide a minimal understanding of XP. It provides the basic understanding of XP you may need to understand the other articles on this web site that discuss XP.
Evolving an Engineering Process for Software While communication is necessary to the success of IT projects, it is certainly not sufficient. In order for communication to be effective, it must involve the right parties and be based on a vocabulary that all of those parties understand. The most critical communication is between the technicians and the business people, and the engineering process itself provides the basis and vocabulary for that communication.
PSP/TSPSM Reported Data This is a compilation of data that has been reported by the SEI and various commercial companies. The data quantify the positive impact of the Personal Software Process and Team Software Process (PSP/TSP) on such measures as the quality of delivered software, programmer productivity, and the accuracy of project estimates. Several of the companies also report on intangible benefits.
Developing Developers Software development companies are just starting to understand what sports teams have known for years. It pays to have a coach. This article describes what coaching involves, and the benefits that comapnies have realized from capitalizing on this simple concept. This article was published in the 24 August 2001 Pittsburgh Business Times.
Process Definition in Web-Time This experience report focuses on the initial process definition work that Alan S. Koch helped a young Internet company to get started on. It chronicles the steps we took to get a quick start on the process definition they so desperately needed, and how we were able to achieve usable improvements in a relatively short time. It discusses the challenges we faced and the things we did that helped the project along.

This paper was written for the 2001 Quality Assurance Insititute conference as a companion to a presentation of the same name.

Can We Afford Software Process? In small entrepreneurial companies, the most critical things are speed and flexibility. We must be able to move quickly, react to both opportunities and threats, and make new product available to customers on a regular basis. In an environment like this, can we afford to spend the time to focus on developing and improving our software development processes? And can we afford the overhead involved in following well-defined processes?

A better question would be: Can we afford not to address our software development processes?

"A" is for "Assurance" How can we truly assure quality? In this article we will explore the various dimensions of software quality (e.g. Usability, Maintainability, Lack of Defects) and identify the variety of actions that are necessary to truly assuring each dimension of quality.

This paper was written for the 1998 Practical Software Quality Techniques conference as a companion to a presentation of the same name.