Agile Project Quality
Every agile project and product, and the workings within every agile team has their own determination of quality. Predictably, we assume that from agile project to agile project in our organization the quality expectations will be similar, if not nearly identical. There is no hard and fast rule to this. In the world of agile project management and continual improvement we imagine future projects to have potentially better, or different determinations, of quality based on the feedback, information gathering, and learning captured from previous agile projects. What the quality standards were for one agile project may not be the same as they are for another agile project, even if they are for the same customer group and lead by the same product owner. Even in the same project, the definition of quality could change. Like our agile plans adapting to the needs and feedback of stakeholders, so could the terms of quality. For instance, if the quality standard the product has is that the Employee Benefit app must load within one second and never crash, but as the features are developed and the technological architecture is vetted out, it is determined that one second is unrealistic and unachievable. Testing and striving to such a quality standard is unreasonable and therefore the standard is reduced.
Maybe the one second quality threshold is obtainable — but at a cost. Is the cost worth it? That question has no one correct answer. The answer of whether the benefit gained is greater than the cost is highly individualized and dependent on the needs and wants in reference to the factors and variables that fit into the equation. When determining the quality for the product, there must be a frequent cost to benefit discussions. Quality comes at a price. Whether that incurred cost is in the form of tangible expenses, such as purchasing higher end, more reliable equipment, tools, or components, or in the form of more intangible expenses such as hiring a more experienced subject matter expert at a higher rate or the inclusion of more tests to ensure the meeting of quality standards.
The power of managing projects in agile methodologies is that we are more connected to our customers and users. We can, as much as possible with the willingness of customers, get more understanding and expectations of product quality.
Using measurements throughout the project, including the concentration on discovering and detecting problems, errors, and bugs and resolving those issues as we discussed in another course, we can support achieving quality and assuring the delivery of value to our customers and end users. There are various quality tools and techniques that can be employed in agile projects, just as they are used in other forms of project management and in day-to-day operations. Awareness of the various tools and techniques are good to have and utilize as much as needed to deliver the appropriate level of quality expected for the project.
Whatever the tools and techniques used in an agile project, the important reminder is that project quality should not be an afterthought. Quality must be built-in from the start. Quality needs to be considered and confirmed from the first minute. Too often agile teams don’t figure out what a quality product will look like because they feel they don’t know what the product is, so how would they know what the quality is. That is an insufficient perspective. Quality does not need to be completely established and set in stone at the immediate start of an agile project or iteration; it evolves and becomes progressively elaborate over the course of the project and development. My suggestion is not to “get to quality when we know more”, but to be considering and thinking about product and project quality from the start. That includes determining what quality should or should not be and assuring that this evolving definition of quality has been achieved. When standards of quality have not been substantially met, you’ll need to determine what action or actions are necessary to correct the quality shortfalls or make sure future project quality defects do not manifest themselves as the project progresses and builds.
When considering quality, our primary focus should be on the products of the project. Nevertheless, we should all be seeking ways to make ourselves and the material we are working on a standard level of quality best suited for our project. That includes the way we interact and work as an agile team. It also counts for our performance on those items that directly and indirectly impact the product. The indirect aspects of quality may still impact the overall project quality and its incremental achievement of project success.
Quality is a mindset. It is a state of being and acting. If the quality norms and expectations are not established, then how are you and your agile team ever to know if they are being achieved and if you are working towards them being achieved?
No matter how fast we are, how efficient we are with our time and resources, how aligned to quality standards we have set ourselves to, and how cost conscious we are, if we are not developing anything of value, then what is the use? If we are not understanding the needs and wants of all our stakeholders and crafting the product to best meet their needs, then all our efforts for setting quality expectations are for nothing. Identifying and delivering to value has been the objective of all our planning and execution processes. It is a concept we have hit hard on throughout the agile project management course series, and that does not change here. For our purposes here, let’s examine it from our need to establish and achieve quality.
Essentially, we can utilize the concepts of fit for purpose and fit for use in delivering value to our product’s customers. On one hand, we must make sure that the product and the features we are developing meet the needs of our customers. Whether it is solving the issue or problem they are having, reducing barriers for them to reach their goal, or satisfying some other want. That is the basic concept of fit for purpose — the overall purpose of the product and features. Making sure we nail this is why we work so hard and consistently throughout the project to ensure we are aligning all the outputs to meet the expectations and match the outcomes they desire.
On the other hand is the necessity to ensure that the product does not just do what it is intended to do, but does it well. For instance, in the Employee Benefit app project example, one of the purposes of the app is to give employees convenient access to their benefit information and claims on their mobile device. If we developed the app to present such information to them on a mobile device, then we accomplished the fit for purpose component. It has produced its purpose. But if the app and presentation of the data is not useful, then it loses value. If the data presented on the app takes too long to load, then its fitness for use diminishes and so does the app’s value. Other examples in this case could be the data presented being inaccurate or not current. Maybe the app crashes too frequently. When we consider the usefulness and quality expectations of the product and features, we might consider its availability, the user experience, the capabilities of the end user to successfully use the product, conformance to standards or code, the reliability of the data, and many, many other factors.
Therefore, when we are confirming value and determining the definition of “done” throughout an agile project, we must not only factor in the purposes of the product and its features, but its inherent usefulness. I am sure all of us can relate to a time where we have used a product or service that presented an ideal solution or desired outcome, only to have it fall short or below expectations in its execution. This is why quality in agile projects is so important. If I gave you a boat to your specifications and in the time you requested, only for it to be unable to propel forward, then there is little or no value in the product.
In an agile project, we must determine the quality standards using the fitness for use considerations — to set, reset, and incorporate the efforts to achieve such standards, including testing and other manners in which to confirm the value. Part of achieving value is to measure the efforts towards value. Next we will discuss how we can monitor the obtainment of value and the production of our agile development team.
Cumulative Flow Diagrams
As part of determining and seeking to match the quality standards, we have to measure the value gained. In terms measuring or having a visual declaration of the value gained by an agile project, there are a couple tools that can be used to express the value gained and to illustrate the progress of the project or iteration and how much more value it has to earn. The tools I want to share with you is the cumulative flow diagram.
Cumulative flow diagrams are graphical tools that can be used in tracking and forecasting agile projects. The cumulative flow diagrams, sometimes referred to as CFD, is a valuable visual that informs all stakeholders on the progress of the project and the work being completed. At its simplest, on a cumulative flow diagram the vertical Y-axis represents the tasks and work of the agile development team, while the horizontal X-axis represents the time period. Cumulative flow diagrams can be constructed per iteration, but are used more to track the progress of value for the entire project.