Agile - It’s a Social Thing

There is a lot of documentation available on agile methodologies, both on and offline, detailing processes to introduce and how best to organise teams etc. This information is very useful for people/ software testing companies wishing to change the way they work, but a key principle needs to be there beforehand - discipline.
Without the discipline of staff receiving new process ideas and actually acting on them, it’s a lost cause from day 1. Many very intelligent people have voiced some fantastic ways to use agile in certain circumstances, when to perform xyz, how to react to abc and when not do anything, but if the people involved do not ’stick to the programme’, failure beckons.
With this in mind, how can a team be ‘energised’ into willingly accepting change and, probably most importantly, continuing to work with this change as the weeks pass by? From my perspective, it firstly requires people who are open to adopting new practices, who are willing to give something a try and who are enthusiastic enough about their individual tasks and about the team. It’s a team game after all and if people are only focused on their work and how good it looks to others, they’re not going to have much time/interest in discussing the latest tweak in the process.
A highly productive agile team requires people who are capable of social interaction and who grasp that the team’s performance is severely hindered if even one member doesn’t pull their weight. Everyone needs to be ‘up for it’, asking each other about their tasks, showing interest in what they’re doing and how they are going about it. And this leads to the QA link.
An agile team which contains a QA person needs to have everyone genuinely interested in what that person is there for. “Why do we have a QA person when we’re doing TDD?”, “What are they doing to improve the way my code works?”, “Why should I listen to their recommendations when I think my unit tests are the bomb?”. If all team members keep in constant contact with the QA person (and the QA person knows what they’re doing :-)), the difference in productivity is very noticeable.
Visit learn more about: Performance testing services
This is where the discipline comes in - people need to leave old habits behind. No resistance to reading QA test plans, no resistance to discussing what seem like bizarre use cases and certainly no resistance to actually doing some manual testing if required. And if the QA person can show that the functionality isn’t as requested, it’s back to the drawing board.
From these points it shows that a QA person has a lot of responsibility in an agile team, so it takes someone with the technical knowledge, drive and (I’ll use it again) discipline to bring out the best in an agile QA function.

Comments

Post a Comment

Popular posts from this blog

How can product quality improvement be tracked from sprint to sprint?

I’m interested in defining the best metrics to use for checking whether the product quality is improving as time, and sprints, pass by. One obvious factor is the number of automated tests passing in the continuous integration builds related to the coverage of functions in the code. Or is it? Do the tests literally show the product quality? What if the finished article isn’t what the customer wanted? There are then a suite of tests making sure that the software does something it’s not meant to. Number of defects? Measured against what? The list of possibilities goes on, what I’d like to find out are tried and tested measurables. Does anyone have a list they use in every project? Update by Kenny 08/11/09 :- Ok, I’ll try and answer my own question here (the power of reflection!). There are two scenarios in projects which require different solutions in relation to metrics gathering. They are :- 1) A project run using mature agile methodologies from day 1 2) A project which ...
Read more

Agile v Waterfall - Which Is The More Risky?

I still find it strange that companies unfamiliar with Agile automatically view it as being a methodology that pays no heed to process or ensuring quality of output. From my experience the quality is actually a lot better, the timescales set are achieved more readily and everyone involved has a much greater understanding of the product and its development status at any one time. At present I´m working on a project where I´ve had to split the test team into two due to several companies working to build a complex product together. One team is performing agile QA in a sprint team, the other is working ´the old way´. It´s very interesting to note that all the worry and uncertainty is coming from the team working with the traditional model due to the fact that timeframes having been guesstimated months ago about environments, data and functionality that no-one knew about then. As time marches on we appear to be spending more time in meetings discussing what we once thought was go...
Read more

Details, Fiction and Software testing services

  No matter what DevOps processes, models and applications corporations use, testing is a vital Component of the general DevOps procedure — don't just to be sure code alterations work as envisioned and integrate well — but to make sure the necessity improvements do break the performance.” – How DevOps Transformed Software Testing Whether or not your web site is still in improvement or out inside the wild, we are able to get the job done with any surroundings. Our testers can collaborate along with your developers and task administrators, and in some cases be part of your Jira, Slack, and standup calls. Find out more about our Site testing services. For that reason, the workforce has to analyse the code on the continual foundation to keep the code foundation in a great maintainable state. This will protect against uncovered complex debts, process crashes and highly-priced fixes.” – Sergey Terekhov, Defining and monitoring the code top quality Most of these tests are more expens...
Read more