I was at a conference last week chatting with a software developer and a product manager. As we talked about their projects, the topic of quality was raised and although they were both saying the word “quality” they were using it in two very different ways. Before we knew it the the project management Iron Triangle was drawn on a whiteboard, and the conversation really took off.
The Iron Triangle
The iron triangle as a way to view the constraints of a project.
The three sides of the triangle represent cost, scope and schedule and the triangle visualizes that changing one constraints will affect the other two constraints (if you want quality to remain the same).
Some people feel that project leaders fail to recognize the Iron Triangle as a valid concept, to their peril. Others have pointed out that the Project Management community are backing away from the use of the Iron Triangle. Either way, scope, resources, schedule and quality are all used as a way to talk about a project’s constraints.
But what is meant by quality in agile projects?
At this level, quality is viewed from the perspective of a project’s leadership and refers to the quality of the service offered to the customer. In other words, does it fulfill their customer’s needs? It has a strong correlation with scope but is not a consequence of scope size.
Kent Beck use the term external quality to describe this (See “Extreme Programming Explained: Embrace Change“, Chapter 4).
Reducing quality from the product’s perspective means removing benefits that the product is supposed to deliver. In lean organizations this may be viewed as a good thing as the focus is on delivering value quickly in it’s simplest form. In larger organizations, where consensus is required, this becomes difficult as some stakeholders will see their features or benefits removed from a product without compensation.
Quality and the delivery team
When the delivery team and their leaders hear the project’s quality is going to be reduced, they conclude (and are sometimes told) that they are not allowed to perform their jobs to the level of a professional.
For software developers reducing quality may mean be not writing automated tests, for UX designers it may be designing flows without understanding the customers goals and for business analysts it may be inventing requirements without speaking to your product people (or customers).
Some teams will sacrifice internally quality in order to meet a deadline, racking up “technical debt“.
To make it more difficult, delivery teams sometimes have “Quality Assurance” team members who check whether the delivered software is customer ready. Having the word “quality” in these team member’s titles emphasises that quality is a quality the delivery team is responsible for.
But what are the consequences?
The consequences of trading of quality are different for external and internal quality.
For external quality it may mean delivering an inferior product that doesn’t meet the goals of the project. Alternatively it may mean the team turns up the focus in order to deliver the core benefits your customers are seeking. If you’re a company that delivers projects to satisfy internal customers then you’re probably going to be in political trouble.
For internal quality, if your system is very, very simple you may be able to reduce internal (build) quality and get away with it, especially if it is a throw away piece of work (these are famous last words). The more likely scenario is that you’d demoralize your team by not letting them do good work and make new development increasingly more difficult.
Software systems with high internal quality are easier to extend, estimating new work can be made with more confidence and you’ll be more able to find good people to work on these systems because the system is in good shape.
It’s a crazy idea, I know, but you may decide to actually increase the quality of the product you’re shipping through a project of work.
From an external quality point of view that may mean adding new features, designing new ways to solve problems or tackling new problems for your software to solve. This benefits your customers by providing them new and/or better ways of getting their jobs done.
Increasing internal quality makes a software product enjoyable to work on because well factored systems are easier to understand, maintain and extend – it increases your agility. Martin Fowler explores this topic too.
Agile teams pay “continuous attention to technical excellence and good design [because it] enhances agility“. Be careful how you the word quality in agile projects, it means different things to different people. You can surprise someone by using the word “quality” in a way they weren’t expecting.