Saturday, July 5, 2008

Can QA be Agile?

We are in an orderless world. Often it feels like the only barking order we get in the development lifecycle of a project from management is "get it done". What is inferred in that statement that is often lost on the masses in your deliverable team, is that management would like you to "get it done" in the following way:
  • On Time
  • On Budget
  • With a happy client (internal or external)
So you get the next website project handed to you. It's a 4 week development project, and the client wants one of the weeks for review with their internal staff. So with Design, Development and Testing you have 3 weeks to get something presentable to the client and one week after to implement all of their changes and get it to go live.

After the screaming in your head subsides (OH DEAR GOD NO IT'S IMPOSSIBLE, THERE IS NO WAY THIS CAN HAPPEN), you shake it off and see how you and your team can "get it done". Your management team thinks the "Waterfall" methodology is ancient and dusty and wants you to use one of the more flexible methodologies that they have read about recently, so you start surfing to read what they are about.

At a top level, you come across some intriguing development methodologies (Oh, there are more, but they all start looking similar very quickly):
  • Agile - (from the Agile Manifesto)
    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan
  • XP
    • An Agile method
    • Development-centric
  • Scrum
    • An Agile method
    • Project-centric - "they provide managers with tools to monitor, prioritize, and control projects without specifying anything about how the software is built." (
OK Agile Manifesto guys - sounds like something that everyone wants - less process, collaboration, working software, with customer interaction! What could be bad about that? I (Negative Nellie) read other things in your list: No documentation or customer commitment and constant change until the end. All of these things equal $$$ and potential instability. How do you guys get the client to commit to an idea, secure a budget, and stay within it with this method? I could not tell. So I surfed some more, and found:

"Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams with "just enough" ceremony that produces high quality software in a cost effective and timely manner which meets the changing needs of its stakeholders." (From Agile Modeling)

OK, the screaming in your QA head is probably starting again - and it comes in one word "HOW??" Have 4 deep breaths, and come back in a minute... Better? Good. Incremental in 3 weeks, hmmm - that doesn't sound like a fit. In 15 business days you need to understand what the client wants and make it. "Agile" is what your team needs to be, but the methodology sounds like nebulous and wishful thinking. When QA people get their hands on it (since there is no QA in the methodology theoretically), it then gets some structure to it.

agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.

A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing. (From James Bach's Blog)

That sounds a lot more like something that can be utilized by a team. So then I found Elisabeth Hendrickson. QA's role is supporting the development team in their goals and the customers in validating that "they got what they paid for". QA is part of the development process from beginning to end. Overall, it's all about embracing change and planning for maintenance. Her high level bullets to describe an Agile lifecycle are:
  • Adapt
  • Collaborate
  • Get Feedback
  • Communicate
  • Deliver Value
  • ...Continuously
OK - she sold me. I dig it. I can't sell anything that is process laden, and over-planned to my management team, or the individual resources no matter how hard I try. Over-planned does waste time, and is loathed by all. But you can't have no planning - you have to have some way to manage client and team expectations, communicate - and it looks like with a little "structure" it can be done! Check out Elisabeth's Google Presentation for details:
So, with my 4 week project, the team should sit down and break it into logical chunks. Each chunk is an iteration unto itself, and each can be designed, developed (including testing), and run by the client as it is completed. That to me is worth a try.

XP and Scrum are flavors of Agile from different perspectives (Dev and PM). I had tons of opinions on XP prior to this blog, both positive and negative (The founding father of XP, described QA as, "irrelevant in the brave new world of eXtreme programming") as for Scrum, I see terms like "manage" and "control" so that tickles my QA fancy, but it may not be as "agile" as one would like - so I will get back to you on that.

In the cloud world of Web 2.0 with 3.0 biting on its heels, how do you as a QA person bring some order to the hip methodologies that are the recent big buzzwords like Agile, XP, and Scrum to name a few. Agile truly is nebulous, but has some good ideas that can be transformed into goals and a development methodology tailored to your company. XP has tools for how to get it done from a design and development perspective. Scrum - looks promising, with its communication points to management, and I will be looking more into that over the next few weeks. The biggest thing I can see, is that with all of these methodologies, if you don't have your test group work throughout the iterative lifecycle, you don't have an Agile process :)

Night all... more Agile thoughts to come on how to actually do it in a project.



Jennifer said...

I could see this working for a small project with a close group working together but I wonder if it would take more budget since QA would be involved during the entire process, or would the increase in iterative testing actually decrease the QA budget. Is there research with actual numbers that show which method is most cost effective?

Test Insanity said...

Check out:

The ideas behind scrum are:
1. Respecting people
2. Continuous process improvement
3. Avoiding waste by eliminating impediments to flow

By joining the team together costly miscommunication and misdirection are minimized, therefore optimizing the process and lowering overall cost.

Most project budget is lost after the release to maintenance when it cost the most to fix the issue. With all groups working in an embedded way throughout the project on small iterations, the quality of the end deliverable is often higher, and the need for bug fixing after the release is less.

Searches on job boards for companies looking for scrum experts to join their teams show many results with large companies like the following:

Pitney Bowes
Kelley Blue Book

Seems to say something - tho the research keeps on :)

Test Insanity said...

How bout this one too:

HP gets 3.4x productivity gain from Agile Management techniques: