Scrum, Agile and eXtreme Programming for QA
I have chosen to write about Scrum, Agile and eXtreme Programming. It´s an important topic. Agile and Scrum has a huge impact on the Software Tester. Scrum in itself is a test of the organization.
If you´re already familiar with Scrum and Agile. How well does your experiences fit the description? It is obvious that there is a difference between Scrum, Agile and eXtreme Programming in theory, and the way organizations try to implement it. In the following, I will briefly describe some examples of situations Software Testers in Agile environments can encounter.
Everyone can test software
I have read claims like that from Gurus in the Agile community. Everybody can program if you learn to put a sentence in WriteLine method in C#. Everybody can use a scalpel, but that does not make them a surgeon. When you go to a mechanic or a surgeon you want a specialist – if you want to survive.
Definition of done
Definition of done defines what it means when the team says “This feature is done”. In theory it is a contract between Product Owner and the team. An example of Definition of done could be:
* Unit and integration tested.
* System tested.
* Documentation is written.
* Release notes are written.
* Deployed on demo server.
* No increased technical debt.
For team-moral it is important that Definition of done is not outside team control. A big mistake is not having a Definition of done. Next problem is: it´s no good to have a Definition of done without obeying it. It´s a waste of time, and creates an illusion.
Imagine a situation where the team is under pressure. The software is not unit tested and hardly any integrations tested. Documentation is not fully completed and the team needs to be finished. The problems end up at the tester. If the environment can pressure him to say it´s done (system testing is done) then the problem disappears. With a weak Scrum Master the team can suddenly become a very dysfunctional team.
Velocity
Velocity is used to describe the team and as a diagnostic tool. Not having a Velocity is a problem. It makes it hard to Release Plan properly. Having a velocity but not obeying it is another problem. Obeying the velocity is important, if objective is to achieve team commitment.
If the Scrum Master correctly monitors the velocity a pattern will emerge. One pattern is yo-yo velocity. The velocity in Sprint 1 is 80, but in Sprint 2 only 45 because of fixing things and debugging – not a good thing.
Sprint Planning and the ready state of the Product Backlog
In a Sprint planning meeting, 3 things are important in terms of the Backlog items:
* What´s to be done is clear
* It has been sized properly
* It has been estimated
A team can under-commit in a Sprint, but more often a team will be over-committing. Sometimes the over-committing is the result of unrealistic expectations. The tester is squeezed and has to work in the last weekend of every Sprint.
If the velocity for the team is 30 Story Point and the team has to deliver 300 Story Points in 5 Sprints there is an obvious problem. You have just revealed a death march. The team marches on without a chance of success.
Sprint retrospective
The objectives of the Sprint retrospective are to make process improvements and find ways to increase velocity. Two main questions are asked at Sprint retrospective. Question 1: What went well during the sprint? Question 2: What could be improved in the next sprint? Without the Sprint retrospective the team is stuck at the current velocity forever, and never gets better or improves the quality.
It´s the place where the team can identify root causes of problems. A warning sign is when the organization stops the Sprint retrospectives with an excuse like “We don´t have time for Sprint retrospectives”. It typically happens when the same problems gets mentioned in every Sprint retrospective. Scrum asks the organization “Are you going to do something about it or not?”. If the answer is yes, it will be tested during the next sprint. At the next Sprint retrospective, the problem still exists.
Scrum gives transparency. On a daily basis Scrum gives you all the news – good AND bad (the hype about Scrum typically only tells us about the good news). Scrum is a test of the strength of an organization. Only 30-35% of the organizations trying to implement Scrum successfully implements it. Organizations don´t want to be faced with something they don´t want to see. That´s the reason why Sprint retrospectives are cancelled and censored by management (despite the fact that the team is supposed to be self-managing). Another recurring problem is the Product Owners incapability to prioritize the Product backlog – which also typically is censored.
As described in this article you as a tester can use Scrum to diagnose the situation. Is the organization strong and mature enough for Scrum? Does the organization have an “Agile relationship” with the customer? Who is cooperating with you, and who is not? Who is selfish, and who is not? After trying to fix the problems and getting transparency from Scrum, you can get a glimpse of the future, and decide if you want to stay or move on.
Kasper Sorensen
Join the discussion at Everything_QA
Tag:agile, agile testing, extreme programming, qa, scrum, sprint, testing