Ask Process
  Resources   »   Articles    

Agile Textbook

Download the Supporting Workbook

Free Article Directory

Search the Website

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.

 

Didn't Find What You Need? Search the website...

 
 
 
Topics: Recent, All, Agile, ConfigMgmt, ITIL®, Management, Metrics, Planning, Process, Quality, Requirements, Risk, Standards  
 
 
  All Articles    

"A" is for "Assurance"
Topic: Quality   •   Date Published: 2003
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.

Adopting an Agile Method
This article is also published on Methods and Tools.
Topic: Agile, Process   •   Date Published: Spring 2006

The argument has been made: "We should be using an Agile software development method." And the command has rung out: "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".

Affordable Peer Reviews
This article is also published on CM Crossroads.
Topic: Quality, Metrics, Planning   •   Date Published: 14 Feb 2006
Many people know that peer reviews can help them to produce better-quality products. But most organizations do not use this potent tool because they can't justify the costs they would incur. But we can do Peer Reviews that pay back more than they cost by ensuring that they are focused on finding the kinds of defects that are difficult and much more expensive to find using other methods.

The Agile Customer:
Making Your Supplier a Bit More Agile

This article is also published on Project Connections.
Topic: Agile, Management   •   Date Published: 31 Mar 2010

"We are adopting an Agile method for our internal development projects. But on my project, some of the development work is being done by an outside contractor who is decidedly non-Agile! How can we be Agile when they are not?" Agility is relatively easy when you control all of the parts of the project. But when others are involved, barriers to Agility can begin to spring up. The best way to overcome those barriers depends upon your situation. So let's explore options for injecting some Agility in spite of the Waterfall raining down on you from your supplier.

"Agile" Means Disciplined SCM (Software Configuration Management)
This article is also published on CM Crossroads.
Topic: Agile, ConfigMgmt   •   Date Published: 19 May 2010

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.

Agility and Quality
This article is also published on CM Crossroads.
Topic: Agile, Quality   •   Date Published: 12 Apr 2006

What constitutes high quality on this project? Don't ask me! Ask your customer! 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.

Assuring Quality: Beyond Testing & Reviews
This article is also published on CM Crossroads.
Topic: Quality, Metrics   •   Date Published: 19 Feb 2007

There is much more to QA than testing and reviews. In fact, testing and reviews don't 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.

Audit Trails, Traceability Because Sometimes Things Go Wrong: (And no, they are not to place the blame!)
This article is also published on CM Crossroads.
Topic: ConfigMgmt, Risk   •   Date Published: 20 Aug 2007
Any time we make a change to production, there is the risk that something will go wrong. 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.

Blurring the Line Between Dev & QA
This article is also published on Project Connections.
Topic: Management, Quality   •   Date Published: 25 Oct 2010

What's the difference between development and QA? It's been decades since we began distinguishing between these two project roles, and in most organizations the fact that they are necessary and distinct from each other is taken as an article of faith. But new voices have arisen in recent years. Most of them do not suggest that we go back to the 1960s, but they do raise interesting questions about the Dev/QA dichotomy. How well has the traditional structure worked? What dysfunctions are crying out to be addressed? Can we make our projects more effective by re-thinking these two roles and how they relate to each other?

Build Quality In: The Agile Methods are right!
This article is also published on CM Crossroads.
Topic: Agile, Quality   •   Date Published: 25 Nov 2007
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. What differentiates those organizations 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".

Building High-Quality Software: Building a Culture of Quality
This article is also published on Sticky Minds and on IT Toolbox.
Topic: Quality   •   Date Published: 6 Jun 2005

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.)

Can We Afford Software Process?
Topic: Process   •   Date Published: 2003
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?

Change Management is not Change Control
This article is also published on CM Crossroads.
Topic: ConfigMgmt   •   Date Published: 20 Aug 2009

A key part of planning configuration management for our projects is determining how we will manage change. After all, "change happens", and any good configuration manager is concerned with how it is managed. Unfortunately, more often than not, our processes focus more on controlling change than on managing it! That is, we put a lot of effort into trying to keep change from happening, and relatively less effort into ensuring that when (not if, but when) change happens, we manage it effectively.

CMM® and CMMI®: Show Me the Value!
Topic: Process   •   Date Published: 2005
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!

