Rawpixel.com - stock.adobe.com
How Agile team culture can help improve software quality
Any Agile team that wants its team's culture to be squarely centered on improving software quality, should consider the following incentives and tactics.
It is easy to stumble into antipatterns that hinder quality in software development. For instance, if there's a quality officer in an organization, most employees will view quality as that person's problem. However, if you leave quality up to the team, the organization runs the risk of nobody stepping up to maintain quality.
Let's examine how to build an Agile team culture that has a clear idea of what quality looks like and what it takes to attain it.
Incentives that drive a quality culture
So how does an organization create the conditions for a quality-centric culture?
Role of management
My first professional role was at a small company that had around 40 employees. The owner and company president would sometimes come downstairs to check on things. Somehow, magically, this visit always seemed to be when people were lollygagging or chatting a bit too much. He would ask someone a status question, and we would all get back to work. He reminded us that he cared, and that reminder was all it took.
This is what management guru Tom Peters called management by wandering around in his book In Search of Excellence. Now, that does not mean asking, "Why didn't QA find that bug?" but it also does not mean a hands-off approach where people are punished for finding defects at the end. Instead, management dials up the team's quality-boosting efforts earlier in development.
So, an executive who might typically ask, "Why didn't QA find this bug?" instead responds, "I don't care about blame. Blame me. Fine. I screwed up. Okay. The question is how do we fix it, and how do we make sure this never happens again?"
That said, the executive must actually follow through and see if the changes actually happen and help -- or if they just add mindless checkboxes to every task that do not apply 99% of the time.
Thinking long-term
Don't fall into the trap of focusing only on short-term incentives. For example, to hit deadlines, teams might want to skip tests; avoid addressing failing tests; and treat quality problems as known issues or expected results. In this scenario, these incentives directly lower the software's quality. Some grown-up needs to say "Yes, this month, this quarter, velocity will be down, but quality will be up." Without that, any change effort has stopped before it started.
Culture and process hacks
One way to produce higher quality code at the same speed as traditional coding is test-driven development. In TDD, programmers spend a little more time on design and structuring the work and make up for that with less debugging.
At the end, the code that pops out includes a "free" regression test suite. So much of software quality is exploring and elaborating on the consequences of ideas, yet the most visible place to start is probably a decrease in bugs escaping undetected at each level.
The history of automated checks at higher levels -- created before the code is created -- is more mixed. After unit tests, the next step may be automated API checks. Defining the expectations for API tests upfront creates an executable specification. The test for an API should represent what the API should do.
Bugs can be defined in terms of a failing test. The bug can be marked as fixed when the test passes and other tests don't fail. Moving up from the API to the user interface is more challenging, as it is harder to create a test for the UI before the UI exists. The tool Cucumber and the given/when/then format are popular ways to define the user experience by checkable flows. These tests aren't often automated, creating something roughly as valuable as a regular requirements document, sort of similar to a legal proclamation of a holiday.
Another surprising hack is to find the feedback delays in the system. The longer the feedback delay from the creation of a bug to it being found, the more uncertainty, confusion, and context change will exist in the system. Give an analyst four weeks from discussing the story to review, and they'll have forgotten it. Make it four months, the analyst will have other priorities or may have moved on. At four days, you get focus. At four hours, the analyst or product owner will be engaged, because they begin to realize that a poor job now will mean much more work later -- and later is real soon.
The bottom line
The major theme with Agile culture is management engagement. If management reads the reports and digs into the data, the work will be of higher quality. If the people in the organization can get closer to the customer, they can deliver more value to that customer
To create culture, take a hard look at what you are rewarding, along with how you communicate expectations and consequences. Make sure people have the tools, training and job assignments they need to be successful. Most importantly, lead from the front. If you're not able to lead, at least try to provide team members external learning materials; maybe even leave printouts of, say, articles in places people will find them.