After more than a decade since Agile Manifesto was published there is a wide spread adoption of agile practices in software industry. Although it had been more prevalent in small and start up companies but in last 2-3 years even banks and big companies have been learning the agile ways. With this increase in agile popularity there is a surge in failures attributed to agile methodology. As part of a research it was established that how unsuccessful Agile has proven to be, the key points from the report are available here. But there are reason for these failures, a great article "How To Fail With Agile:" explains possible causes behind these failures and how teams can avoid these pit falls.
Being a QA on various agile teams I have observed that even for successful agile projects, teams find it difficult to extend agile practices to the test/QA teams. These teams usually have their dev teams following agile but their QA team will still be in waterfall. The reason being, QAs are not able to catch up with the dev team and are lagging behind to cover up with automation and manual testing.
One of the important reasons for this gap is the way teams do estimation. All agile teams follow story or feature estimation as part of their planning process. There are varied number of ways that one can do estimation which can represent either complexity or time. In scrum methodology estimation activity is called planning poker and usually the stories are estimated in fibonacci numbers series : 1, 2, 4, 8.... or they could be S, M, L, XL sizes. During iteration planning meetings (IPM) developers throw these numbers for a given story to get estimation.
But a story other than development work involves testing phase which could be unit tests, acceptance tests, exploratory tests and regression tests. Since developers write unit and acceptance tests they are included in the estimates but the work done by QAs is not considered in these estimates. There could be argument that testing work can be done in parallel with development activities and hence we need not allocate extra time for this. But as part of TDD and BDD developers also share the responsibility of writing tests and setting up test environments. Then there are other testing processes that involves exploratory testing, setting up test data, fixing automation tests and other testing activities that vary with each story. Some times there are stories where QA effort might be more that dev effort.
The best way to make sure that QA teams don't end up being bottleneck for releases they should be included in planning meetings and should be given power to vote & estimate QA effort involved in stories. The QA team might not be bale to contribute much initially but as they get experienced in the estimation process the would be able to get accurate estimates. The QA estimates need not be added to dev estimates instead they should be averaged out and you will get a true velocity of the team.
But a story other than development work involves testing phase which could be unit tests, acceptance tests, exploratory tests and regression tests. Since developers write unit and acceptance tests they are included in the estimates but the work done by QAs is not considered in these estimates. There could be argument that testing work can be done in parallel with development activities and hence we need not allocate extra time for this. But as part of TDD and BDD developers also share the responsibility of writing tests and setting up test environments. Then there are other testing processes that involves exploratory testing, setting up test data, fixing automation tests and other testing activities that vary with each story. Some times there are stories where QA effort might be more that dev effort.
The best way to make sure that QA teams don't end up being bottleneck for releases they should be included in planning meetings and should be given power to vote & estimate QA effort involved in stories. The QA team might not be bale to contribute much initially but as they get experienced in the estimation process the would be able to get accurate estimates. The QA estimates need not be added to dev estimates instead they should be averaged out and you will get a true velocity of the team.
No comments:
Post a Comment