CMM®-Compliant XP
Topic: Agile, Process   •   Date Published: 2003
"Should we do XP? Or CMM?" Although XP and CMM appear to be incompatible, they need not be. CMM recognizes that different projects may require different processes. 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. So, could XP be one of the available options in your CMM toolkit? No, and Yes.

Consistent Quality Requires Consistent Processes
This article is also published on CM Crossroads.
Topic: Quality, Process   •   Date Published: 18 Jul 2005

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.

The Definition of "Done"
This article is also published on CM Crossroads.
Topic: Standards   •   Date Published: 17 Dec 2007

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.

Developing Developers
This article is published on Pittsburgh Business Times.
Topic: Process   •   Date Published: 27 Aug 2001

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.

Did That Process Change Work?: Four Steps to Better Processes
This article is also published on Project Connections.
Topic: Process, Metrics   •   Date Published: 25 Sep 2007

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 only the first step. The real work follows that step. And that real work is what must be carefully managed--and carefully measured!

Does Senior Management Really Care About Quality?
This article is also published on CM Crossroads.
Topic: Quality, Planning   •   Date Published: 20 Sep 2006

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?

Employee Recognition in an Agile Team
This article is also published on Project Connections.
Topic: Agile, Management   •   Date Published: 3 Sep 2009

Fred sent me this question: "I've read that recognition (in whatever form is most valued to the individual) is an important motivator. In the context of Agile team dynamics, I'm guessing that individual recognition could be counterproductive to everyone working well together, but recognition would be a better motivator if it were directed toward the entire team rather than just to a few individuals on the team that stood out. What do you think?"

The Agile methods are designed to make the work environment itself a motivator for the team members. But well-placed recognition can be a powerful addition – if it is done in an Agile way!

The Essence of Agility Series

Part 1: Learning & Adaptation, and Collaboration
This article is also published on Project Connections.
Topic: Agile   •   Date Published: 21 Feb 2008

The Agile approach is often panned as an excuse for lack of discipline. This shows that many people don't understand what Agility is all about. 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 some 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.

Part 2: Customer Focus
This article is also published on Project Connections.
Topic: Agile, Requirements   •   Date Published: 1 May 2008

Is the team 'Agile,' as they claim? This time, we will focus on how the team relates to their customer. It is all about our customer. All! 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.

Part 3: Small Self-Directed Teams
This article is also published on Project Connections.
Topic: Agile   •   Date Published: 18 Sep 2008

The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers who are claiming to be Agile. They are the markers that any concerned stakeholder can use to answer an important question, "Are they being Agile? Or just lazy?" In this article, I will address the next key characteristic: Small, self-directed teams.

Part 4: Embracing Lean Principles
This article is also published on Project Connections.
Topic: Agile   •   Date Published: 24 Nov 2008

The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile. They are the markers that any concerned stakeholder can use to answer an important question: "Are they being Agile, or just lazy?" In this article, I will address the next key characteristic: Embracing Lean principles.

Part 5: Progressive Requirements Elaboration
This article is also published on Project Connections.
Topic: Agile, Requirements   •   Date Published: 5 Feb 2009
They say that they are "Agile", but it just looks like hacking to you. How can you tell? The Essence of Agility consists of those sets of behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile. In this article, I will address the next key characteristic: Progressive Requirements Elaboration.

Part 6: Incremental Delivery
This article is also published on Project Connections.
Topic: Agile   •   Date Published: 16 Apr 2009

When developers claim that they are "Agile," how can you know that they're not just hacking? Their methods are unorthodox, even weird! Is there a way to see if they know what they are doing? The Essence of Agility consists of those sets of observable behaviors that distinguish a truly Agile team from a bunch of hackers claiming to be Agile. In this article, I will address the next key characteristic: Incremental Delivery.

Part 7: Iterative Planning
This article is also published on Project Connections.
Topic: Agile, Planning   •   Date Published: 25 Jun 2009

Is it Agile? Or is it lack of discipline? How can we know for sure? The Essence of Agility consists of those sets of observable behaviors that distinguish a truly Agile team from a bunch of undisciplined programmers. In this last article of the series, I will address the final key characteristic: Iterative Planning.

Establishing Unit Test Criteria
This article is also published on CM Crossroads.
Topic: Quality   •   Date Published: 16 Nov 2005

