I have chosen to write about Scrum, Agile and eXtreme Programming. It\u00b4s an important topic. Agile and Scrum has a huge impact on the Software Tester. Scrum in itself is a test of the organization.<\/p>\n
If you\u00b4re 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.<\/p>\n
Everyone can test software<\/strong><\/p>\n 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 \u2013 if you want to survive.<\/p>\n Definition of done<\/strong><\/p>\n Definition of done defines what it means when the team says \u201cThis feature is done\u201d. In theory it is a contract between Product Owner and the team. An example of Definition of done could be:<\/p>\n * Unit and integration tested.<\/p>\n * System tested.<\/p>\n * Documentation is written.<\/p>\n * Release notes are written.<\/p>\n * Deployed on demo server.<\/p>\n * No increased technical debt.<\/p>\n 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\u00b4s no good to have a Definition of done without obeying it. It\u00b4s a waste of time, and creates an illusion.<\/p>\n 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\u00b4s done (system testing is done) then the problem disappears. With a weak Scrum Master the team can suddenly become a very dysfunctional team.<\/p>\n Velocity<\/strong><\/p>\n 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.<\/p>\n 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 \u2013 not a good thing.<\/p>\n Sprint Planning and the ready state of the Product Backlog<\/strong><\/p>\n In a Sprint planning meeting, 3 things are important in terms of the Backlog items:<\/p>\n * What\u00b4s to be done is clear<\/p>\n * It has been sized properly<\/p>\n * It has been estimated<\/p>\n 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.<\/p>\n 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.<\/p>\n Sprint retrospective<\/strong><\/p>\n 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.<\/p>\n It\u00b4s 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 \u201cWe don\u00b4t have time for Sprint retrospectives\u201d. It typically happens when the same problems gets mentioned in every Sprint retrospective. Scrum asks the organization \u201cAre you going to do something about it or not?\u201d. If the answer is yes, it will be tested during the next sprint. At the next Sprint retrospective, the problem still exists.<\/p>\n Scrum gives transparency. On a daily basis Scrum gives you all the news \u2013 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\u00b4t want to be faced with something they don\u00b4t want to see. That\u00b4s 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 \u2013 which also typically is censored.<\/p>\n 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 \u201cAgile relationship\u201d 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.<\/p>\n Kasper Sorensen<\/p>\n