Agile teams often find themselves in a difficult position when it comes to accountability of the work done. Agile rightly promotes collective owenership, in the codebase, build environment, and even the story wall.While it is extremely useful to have polyskilled people in the team, it should not hamper the need for accountablity on the delivery of a Story, A Feature and A Release.
One way to build this accountability is to ask the critical questions when there are issues in delivery, and tie it with feedback so that the issue doesnt manifest itself again. This can also be coupled with a bit of coaching.
Examples
Scenario 1 : Customer's testing team finds a bug on a story which was delivered to them.
Question (to team QA) : Is this bug breaking the acceptance criteria of the story ?
QA : Yes
Question (to team QA) : Why was this bug not caught when we tested this story ?
QA : Well, this was working fine on the build I used. It broke in the build given to the customer for testing
Question (to team QA) : Why did we not catch this when we ran our automation/regression suite ?
QA : That is because we have some QA backlog on the automation front. This test isnt yet been added to the automation suite
Feedback (to team QA) : Well, that means we need to catchup on our automation first, before developing anymore stories. Now you understand how bad it looks when a basic bug is found during customer testing. Please take this as a challenge that from now on, any stories you test and give to customer, the customer should not be able to find any bugs in them. We should do all that is required so that a story does not fail at any point again.
Scenario 2 : QAs find some basic bugs during testing of a story. A bug which breaks a happy path scenario
Question (to team Dev pair) : Why was such a basic bug not caught during development ?
Dev : Thats because we had to refactoring as a part of another story which ended up breaking this piece of code.
Question (to team Dev pair) : Why were there no unit tests around this piece of code then ?
Dev : Well.. The unit tests were missing because I was finding it difficult to write tests for this piece
Feedback (to team Dev pair) : We now know that having unit tests around this would have ensured that this code would not have broken during a refactoring session. Simply put, if we had test driven the whole piece, we would not have ended up in this situation. I think we need to practice TDD more religiously. in the team. Let us have ahuddle to see how we can improve this. (Maybe look at some coaching on TDD)
It is the Iteration Manager's role to actually ask these questions and make the team retrospect their delivery, time and again, and learn from mistakes.This will allow the team to build more accountability on the work that is delivered.
One way to build this accountability is to ask the critical questions when there are issues in delivery, and tie it with feedback so that the issue doesnt manifest itself again. This can also be coupled with a bit of coaching.
Examples
Scenario 1 : Customer's testing team finds a bug on a story which was delivered to them.
Question (to team QA) : Is this bug breaking the acceptance criteria of the story ?
QA : Yes
Question (to team QA) : Why was this bug not caught when we tested this story ?
QA : Well, this was working fine on the build I used. It broke in the build given to the customer for testing
Question (to team QA) : Why did we not catch this when we ran our automation/regression suite ?
QA : That is because we have some QA backlog on the automation front. This test isnt yet been added to the automation suite
Feedback (to team QA) : Well, that means we need to catchup on our automation first, before developing anymore stories. Now you understand how bad it looks when a basic bug is found during customer testing. Please take this as a challenge that from now on, any stories you test and give to customer, the customer should not be able to find any bugs in them. We should do all that is required so that a story does not fail at any point again.
Scenario 2 : QAs find some basic bugs during testing of a story. A bug which breaks a happy path scenario
Question (to team Dev pair) : Why was such a basic bug not caught during development ?
Dev : Thats because we had to refactoring as a part of another story which ended up breaking this piece of code.
Question (to team Dev pair) : Why were there no unit tests around this piece of code then ?
Dev : Well.. The unit tests were missing because I was finding it difficult to write tests for this piece
Feedback (to team Dev pair) : We now know that having unit tests around this would have ensured that this code would not have broken during a refactoring session. Simply put, if we had test driven the whole piece, we would not have ended up in this situation. I think we need to practice TDD more religiously. in the team. Let us have ahuddle to see how we can improve this. (Maybe look at some coaching on TDD)
It is the Iteration Manager's role to actually ask these questions and make the team retrospect their delivery, time and again, and learn from mistakes.This will allow the team to build more accountability on the work that is delivered.
No comments:
Post a Comment