In May I attended my first software testing conference in person, StarEast in Orlando. I sat through most of the sessions, taking notes, which is in part why I was a bit caught off guard when the first speaker of the day said something that struck me the wrong way.
The speaker started with a brief company overview and then mentioned the firm's agile process. What I heard was: "We utilize Scrum. And we document our process, and we repeat it."
My first reaction was, "Did I just hear what I think I heard?" Ergo, they're "agile"? There was something in that implied statement that simply didn't compute.
Waterfall development has been around since 1970. Waterfall follows a repeatable, incremental process. It's also heavily documented. None of that makes it agile. It doesn't make it adaptive.
It's clear that some people still don't know what agile is all about. "Agile" has become the other "A" word (hint: automation). People talk about agile software development as the cure for everything, without knowing what it really means. We've strayed from the origins of the Agile Manifesto, and turned agile into something used and abused by salesmen to sell as a product, rather than as a mindset.
People are so focused on being agile that they've forgotten the real objective: delivering quality to the customer. Here's how to keep the focus.
My early agile experiences
My first introduction to agile came in 2011. My team followed many of the standard agile processes: two-week sprints, daily standup meetings, backlog grooming, retro, and planning. I soon learned we were missing one key tenet: self-organizing teams. We had relocated to a brand-new building, where the office could have been set up and furnished in any fashion, but the decision was made to go with a standard cube farm.
Within a few months, management decided to tear down the cube farms in most areas, bringing down the walls between teams—and severely disrupting the development work going on—in favor of the open office concept. It did so without consulting anyone on our Scrum teams.
What we got was agile-in-a-box. Management had only an idea of what agile was, and it brought in agile coaches who sold the company exactly what they thought it needed.
In my next agile experience, I worked on a product team with multiple Scrum teams working on different areas of the same product. We had weekly releases, keeping each Scrum team on the same schedule.
Despite the ability for each team to deliver changes independently, we were not allowed to do so. What happened next was entirely predictable.
The release cycle would begin at the start of each week, with a planned regression test cycle by each team prior to deploying to production. One team would discover a defect that would prevent every other team from being able to release their changes. This prevented us from releasing small changes more frequently, and instead forced us into larger releases with even more risk, one of the very things the agile process was intended to avoid.
The purpose of agile
So what is the purpose of agile? Agile doesn't mean no documentation, or no planning. Agile isn't about iteration. Iteration is a method, not a goal. We iterate in order to adapt.
Agile is about being able to adapt to changing customer needs rapidly. It's about getting fast feedback from the customer, who is the ultimate arbiter of quality. Quality means different things to different people, but in this context I like the definition from Alan Page and Brent Jensen on the AB Testing podcast: Quality is a problem solved for the customer.
For those involved with software development: You are not the customer. It's important to learn about the customer, to understand the customer, but you will never be the customer. This is why it is so important to deliver changes to the customer frequently, to get fast feedback, and know that you built the right thing, not simply built something that works.
There was a story my team worked on during my first introduction to agile that didn't go right. We discussed the story in our backlog grooming meeting, the developer wrote code to match the requirements, and I verified that the code worked without error. We demoed the story to our product owner, who immediately told us we'd built the wrong thing.
We built the thing right—we verified code correctness—but we hadn't built the right thing. We didn't deliver the correct solution for the customer. Luckily, it was only a single story within our two-week sprint, and we were able to quickly adapt and make the necessary change.
The pursuit of quality
I watched a great session recently from the 2011 StarWest conference, presented by Dr. James Whittaker and titled "All That Testing Is Getting in the Way of Quality." He talked a lot about testing, but his bigger lesson was: "Don't waste your time doing stuff that doesn't matter."
The customer doesn't care about:
- What process you follow
- Whether you sit in a cube farm or in an open office environment
- Whether your team is centrally located or whether some of the team is remote
- Whether you stand up for standup
- How many teams you have
- Your code and how you write it
- Your test plans or test cases
- Your bug reports
Customers care about the software that is actually delivered. If it doesn't ship, it's of no value to the customer.
StarEast was a reminder that buzzwords matter less than what development teams are trying to accomplish: finding ways to solve customer problems and deliver solutions faster. Forget about whether you're following agile, lean, XP, DevOps, BDD/TDD, or some combination of those things.
Instead, take this advice from Gen. George S. Patton:
"If you tell people where to go, but not how to get there, you'll be amazed by the results."
The best result for a customer is a problem solved. That's what quality really means. Focus on that.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