The phrase "latest and greatest" belies an assumption that the latest version of something is automatically the greatest. The latest version 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.

Evolving an Engineering Process for Software
Topic: Process   •   Date Published: 2003
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.

Expecting Easy Integration
Topic: Quality, ConfigMgmt   •   Date Published: Feb 2009
My biggest Configuration Management mistake was in being overly optimistic! And I should know better -- I've been in Quality for a lot of years! I know that things never go as we plan and expect them to when we are integrating software. So why did I think that things would be any different when I was teaching a college class?

Fix It Fast vs. Fix It Right
This article is also published on Project Connections.
Topic: ITIL®, Management   •   Date Published: 13 Nov 2009

They were already doing Root Cause Analysis (RCA), but they were failing to get any real benefit from it. The heart of the problem with their RCA process lies in the fact they were mixing and confusing the two distinct and different ways that you can respond to any problem that comes along: 1) fix it fast, or 2) fix it right. They were trying to do both of them at the same time, which often isn't possible. They learned how to fix things fast, and so the "fix it right" part of the equation kept failing, even though they were trying to make it work. A deliberate Root Cause Analysis process will help them get to the bottom of a problem and fix it permanently, not just quickly.

Help! The Testers Want to Break the Bank!
This article is also published on Project Connections.
Topic: Quality, Planning   •   Date Published: 2 Feb 2006

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?

High-Maturity Project Management
This article is also published on Global Knowledge.
Topic: Management   •   Date Published: 17 Aug 2006

We are doing all of the things that the Project Management Body of Knowledge (PMBOK®) tells us to do. 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."

A High-Quality Plan
This article is also published on CM Crossroads.
Topic: Quality, Planning   •   Date Published: 20 Sep 2005

Do good plans 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!

High-Quality Processes
This article is also published on CM Crossroads.
Topic: Process   •   Date Published: 15 Mar 2006

All of us can think of examples of bad processes. But it may be hard to think of what a high-quality process looks like because they are the ones that were invisible! So, what is it that makes a process "high-quality"? And what is it about high-quality processes that makes them invisible? They are the processes that help people to do their jobs well without getting in the way.

High-Quality Unit Tests
This article is also published on Project Connections.
Topic: Quality   •   Date Published: 8 Dec 2005

Most software developers are not good at unit testing. This is not surprising for many reasons. 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?

How Much Quality Can We Afford?
Improving our Cost of Quality

This article is also published on Project Connections.
Topic: Management, Quality   •   Date Published: 1 Jun 2010

Sure, it might be nice to build a higher quality product. But how much quality can we really afford? Well, let's break out our Cost of Quality Calculator and try out the numbers.

How to Estimate Program Size
Cost of Quality Redux

This article is also published on Project Connections.
Topic: Metrics, Planning   •   Date Published: 12 Aug 2010

In my last article on Cost of Quality, I started out by blithely stating, "Let's say we're going to write a system of 25,000 Lines of Code." Teri (a perceptive reader) called me on it! She wrote, "If a new system is built, how do you guess at how many lines of code there will be? You possibly can guess at the number of programs from looking at the requirements but how do you guess the amount of lines involved for each program?" It's an important question, and doesn't have a quick and easy answer. This was what I told Teri.

In Search of the Elusive "Best Practice"
This article is also published on CM Crossroads.
Topic: Process, Standards   •   Date Published: 21 Apr 2010

A friend and fellow consultant has been known to react quite strongly to the phrase "Best Practice". "There is NO such thing as 'best practice'!" James will inform you in his not-so gentle manner. "There are only good practices that are appropriate under certain circumstances!" While I tend not to be as adamant as James, I certainly agree with his thesis. You can't assume something will work for you just because it works well for someone else.

Investing in Quality: When is "Enough" Enough?
This article is also published on Project Connections.
Topic: Quality, Planning, Metrics   •   Date Published: 27 Feb 2007

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!) The information you need to make good quality investments 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 decisions this time around.

Is Your Metrics Database Write-Only?
This article is also published on CM Crossroads.
Topic: Metrics   •   Date Published: 19 Mar 2007

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. 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!

ITIL®: A Foundation for Project Success
This article is also published on Project Connections.
Topic: ITIL, Management, Requirements, Quality   •   Date Published: 9 Oct 2006

