Operations, Tactics & Strategery

Customers define quality. Creating quality software means delivering a product that not only meets customers needs but also their expectations of how it should work. When is the last time any of us read a requirement document that outlined the customer’s perception of quality? I’m sure quality is omitted from a requirements document because it is assumed. Maybe quality is omitted because we are afraid to ask our customers to define quality for us. After all, we position ourselves with our customers as people who have all the solutions to all of their problems. We know everything, so we know all about quality. Right? Maybe we are afraid to ask about quality because we can not truly deliver quality. To be fair, the question probably does not get asked as much as it should because the customer’s definition of quality is always changing.

To meet this moving target we need to be more agile. Many organizations spend a significant amount of time up front gathering requirements. Prior to assigning development resources, the requirements are defined in a requirement document and all development decisions are based off that document. What if the customer’s requirement changes? There is a good chance the customers business landscape will change affecting the requirement. How would development know of this change from a static document that has been defined and approved 4 months ago? There is a good chance the requirement will be developed without instruction, a story or some context of how the customer will use the functionality to meet their changing business needs. How do organizations deal with this misalignment between the customers, their customers business and their own development lifecycle?

Many development organizations have addressed this type of problem by migrating from their traditional code and fix or waterfall methodology to a flexible agile development methodology such as XP, Scrum, EVO, ASD, etc. Agile methodologies promote frequent adaptation through iterative steps called iterations. Each iteration lasts a short period, is worked on by an entire team through a development cycle. The benefits of agile methodologies provide organizations the ability to adapt quickly to customer’s needs and expectations. Many organizations employ a more hybrid agile approach to fit their organization.

Organization’s that employ a type of agile methodology improve their chances at meeting customer expectations and delivering quality in the eyes of the customer versus their code and fix or waterfall counterparts. Even if your organization does not employ an agile methodology find a way to narrow that gap between requirement gathering and user feedback to ensure the product is meeting the customers needs and their expectations. The next topic will discuss measuring an agile program.

Defining and collecting metrics should be a disciplined part of every project or deliverable as a feedback and evaluation mechanism. When unsure what to collect, organizations often collect everything and wind up with, well in many cases not much, just a bunch of numbers. A method that provides focus in determining what to collect is the Goal-Question-Metric (GQM) method. This top-down, goal-driven method was developed by Dr. Victor Basili during the 1980’s in conjunction with his work at NASA. GQM provides a framework for developing and maintaining a meaningful metrics program that supports metric alignment with organizational goals. GQM can be applied to all life-cycle products, processes, and resources.

GQM Basics –

• Develop corporate, organizational or project goals.
• Generate questions that define those goals in a quantifiable manner
• Define the metrics needed to answer those questions in conformance to the goals.

With each goal, question and metric a mechanism is required for data collection and validation. Analysis of the data is required to provide timely feedback for corrective actions. Analysis of the program itself is required to assess conformance to the goals and improvements.

Some best practices for implementing GQM across all levels (strategic, tactical and operational) include -

• Implement in a phased approach to ensure quality and focus.
• Get the right people involved at all levels, cross functionally.
• Secure management commitment.
• Set and communicate measurement goals.
• Do not reverse engineer goals based on available data.
• Plan, document and establish the infrastructure for the metrics program.
• Stay focused on goals when analyzing data.
• Ensure each metric has a goal, owner, target & corrective action plan.
• Metrics need to be ones that drive the right behavior.
• GQM is a tool, not the end goal.

GQM has long been in the industry. It is a large yet critical topic; this approach should be the cornerstone of any program.