The State of Agile – Lisa Crispin

The State of Agile: A Tester’s Viewpoint

I started my software career as a programmer/analyst working in an organization that knew nothing about waterfall – we sat with our end users and released when they were happy with our product. Through the years, I’ve worked in tech support and QA for software companies, as a tester and QA director for internet startups. One was a successful waterfall shop that automated all unit tests, a large percentage of functional tests, and did continuous integration – sound familiar?  For the past 10 years, I’ve worked as a tester on agile teams.

Back in 2000, my programmer teammates and I were figuring out how to do testing in an XP environment, and how testers add value on XP teams. The Agile community was welcoming, and our employer gave us time and training to learn practices such as TDD and refactoring. There were few lightweight automated tool choices, but managed to automate a good percentage of our regression testing. We produced production-ready code every iteration. My team helped start a local XP user group with folks from the few other startup companies in Denver who were doing XP.

I was one of a handful of testers to attend XP Universe 2001, the first Agile conference (as far as I know) in North America. My experience report at a large testing conference that same year was the only one on the subject of XP (we didn’t have the term “Agile” yet).

The XP literature of the time talked about customers and programmers, and pretty much nothing else. Testers, QA managers, business analysts, project managers, and people in other roles worried what would happen to them when their organization transitioned to Agile. Fear and loathing ensued, fueled by organizations that dumped documentation, encouraged chaos and called themselves “Agile.

Today, I’ve worked as a tester on five different Agile (ok, one was not so Agile) teams. I’ve worked on my current team for almost all of the past seven years. New and improved test automation frameworks and drivers come to our attention continually. 100% of my team’s regression tests are automated. We are experts in our company’s domain and drive development with business-facing acceptance tests. We have a stable, releasable, production-ready build every day.

Our local Agile user group, now 10 years old, has several hundred members, many from some of the largest employers in the Denver area. The meetings at other local software groups, including the QA group, often revolve around presentations on agile development. Agile 2010 had a robust testing “stage,” with many testers attending the conference. Every testing conference I attend has many participants from Agile teams. Social networks such as LinkedIn and Twitter allow practitioners from around the globe to share experiences and spread ideas.

Agile software development is really about continually improving how we do our job of delivering software to help the business. Practices such as continuous integration, test-driven development, and refactoring, which were popularized by agile processes, have become adopted by teams that don’t apply the “Agile” label to themselves – it’s just about producing a good product.

What Agile Has Done For Us

Agile development has clearly “crossed the chasm.” For Agile practitioners, that means that there are plenty of places we enjoy working! For companies, it means that software enhances the business, instead of holding it back – it may even mean, as it did with my current employer, the difference between success and failure.

The Agile movement has brought sweeping changes to the world of testers. Back in the day, “QA” professionals were the quality police. My last job title on a waterfall team was actually “Quality Boss!” With Agile, the whole development team is committed to delivering the highest quality code possible – and a large part of that quality is defined by our customers. When a diverse group of people with a varied skill set and wide-ranging experience takes on testing problems, innovative solutions result.  More importantly, testing is no longer a separate phase. Coding and testing are two inseparable parts of software development.

Early Agile teams were frustrated with the heavyweight vendor test tools, mostly GUI-based, of the time. So they built their own tools that were lightweight enough for an Agile environment, where we deliver business value frequently while maintaining a sustainable pace. Even better, they involved the larger open source community to help develop these tools, making them available to teams everywhere. Even commercial test tool vendors have finally woken up to the needs of Agile teams. Today, Agile teams enjoy an incredible variety of tools to meet a huge variety of testing needs. Many of these tools reinforce the essential collaboration between testers and programmers, and between development teams and business experts. Continuous integration tools let us have fast feedback all day long. If anyone checks in a change that “breaks” any part of the system, our regression tests will tell us right away.

Agile software development has blurred the lines between roles on the teams. Everyone on an Agile team does testing. Testers often do analysis work, act as toolsmiths, maintain continuous integration processes and even write production code. I’ve been known to fix bugs in SQL code. My own team writes high-level acceptance tests together. No matter what our official role, we all collaborate, with a common goal in mind: Deliver the best possible solution to the business.

Ten years ago, the common wisdom said that XP was for small, co-located teams. These days, technology enables huge software organizations spread around the globe to have effective Agile teams, coordinating vast code bases.

Where Is Agile Taking Us?

Test-driven development helps us deliver solid architecture and code design. Acceptance test-driven development helps us deliver exactly what our customers want. Continuous integration and refactoring help us work at a sustainable pace. Communication, collaboration, simplicity and feedback are like apple pie – who wouldn’t want that? My hope is that all of these become good ways of developing software. We don’t need a special name for it – we need to do our best work.

Successful software development depends on having good people, who are allowed to do good work.

For that to happen, the good people need time to learn, and autonomy to find the best ways to deliver good software. Programs that promote a learning culture, such as Google’s 20% rule and Atlassian’s FedEx Days, help companies attract and keep the best practitioners.

Unfortunately, not all companies are committed to providing a high quality software product. They aren’t going to bother to hire the right people, provide training and time to learn, and make the kind of investment needed for success over the long term. The bright side of this is there will still be jobs for people who don’t care about software craftsmanship.

We might hear the term “Agile” less in the future, but see continuous integration adopted as just as essential as source code control (who doesn’t do source code control nowadays? But 15 years ago many teams found it optional). TDD and  ATDD may be next in the list of practices that are accepted as the right way to ensure that the right product is produced. More frequent delivery and even continuous delivery to production, with all the practices needed to support that, will become the norm. We’ll have better and better tools to use, providing constant visual feedback that keeps our projects on track.

In this rosy future, there might not be a place in successful organizations for “testers” who do nothing but execute manual test scripts and never learn anything new. There might not be a place with a desirable employer for anyone who isn’t passionate about delivering the best possible software product. Agile development raises the bar for everyone on the development team. The software craftsmanship movement includes testing. There are so many ways to hone our craft, from traditional conferences to testing dojos and Weekend Testers. Enjoyment is the most important Agile value. If you discover the  joys of learning, growing, collaborating, and getting outside of your comfort zone, the future of Agile will be very good to you!

You can find Lisa Crispin at @lisacrispin and blogging on

3 Replies to “The State of Agile – Lisa Crispin”

  1. Two papers on the State of Agile in a day, one from Lisa and other from Bob Marshall discussing the fragile topic of Agile and its future. There are still questions to be answered and future directions mapped before Agile practices are accepted as the mainstream projects. There are organisations out there that expect value for money but at the same time want the product delivered as one lump sum and not in small deliverables. Even the comedians have Agile written in their script. I wonder whether it is time to transition to newly invented glamorous and catchy practices to take over from the old/current approaches. There is confusion in the market place where various establishments are adopting different set of tools and techniques discouraging the movement of people from project to project and organisation to organisation. In the past all you needed was testing experience and now as Lisa pointed out you need more which hard to gain unless you have a sympathetic employer.

Leave a Reply