Labels

Wednesday, January 16, 2013

The Product Manager and the Agile Testing Strategy

On an Agile project, the application is being built incrementally with every sprint adding to the functionality. As a result of this approach, Developers are constantly adding to the codebase impacting the existing functionality. While Agile software development ensures faster time to market and greater transparency for the stakeholders, it also stands for finding defects earlier in the cycle and raises the bar for quality. Agile testing requires QA engineers on the Agile teams to test quickly, incrementally, and contextually while staying within acceptable defect limits. In this scenario, an Agile QA engineer employs "smart" testing strategies and tactics to meet the demands of an Agile project.

Smart Testing
Smart testing requires the application to be tested incrementally - meaning while the user story is being coded, the QA engineer plans for the test cases and scenarios in the immediate vicinity of the story and tests the application as soon as the developer is done coding. Individual user stories are tested in this manner and when the build is created for the sprint scope then QA accepts the build, regresses the system, and skims over the user stories of the sprint with greater focus on the impact on the surrounding areas of the functionality delivered in the sprint.
As you can well extrapolate, this approach can add to the quantum of build level testing that is done in successive sprints. To optimize on the testing scope vs effort, another facet of smart testing, which is testing prioritized system workflows is undertaken. Testing in this prioritized order while optimizing the effort does introduce some risk which can be handled to some extent by doing adhoc testing around the major workflows.

Product Manager's Contribution
The Product Manager's contribution to the smart testing approach is to validate the workflows that are being tested and ensure that the tests cover features that are indeed the major workflows at the customer end. This validation begins with the review of the Test Plan that QA comes up with at the end of the release planning or sprint 0. The validation continues on during the iteration while reviewing the scope of coverage of the test cases at the user story level. The validation concludes when looking through the prioritized list of major workflows that QA plans to test as the functionality scope increases. 
Additionally, during acceptance testing, the Product Manager can take into cognizance the scope of QA testing and review the product against the acceptance criteria. 

The Product Manager is able to collaborate with QA on the testing strategy by drawing on his/her knowledge of: how customers use the product, features that pre-Sales demo to prospects, the features that are obligatory requirements, and those user stories that effectively out-pitch the competition and find favor with analysts.

In case of a complex product, it may not be possible for a Product Manager to be involved with the Agile teams everyday. In this scenario, the Product Manager's contribution can be scaled by taking the help of a proxy Product Owner who works closely with the Agile teams.

In this way, a Product Manager can ensure that the Product is being built right by having a stake, albeit minor, in the testing strategy of Agile teams.

Tuesday, January 15, 2013

Challenges in conducting Agile Assessments


Some challenges that the Agile Center of Excellence could encounter when conducting Agile Assessments, including suggestions to move past the challenges.

1. When teams look at the assessment as an audit, there could be cover-up and manipulation. An Agile CoE can counter this by stressing on the role of the assessor as a Coach and not as an auditor. For his/her part the assessor should work with the team towards implementing the identified Agile areas of improvement so the assessment is a measure of collaborative effort on the part of the assessor-Coach and Agile team.

2. When a single Agile coach has to cater to the assessments of several teams, it spreads the coach too thin. I dont have a golden number which limits the team-coach ratio, but íf there is a situation where one coach has to work with over 4 teams, then the coach could have the Scrum Masters intervene on their behalf. This approach can help mentor Scrum Masters who can mature into coaches. The flip side would be the added delay and loss in transmission through the Scrum Master to the Agile teams.

3. Continuing on handling the coach-team bandwidth challenge and coupled with coach succession challenges, another approach could be to have a team of Agile assessors essentially members of CoE who are Scrum Masters do the assessments. This approach could help ease a single Coach's onus and build assessment abilities in other scrum masters or coaches.
The Assessor-Scrum Masters begin by observing the team in their work environment and ceremonies, followed by an assessment, and concluding with an action plan as agreed with the Scrum Master of the team being assessed.
The Assessor-Coach should stay with the team for at least 3 to 5 assessments so that they get an opportunity to implement Agile ideas and report to the CoE about the plans ahead for each team so that the expectations from the organization are met.