At its heart, quality is a matter of meeting the business need. Can the Information Technology Infrastructure Library (ITIL®) -- a process model for IT Service Management -- 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!

ITIL® – Why Should I Care?
This article is also published on Project Connections.
Topic: ITIL, Management   •   Date Published: 27 May 2011

ITIL (the Information Technology Infrastructure Library) is a framework of good practice in IT Service Management. You needn't look far to find articles and presentations that explain ITIL. But those explanations may leave you with many more questions. Cinda Voegtli, CEO and Founder of Project Connections engaged in a long-distance conversation with me about this. We invite you to listen in.

Lessons Learned: Its Not Just a Good Idea...
This article is also published on Global Knowledge.
Topic: Management   •   Date Published: 25 Sep 2007

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?"

Making Quality Planning Concrete
This article is also published on Global Knowledge.
Topic: Planning, Quality, Metrics   •   Date Published: Jun 2006

Most of what you do while planning a project is concrete. But Quality is a "soft" concept that it is difficult to think about it in concrete terms. This makes it harder to plan for than the budget or schedule. 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.

Meeting Customer Requirements: First Time, Every Time Using TQM
This article is published on the James A Ward & Associates website.
Topic: Requirements, Process   •   Date Published: Summer 1994
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!

Negotiating the Triple Constraints
This article is also published on Global Knowledge.
Topic: Management   •   Date Published: 14 Jun 2006

"Here is what I need. I need it by the first of June, and it can't cost any more than this." The Project Management Body of Knowledge (PMBOK®) 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?

No Risk of Defects!: Making Quality-Related Risks Actionable
This article is also published on Global Knowledge.
Topic: Risk, Quality   •   Date Published: 19 Jul 2006

A risk is defined 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 they do not belong on our risk list. 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.

The One Right Way to Achieve High Quality Requirements
This article is also published on CM Crossroads.
Topic: Requirements   •   Date Published: 16 Sep 2007

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. 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.

Partnership For Success
This article is also published on CM Crossroads.
Topic: Quality   •   Date Published: 17 Oct 2005

Our projects often seem like a struggle between the Quality Assurance personnel and those who have other jobs. 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"!

People, Processes and Tools Series

These articles were re-published on CM Crossroads.

Part 1: The People Premium
This article is also published on Projects at Work,
and Improvement and Innovation .
Topic: Process   •   Date Published: 17 Jun 2009

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. We begin with the primary one of the three, People.

Part 2: Processes For People
This article is also published on Projects at Work,
and Improvement and Innovation .
Topic: Process   •   Date Published: 17 Jun 2009

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.

Part 3: The Role of Tools
This article is also published on Projects at Work,
and Improvement and Innovation .
Topic: Process   •   Date Published: 17 Jun 2009

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 final installment explores the role of tools in making people and the processes that support them more efficient.

Personal Quality Management With the Personal Software Process
This article is also published on Methods and Tools.
Topic: Quality, Process   •   Date Published: Summer 2007

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.

Placing the Quality Bet
This article is also published on Project Connections.
Topic: Quality, Planning   •   Date Published: 11 Apr 2006

Most of us have heard the logic: Invest in quality early in the project, and it will pay back later. But when it's time to plan a new project, there is always a reason why that logic just doesn't seem to apply. Regardless of how compelling they seem to us, these "reasons" are illusions. Let's look at where to find the time for reviews in your project schedule. (Hint: look under "testing.")

Planning For Quality
This article is also published on Project Connections.
Topic: Quality, Planning, Metrics   •   Date Published: 11 Oct 2005

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.

PM Network: Feedback: Agile Experience
This article was published in PM Network Magazine.
Topic: Agile   •   Date Published: Feb 2008

While this may have been intended as a humorous piece, it belies (and supports) 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.

PM Network: Feedback: Dilbert Isn't Real
This article was published in PM Network Magazine.
Topic: Management   •   Date Published: Feb 2008

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. ... 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.

Process Definition in Web-Time
Topic: Process   •   Date Published: 2003

This experience report focuses on the initial process definition work that ASK Process, Inc. 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.

Project Quality Management Series

Part 1: Quality Planning, What is "Good Enough"?
This article is also published on Global Knowledge.
Topic: Quality, Planning, Metrics  
Date Published: 13 Dec 2006

The PMBOK ® Guide makes Quality Planning sound simple enough. But for many of us, the relevant quality standards are not immediately obvious. 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"? and (2) How can we ensure that our product will be "good enough"?

Part 2: Quality Assurance, Gettin' Better
This article is also published on Global Knowledge.
Topic: Quality, Metrics   •   Date Published: 14 Feb 2007

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.

Part 3: Quality Control, Ensuring "Good Enough"
This article is also published on Global Knowledge.
Topic: Quality, Metrics, Management   •   Date Published: 15 Mar 2007

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.

PSP/TSPSM Reported Data
Topic: Quality, Metrics, Process   •   Date Published: 2003
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.

The QA Catchall
This article is also published on Better Software Magazine - Sticky Minds.
Topic: Quality   •   Date Published: May 2007

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. My talk resulted in frustration for many audience members 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.

Quality = Business Value Series

Part 1: Why common definitions of Quality fall short
This article is also published on Project Connections.
Topic: Quality   •   Date Published: 3 Jan 2011

"Quality" is one of those words that is used all the time, but rarely defined. We are supposed to produce "quality" products, but the precise meaning of that mandate is left to the imagination. Even among those who have undertaken to define "Quality", there is more variety than consensus. By examining the ways each of these traditional definitions falls short, we can appreciate an emerging new definition: Quality is delivering Business Value.

Part 2: Business Value as the Measure of Quality
This article is also published on Project Connections.
Topic: Quality   •   Date Published: 18 Mar 2011

We examined the ways each of the traditional definitions of "quality" falls short in part 1 of this 2-part series. Having done this, we can now appreciate an emerging new definition: Quality is delivering Business Value. As we do, we will see that it borrows the high points from each of the common definitions while leaving the baggage behind.

Quality is Conformance OF Requirements
This article is also published on Project Connection.
Topic: Quality, Requirements   •   Date Published: 15 Aug 2005

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 this: 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"?

Quality is Not My Job
This article is also published on CM Crossroads.
Topic: Quality   •   Date Published: 15 Aug 2006

In software organizations, it is not uncommon (in fact, it is considered to be "best practice") to make a clear division between developers and testers. This division of work makes a lot of sense from both a skills and an objectives point of view, but 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. How can we combat the attitude that "Quality is not my job"?

Quality That Is Worth the Cost
This article is also published on Project Connections.
Topic: Planning, Quality, Metrics   •   Date Published: 5 Jun 2006

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.

Quantifying Risk: The Purpose of Testing
This article is also published on CM Crossroads.
Topic: Quality, Risk, Management   •   Date Published: 16 Feb 2010

Testing is such an integral part of our software projects that we often don't stop to think about why we do it. We must do it! What else is there to know? It is obvious that software that has not been tested is unready for deployment. But as painful experience has taught us, testing does not guarantee that the software is fit to deploy. Even rigorously tested software may still have hidden fatal flaws.

Reducing Your Cost of Quality
This article is also published on Project Connections and CM Crossroads.
Topic: Quality, Metrics   •   Date Published: May 2005

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? These are the more significant Cost of Quality, and althought they are beyond your direct control, you can gain control over them indirectly!

Risk Management: It's not just a good idea...
This article is also published on Global Knowledge.
Topic: Risk   •   Date Published: 27 Nov 2007

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?"

The Risk of Regression
This article is also published on CM Crossroads.
Topic: Risk, Quality   •   Date Published: 19 Jun 2006

"But it was just a tiny little change! How could we have known it would cause such big problems?" 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?

Software Quality Data Series

Part 1: Basic and Derived Metrics
Topic: Quality, Metrics   •   Date Published: 2003

We measure, quantify and report on software quality. But can we control it? Can we actually assure quality (as opposed to just measuring it)? In Part 1 of this series, we will discuss the three basic metrics from which the most important quality measures can be derived (Defects, Effort, and Size). Then we will look at several important metrics that can be derived from those basic three.

Part 2: Quantitative Quality Planning
Topic: Quality, Metrics, Planning   •   Date Published: 2003

In Part 2, 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. This includes 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.

Part 3: Quality Control Using In-Process Data
Topic: Quality, Metrics, Management   •   Date Published: 2003

