Going from Waterfall to Agile

Agile - look up this word in any dictionary and the meaning you’ll find is something along the lines of "able to move quickly and easily”. The new dictionaries have made space to accommodate another meaning with reference to the software industry - "relating to or denoting a method of project management, used especially for software development, that is characterized by the division of tasks into short phases of work and frequent reassessment and adaptation of plans”(1).Similarly, a search for Agile on Google can flood the page with so many references and articles that, more often than not, end up confusing the user than explaining the concept.

Like some people new to agile in the software industry, the most I really new about agile and ThoughtWorks, was that it was a propagator of this methodology. As a good student, I had done my homework by reading as much as possible on agile before joining ThoughtWorks. Little did I know, that this was no where close to preparing me for what was about to hit me hard - the agile practice.  I realised reading about agile is one thing, and practicing it, quite another.

On the first day in my first project in ThoughtWorks I stood by as the other teammates gave their updates in the stand up and moved towards the ‘wall’ for sign-ups. The story wall was set up for the various phases like ‘In-analysis’, ‘Ready-for-dev’, ‘In-Dev’,‘Dev done’, ‘Ready-for-QA’,’In-QA’, ‘QA-done’ and ‘Ready-for-release/Showcase’. The cards were neatly lined up in various lanes, depending on which stage of development they were in. The successive days saw the cards being quickly moved to the next lanes. In the blink of an eye, the stories were getting completed and thrown into the QA bucket. To me, it seemed like the earth spinning at twice its usual speed. How can something get developed so fast? What was this velocity that was being called out for every iteration? What is burn-out? What goes on in an IPM? What do story estimates like 1-2-4-8 mean? What is an epic? What is dev-box? Questions like these flew thick and fast in my mind.

Coming from a company that practiced the traditional waterfall model of software development, where QAs sat pretty until the entire development cycle cloud burst to rain work on the QAs, I found this to be totally new ground. It took me a couple of weeks to comprehend all that was going around and feel the earth spin at its normal speed again. I soon realised, the key in this mode of working was to walk hand in hand with the devs to keep pace with development. The turnaround cycle was quick and very effective with immediate feedback at every stage. As a QA, while the dev work was on for a project, I had time to put down my test scenarios and test cases in the story card. This helped set the expectation with the devs as well as bring down the time spent in testing.

So for a newbie in ThoughtWorks and who happens to be new to the agile world, here is what to expect:

• Reading about agile isn’t usually enough to prepare you for agile in practice
• Every member in the team, be it a developer or QA or BA can get involved in the project as early as the inception, so as to keep pace and be involved in every step
• The stories move through each phase of development quickly and will be out for showcase in no time
• The feedback cycle is quick and this helps in getting out a software/product with fewer/no defects
• Agile is QUICK. Be prepared. I’ve probably said it enough times before!

 

(1)"agile - Oxford Dictionaries." 2013. 19 Dec. 2014 <http://www.oxforddictionaries.com/us/definition/american_english/agile>