Over the weekend, on the Agile-Testing Yahoo Group
, one of the members asked the following question:
What, to you, makes an Agile project "agile"? If you were asking questions about an upcoming project that was billed as "agile," what would be green or red flags to you?
For example: I would be very concerned with the actual workflow during the sprints: are the testers brought "into the room" after development is "done" (mini-waterfall) or are they involved from the very beginning of story development?
What role should metrics such as bug count and actual vs. remaining hours play? (I have my own ideas on this subject but would like to hear from others.)
As a final example, I would ask if there was a continuous integration architecture in place.
(Background: I have read quite a bit about Agile methodology - including Lisa Crispin's and Janet Gregory's excellent book on Agile testing - but have yet to have any real experience with it.)
Thanks for any feedback and I hope this is not OT.
Not off-topic at all.
In fact, I took my quick, lazy, hopefully-good-enough Saturday swing at the question, and wrote this brief reply
--- In firstname.lastname@example.org, Lisa Crispin <lisa.crispin@...> wrote:
> These are good questions, and it's hard to give a short answer. However, I
> can provide a couple of good links that would help answer these.
> On what makes a project agile - Elisabeth Hendrickson's "Agile Acid Test"
Good points, Lisa.
Here are five things that, for me, are big/more obvious red flags that an 'agile' project might, well ... not be so much.
1) If you take the word "agile" off of everything ("Agile" requirements
documents, "Agile" gannt charts, "Agile" Change Control Boards) -- It pretty much
walks, talks, and acts like the old, classic waterfall process.
If it walks like a duck ...
2) The adherence to process, terms, and definitions, seem to defy a
plain-english reading of the agile manifesto. (www.agilemanifesto.org)
3) The process seems to be all about the artifacts - cards on a wall,
"iterations", automated test suites. The human element feels missing, and so
does the thinking.
4) People aren't talking to each other; hand-offs of documents are the norm.
5) There is a powerful group of heavily influential customers who are either
asking for conflicting things, insisting on the right to add new scope without
moving the deadline, or insisting on knowing when the software will be done-done
before it's really defined. In other words, classic recipes for defeat still
fail, even on "agile" projects. Especially "agile" projects where the
quotations are appropriate!
That's my quick, sloppy list, but i hope it helps. Hmm. I may blog this. :-)
Make that "will blog this", not may.
Yes, I sidestepped the metrics question -- we've covered that on this blog plenty of times. The answers I have are a handful of the bigger issues I see blocking agile adoption.
If you'd like more, I do have an older article
addressing the question from a different perspective.
More importantly, though - are there other 'smells' you've seen where companies try to implement a more Agile way of work, yet are crusin' for a brusin'?
Do you have stories to tell? I'd like to hear them, and yes, we can protect your anonymity. If you don't want to login with a known userid, please feel free to email me, Matt dot Heusser at Gmail Dot com. I will not retell your story or 'smell' without permission. (and credit!)