Thursday, December 13, 2012

I have decided to upgrade my present Certified Scrum Master
certification to the Certified Scrum Professional level – the highest
level offered. Fortunately enough, my company is in the Agile transition journey and i got a chance to read & learn many agile scrum practices which kind of helped me to pass by Certified Scrum Professional (CSP) exam.I have started preparing 4 weeks before the online test. With $300 at stake, there is no
way I want to fail. The CSP handbook gives you a list of reference
books. The list being so big, it's sure that Scrum Alliance want to
ensure that people just don't prepare only for the exam.First & foremost thing i did was going through online scrum training material provided by Michael James which also has some interesting quiz questions along the way.

Monday, August 27, 2012

I have completed reading 2 parts of "Succeeding with
Agile: Software Development Using Scrum - By Mike Cohn" and its explaining
some of the fantastic attributes of Scrum Master. I am pretty impressed with
the attributes of scrum master explained by Mike Cohn.

Responsible

A good ScrumMaster is able and willing to assume
responsibility. That is not to say that ScrumMasters are responsible for the
success of the project; that is shared by the team as a whole. However, the
ScrumMaster is responsible for maximizing the throughput of the team and for
assisting team members in adopting and using Scrum. As noted earlier, the
ScrumMaster takes on this responsibility without assuming any of the authority
that might be useful in achieving it.

Humble

A good ScrumMaster is not in it for her ego. She may take
pride (often immense pride) in her achievements, but the feeling will be “look
what I helped accomplish” rather than the more self-centered “look what I
accomplished.” A humble ScrumMaster is one who realizes the job does not come
with a company car or parking spot near the building entrance. Rather than putting
her own needs first, a humble ScrumMaster is willing to do whatever is
necessary to help the team achieve its goal. Humble ScrumMasters recognize the
value in all team members and by example lead others to the same opinion.

Collaborative

A good ScrumMaster works to ensure a collaborative culture
exists within the team. The ScrumMaster needs to make sure team members feel
able to raise issues for open discussion and that they feel supported in doing
so. The right ScrumMaster helps create a collaborative atmosphere for the team
through words and actions. When disputes arise, collaborative ScrumMasters
encourage teams to think in terms of solutions that benefit all involved rather
than in terms of winners and losers.

Committed

Although being a ScrumMaster is not always a full-time job,
it does require someone who is fully committed to doing it. The ScrumMaster
must feel the same high level of commitment to the project and the goals of the
current sprint as the team members do. As part of that commitment, a good
ScrumMaster does not end very many days with impediments left unaddressed.
There will, of course, be times when this is inevitable, as not all impediments
can be removed in a day.

Influential

A successful ScrumMaster influences others, both on the team
and outside it. Initially, team members might need to be persuaded to give
Scrum a fair trial or to behave more collaboratively; later, a ScrumMaster may
need to convince a team to try a new technical practice, such as test-driven
development or pair programming. A ScrumMaster should know how to exert
influence without resorting to a dictatorial “because I say so” style.

Knowledgeable

Beyond having a solid understanding of and experience with
Scrum, the best ScrumMasters also have the technical, market, or other
specialized knowledge to help the team pursue its goal. LaFasto and Larson have
studied successful teams and their leaders and have concluded that “an intimate
and detailed knowledge of how something works increases the chance of the
leader helping the team surface the more subtle technical issues that must be
addressed” (2001, 133). Although ScrumMasters do not necessarily need to be
marketing gurus or programming experts, they should know enough about both to
be effective in leading the team.

Friday, August 3, 2012

We have learned a great deal about Agile testing. This article presents ten tips for Agile testing based on our experience. However, don’t expect to find the perfect test approach for your company or software project in this article. That is still something you will have to find out yourself!

1. Integrate the testers in the development teams

Teams are responsible for delivering software that meets expected requirements and quality. However, if we want teams to test the software, we must give them the knowledge to do it right. Testers have that knowledge. By integrating testers into the development teams, teams obtain the skills they need to test their software. When you try this, make sure you choose the right mix: one tester for three programmers is a fair but minimal number.

