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.

One Comment

  1. Helen says:

    I look forward to how organization’s measure their agile process. My team incorporated a hybrid model and kept the same measures which do not align. Now there are no resources to determine the effectiveness of the process change. One thing that teams need to do which we didn’t was to baseline the old development process against the purpose for the change and then compare it to the new process.

Leave a Reply