In Part 3, we will discuss using in-process metrics to track against our quaity plan, and taking corrective action when the in-process data suggest it. This is how we actually gain control over quality!

Software Quality – Service Quality: What's the Difference?
This article is also published on CM Crossroads.
Topic: ITIL®, Management, Quality   •   Date Published: 16 Oct 2006

We have spent many years talking about building high-quality software products. But 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.

Standards That Are Worth Following
This article is also published on CM Crossroads.
Topic: Standards   •   Date Published: 18 Feb 2008

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.

Testing is NOT Quality Assurance
This article is also published on Project Connections.
Topic: Quality   •   Date Published: 3 Aug 2006

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!

Testing vs. Quality Assurance
This article is also published on CM Crossroads.
Topic: Quality   •   Date Published: 30 May 2006

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!

Tool Choice as a Quality Issue
This article is also published on CM Crossroads.
Topic: Quality, ConfigMgmt   •   Date Published: 18 Nov 2008

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. Well, let's think about this a bit. Hmmmmmm...

TSP Can Be the Building Blocks for CMMI
This article is also published on CrossTalk Magazine.
Topic: Process   •   Date Published: Mar 2005

Why would you even consider the Team Software ProcessSM (TSPSM) when you must conform to the Capability Maturity Model&reg Integration (CMMI&reg)? Far from adding work to a CMMI initiative, TSP can reduce the time and effort that will be required to achieve your goals. Simultaneously, TSP will give your engineers an appreciation for good processes along with the desire to adopt improved processes in every area of the organization.

Using Earned Value Series

Part 1: Planning Software Projects
Topic: Planning   •   Date Published: 2003
How can 90% of our projects be 90% complete 90% of the time? 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.

Part 2: Tracking Software Projects
Topic: Management   •   Date Published: 2003
How can 90% of our projects be 90% complete 90% of the time? Earned Value is a project planning and tracking method that removes much of the subjectivity from the process. 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.

We Cannot Trade Quality for Budget or Schedule
This article is also published on Global Knowledge.
Topic: Quality, Planning   •   Date Published: 14 Feb 2006

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.

Welcoming Change
This article is also published on CM Crossroads.
Topic: Agile, ConfigMgmt   •   Date Published: 18 May 2009

Change is a fact that we must live with. To avoid change is to avoid reality. The Agile methods go beyond merely acknowledging this reality. They teach us how to capitalize on the changes that will inevitably come along to produce a better result than the one we planned for in the first place. We don't just accept change, and we don't control it. Instead, we learn how to welcome change!

What is the BA's Role?: Four steps to a clear answer
This article is also published on Project Connections.
Topic: Requirements   •   Date Published: 19 Jul 2007

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. 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. The Business Analyst role can overlap several others in your organization, but this simple approach will minimize conflicts over responsibilities.

Who Does QA? Hint: Not Your Testers!
This article is also published on Global Knowledge.
Topic: Quality   •   Date Published: 20 Nov 2006

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.

Why Agile? Learning to develop software successes
This article is also published on Project Connections.
Topic: Agile   •   Date Published: 4 Dec 2007

New software development 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?

Why Agile? What's so great about Agility?
This article is also published on Global Knowledge.
Topic: Agile   •   Date Published: 23 Sep 2008

Why are people talking about Agility so much? Is this just the latest "new thing"? Or is there some real value to it? "Agile", as a set of software development methods, was defined seven years ago, so the "flash in the pan" would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in agility.

XP – An Overview
Topic: Agile   •   Date Published: 2003
Many people are talking about Extreme Programming (XP) and the other "Agile Methods", 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.

Yes, You Can Negotiate Project Constraints!
This article is also published on Project Connections.
Topic: Planning   •   Date Published: 2 Jan 2007

"This is what we need. You can use these resources. And you must deliver it by that date." Does this sound familiar? There are lots of dictates, no flexibility, and more often than not little realism in the demands. 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.

Yes, You Can Review Your Own Work!
This article is also published on CM Crossroads.
Topic: Quality, Metrics   •   Date Published: 14 Jun 2005

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.

 

©2009-13 ASK Process, Inc.
ITIL® is a registered trade mark of the Cabinet Office.
<
Website design by www.GraphicsPark.org