2. Use risk based testing

You can never test everything with the same (extensive) depth; even in a waterfall project you have to make choices. In an Agile project all the activities are time boxed so you have to make choices about how extensively you want to test each feature. We use a risk based approach to determine which test activities we are going to carry out for a feature during the iteration. The risk level of every feature is determined by the customer and the teams. It is a very transparent process so the customer knows exactly which test activities are executed for every feature.

3. Have testers review unit tests

In our organization the developers are responsible for creating and maintaining the unit tests. Unit tests are a very important part of our test harness. Developers often have a different way of thinking; for example, they tend to test only the success scenario.

To create unit tests that are as good as possible, our testers review the unit tests for all our high-risk items. The review has two advantages. First, the unit tests are improved because testers and developers supplement each other: the developer knows where the weak places in the source are, and the tester can use his knowledge of testing to give tips to improve the unit tests. Second, the testers know exactly which test cases are executed in the unit tests and can concentrate on executing other (e.g. higher-level) test cases.

4. Create a test automation framework and appoint a toolsmith

Automated testing is very important because new features and refactoring can introduce problems that can be difficult to find. By using an automated test framework, we can maintain quality levels during the iteration. Our testers are able to create new tests easily and quickly in the framework. We have a dedicated test engineer (we call him a tool smith) that maintains and optimizes the test automation framework, reviews the new automated tests of the testers and analyzes the daily test results. Testers in the teams can spend more time creating and extending automated tests because the toolsmith supports them.

5. Display quality metrics in a public location

Almost every software project has a problem registration system, automated test results, and in some cases nightly or continuous build results. But how often do team members look at the results or count the open problems? We installed a monitor in the coffee room that displays the actual metrics of the currently open problems, the percentage of successful unit tests, the percentage of successful nightly builds, and the current state of the continuous build. By displaying the metrics in public the teams are confronted with the information. The information is no longer just a number in a system or a record with some other information in a metrics database.

6. Add a test scrum

One advantage of having a separate test team in one room is that the communication between the testers is improved. When you have a project like ours where the testers are distributed across several teams, the communication becomes more difficult. To solve this problem, we use a test scrum to align the test activities. Our test scrum is held twice a week and every team is represented by one tester. The test scrum is a scrum like the daily team scrum but focused on test activities. The test manager is the ScrumMaster of the test scrum.

7. Implement test retrospectives

Every team in our project holds a retrospective meeting at the end of the iteration. In the retrospective, the team discusses the process: what went well and what went wrong. The testers in the team learn and discover new ways to improve their tests. The sharing of knowledge with testers from the other teams helps everyone.

We have a test retrospective every iteration so the testers can exchange knowledge and experience and discuss problems they have. It is important that the retrospective is only related to test issues; you shouldn’t discuss team issues (they should be discussed in the team retrospective). As with the test scrum, the test manager is the ScrumMaster of the test retrospective.

8. Plan for open problems

We try to fix all the problems that we find during the iteration in that same iteration, but sometimes we end the iteration with open problems. The best way to handle open problems is to add them to the sprint backlog for the next iteration. By explicitly planning the management of the open problems, the chance that they are “forgotten” and pile up is very small.

9. Remember: Testing is still testing

When you test in an Agile software project you can still use the “traditional” test techniques. We use exploratory testing but also apply test techniques such as boundary value analysis, equivalence partitioning, cause/effect diagram, and pair-wise testing. Which test technique we choose for a feature depends on its risk category. Exploratory testing is used in every category; but if the risk is higher we also apply more formal test techniques. The challenge for the tester is to use a formal test technique without delivering extensive test documentation.

10. Start doing it!

The last but most important tip is start doing it! Don’t talk too much about how you are going to introduce testers, or which test approach is perfect for your organization. You are going to make mistakes or discover that the chosen approach doesn’t fit your organization. That’s a given. But, the sooner you start, the sooner you can begin learning and improving your test approach. With the retrospective meetings, you have the opportunity to adapt your test approach every month.

Saturday, February 11, 2012

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 beknown 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

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 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 itemswhich 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