- On Time
- On Budget
- With a happy client (internal or external)
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
- An Agile method
- 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." (testobsessed.com)
"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.
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:
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)
- Get Feedback
- Deliver Value
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.