When moving your test organization from Waterfall to Agile you have change a lot.
But du you throw away everything? I don’t think so.
In lack of a better word, some “artefacts” you;
Put into these four categories. any thoughts regardning what “artefacts” goes where?
And why?
Archive everything. When you need it, pull it out. That’ll teach you what you can’t do without. The choice will be heavily contextual, so nobody could sensibly say what you definitely keep or dispose of.
@emossik Can you give some examples of what you consider to be “artefacts”?
I’d caution against trying to keep too much the same from your previous process. I’ve seen and heard of plenty of organizations that really struggle with the transition from waterfall to agile as they keep trying to maintain processes and things from waterfall. I’d argue if you’re really trying to do a paradigm shift from waterfall to agile, you need to jump in and not worry about maintaining backwards compatibility to your old processes . . .
Hey - we went through something very similar to this a few years ago. I did a talk a few years ago called “Deprogramming The Cargo Cult” (of Waterfall). I think you can find a video of it on YouTube.
But in a nutshell we did an analysis of everything we felt we got from our artifacts in waterfall, and said “how can we get this kind of assurity under agile?”. Because agile is so different, sometimes the same artifact just doesn’t deliver under agile vs waterfall.
Oooh - video here ,
Most of the QA service companies follows the Agile Process in their projects over waterfall. This is because if we talk about Agile, it has several advantages over Waterfall modal. Moreover, Agile is also more suitable for software development but if we talk about global usage, not many companies are ready to move from one implementation to the other very easily, as it is always a bit difficult adapt to the new process/technology. Waterfall has served many software testing companies for a long time and is still considered a good methodology by many companies who integrate it into their day-to-day work. Agile is basically a relatively new methodology which is in trend for the development.
If we talk about agile, there are several things which we need to be considered about the project which are implementing the agile process and there are few factors that play a role, it includes:
Agile methodology is very flexible & different from waterfall model and it can be used in many ways including in bits and pieces. Also, the main benefit of implementing the agile process is that it can be mixed with other project management methodologies. There is a reason it is called “Agile Methodology”.
As we are moving from Waterfall to Agile, there are few essentials they can implement:
Hope this information is helpful for you.
Keep a sense of adventure because not everything is planned and needn’t be. This is a challenging mindset switch if you are comfortable with a significant amount of planning.
Change your horizon from very long to a few weeks, and change your delivery perspective from code products to products that demonstrate business value. Frequently.
Embrace the newness, the awkwardness, the clumsiness of the first few attempts to try something agile. Experimenting is half the fun and helps you learn how agile might work for your team.
Joe
So many offshore software testing companies, e.g., QAwerk, you may also seek to replace waterfall with agile in a quest to shorten the time-to-market and deliver high-quality software faster, more frequently and at a lower cost. The road to agile, however, can be a rocky one. That’s why you have put together a few lessons and tips that will help you in succeeding in agile software development. And as for me the FIRST thing is to change in mindset and culture throughout the entire company. The key to success is that everyone involved knows what to expect, is patient and, most importantly, embraces change. Agile is about adjusting. It’s about continuously assessing if requirements and goals are still valid. This new learning culture is a big challenge.
You should also remember that Agile is not a linear process. Like in waterfall projects, the work is build in a sequential manner: requirements, design, implementation, then testing and maintenance. However, in agile software is developed and delivered in small chunks. So managers, developers and testers have to work together closely and stay in sync to evaluate the situation and determine the right next steps.
In Agile development, there is more emphasis on conversation and collaboration to clarify requirements more than the traditional approach of specifications and documentation.
Although requirements can be clarified to some extent in agile development, it is still possible for requirements to be ambiguous and incomplete, and for team members to have different understanding of the requirements.
So what does this mean for an Agile Tester? A common concern for testers transitioning to Agile development is that they don’t know precisely what they’re testing for. You don’t need to have detailed documentation to get started with testing. Many times, decent testers can use their judgement and common sense to validate a product. Domain knowledge becomes crucially important. Testers should be confident to work more from their own knowledge of what good looks like. It’s certainly not just a case of following a test script, making sure the software does what it says in the spec.
7 ways to ease the transition from waterfall to agile method