Thursday, February 16, 2012

Agile Scrum Training Modules


Online training modules with built in quizzes that have been shown to improve scores on exams CSM/CSP/CSPO

SEVERAL ENJOYABLE ANIMATED E-LEARNING MODULES:





READING:

a. The six-page overview of Scrum at http://ScrumReferenceCard.com

b. The four values of the Agile Manifesto at http://AgileManifesto.org

c. The twelve principles of the Agile Manifesto at http://AgileManifesto.org/principles.html



Saturday, February 11, 2012

Handling common issues in Scrum Testing

I would like to point out some of the common issues/challenges which we have faced while following the agile/scrum testing. We have learned a lot over a period of time and we are trying to find right approach which would eventually help us to improve our scrum testing practices.

Challenge1: Most of the time QA finds quite a lot of regression issues during final stages (stabilization weeks) which leads unpredictability on the product release. What is the best way to do the regression testing to capture defects in the early stages?

Solution: You need to do incremental regression testing along the way, probably every sprint.  This takes careful collaboration with the developers to figure out what to release to the test lab every sprint so that it can be regression tested.

Challenge2: What would be best way QA can work with development to understand the complete test scenarios / cases?

Solution: QA needs to talk to the Dev. team constantly. Be in their grooming sessions. Act as one team. Work as one Team. Be SMEs for them during development, so that the testing is done on their box as part of their work before it ever gets to you.

Challenge3: Most of the times QA has been pointed out as a root cause of delay in release (which is a trend all over the world), even though they do get better every release but we are not their yet to show our class. What is the best way to improve QA process here?

Solution: Integrate it into the development process. Make sure QA & Dev works together as one team.

Challenge4: What are all the QA best practices we can follow (as per scrum)?

  • Don’t separate verification testing from development. By the time QA gets to the code, it must be known to work, the only question should be validation that it does the right thing.
  • Do validations constantly, either intermingled with development, or as a separate thread. Think of the code as leapfrogging from Dev to QA.
  • Every sprint a new build is dropped on QA, it does validations (not verification, that’s done in dev, but possibly by testers on the team) to find new stories that are dropped back on the backlog. The PO prioritizes them alongside everything else, and it keeps going.
  • Always remember that it’s about the product, not the code. The product is not finished until it’s been validated and defects have been corrected. Therefore, the developers are not finished until that happens, either.
  • Last but not the least…”It must be thought of as one big team, not two teams… “


This is exactly what i am proposing to my management to get the ball rolling in the right direction but it has its own challenge:-)

Wednesday, February 8, 2012

Potentially Shippable


The phrase "potentially shippable" has little to do with shippability. 


Here is the definition from Ken:potentially shippable means that /the 
increment consists of thoroughly tested, well-structured, and 
well-written code that has been documented and built into an executable 
reviewable by the Stakeholders/ [Ken Schwaber, /The Enterprise and 
Scrum/, Microsoft Press, 2007, pg. 112, paraphrased]. 


As you can see, it has nothing to do with amount of functionality; it has everything to with technical quality.


Not many people agree with this in my company at least but i would really like to push on this if i would been a product owner for any release or a product in future.

Monday, February 6, 2012

Iteration 0 - Time line


Iteration 0 is typically the duration between the initial “Discovery” and “Evolve Phase” of a software project.  As such, there is no formula or a number to determine the iteration 0 duration, which suits all the projects. 

  
I would like to use the following check list to decide the duration 
1. Duration of a release :  If the duration of the release is small, then one should be cognizant of spending a lot of time on Iteration 0.  
For a 6 months or 1 year release ideally 1 week of  Iteration 0 should be good enough. 

2. Pending back log items : These are the items which could negatively impact starting of Evolve phase.  Based on my experience over a period of time, I have managed to create a checklist of things typically needed to start the actual development.   

Some of them include: 
     a. Development and testing environment readiness (licenses, Hardware, etc) 
     b. Is Backlog healthy and ready to support one or two future iterations 
     c. Do we have the team ready with the right skills 
     d. Does the team need any training before they start the coding 
     e. Does the team have all necessary tools to start the project 


     f. Do we have all the user stories acceptance/done criteria with the ranking/prioritized      
If  the team does not have basic things, then there is no meaning in starting the development and waiting in between. 

3. Did it exceed > duration  of 1 iteration ? 
The iteration duration varies from project to project, and stays between 2 – 4 weeks (max) in most of the good Agile projects. 
I always tend to suggest that the Iteration 0 should not exceed duration of one iteration.  In my world, if Iteration 0 needs more time to finish then there are more challenges ahead for this project