The Agile School

In traditional software development model QA/testers were actively involved in only certain phases of the project. After development finishes the coding the entire project was handed over to QA. In many cases QA and developer wouldn’t even know each other. All the communication will be through email or bug tracking system. I remember one instance when my project manager relocated the entire QA team to another building!!! He didn’t want the QA and development team to communicate face to face. We had different competency centers for QA and development teams with different career objectives and career ladder.   The QA team had a separate identity, a feeling of ownership over an entire phase of product. They were called the gatekeepers of quality. Don’t fear the change But in scrum apart from the sprint cycles there are no definite phases. In scrum there is a big change in the way team operates and interacts. In scrum there is no differentiation between a QA and developer. ...

Scrum/Agile demands frequent delivery of software. Most of the companies develop software in a sprint of two weeks. ( How to choose Sprint duration? ) But many companies don’t release software that frequently. According to scrum principles software at the sprint end should be of shippable quality. But really is this the case?  Many teams who diligently deliver the software periodically complain that because of frequent release they are not able to fix all the bugs. Because of the number of bugs they have an affinity for longer sprint cycles. But in reality there is no co-relation between the sprint duration or release duration and the quality of the software produced after each sprint. Slow down to move fast If you or your team is in a vicious cycle of releasing software with bugs release after release – then stop what you are doing, review the process you are following Review the definition of “done” – Schedule a meeting with all stakeholders, decide on a definition of d...

• I can push bugs to backlog. • We can complete a story without fixing all the bugs • I have to finish all the stories first; the bugs can be fixed later. • Before the release I will have a maintenance sprint which will have only bug fixes. The list is big. If you are doing anyone of the above please stop doing it before it is too late. One of the fundamental requirements of scrum is to have a shippable product by the end of the sprint. There is no benefit in "finishing" maximum stories with lots of bugs. Scrum places high importance in the quality. With this approach of not fixing bugs will lead to accumulation of bugs & in few weeks you will have 100 + bug and you may spend couple of months fixing it. The cost of pushing bugs sprint after sprint will increase exponentially. The bug which could have been fixed in 30 minutes today will take couple of hours after 2 months!!! I have faced this problem in many teams I have worked with. My simple advice is to sl...

You had a sprint demo and it failed miserably. A lot of stories were not fully tested. QA team is complaining that they don’t have any work during the first part of the sprint and they are overloaded during the last few days of the sprint. This looks very familiar. For months we will work casually and during the last two months of the release there will be lots of last minute changes and bug fixes. It will be a virtual hell with late night hours. People will be coming early and going late (Many don’t even go home, they stay at office). Now this looks familiar. We have seen this in many projects. Scrum promised that such thing won’t happen again but still we can see such mini waterfall in our sprints. If you are seeing such issues, you should have a retrospective immediately. A scrum team should be cross-functional. I will start with the following questions • Why can’t the developer’s cross verify each other’s work? • If testing is the bottleneck why can’t everyone help by tes...