How to fit QA in Scrum Sprints

Many scrum teams have a tough time accommodating QA in the same sprint. They end up creating separate QA sprints and staggering it with development sprints. Thus development happens in one sprint and QA in the next. So agile, isn't it? In the true spirit of Scrum, stories should be finished with the necessary testing in the same sprint.

Here is how it happens. Let's say our sprint length is 3 weeks. We have two dedicated QA persons assigned to our project. They are a part of the team. First two weeks developers keep working on their code (and unit tests) and QA persons play ping-pong. In the third week developers start delivering code to QA. Now suddenly our QA has work! As all the tests are manual, one week doesn't suffice. Some stories get demonstrated in the sprint demo without testing! The remaining QA work then gets included in the next sprint. They finish the remnant work in a week and again play ping-pong for one week. Thus the staggered cycle continues.

There is only one way to break this cycle – QA automation. Automating tests with a tool like Selenium saves testing time considerably. It increases test development time, but it reduces testing time considerably. Thus when developers are coding, QA persons can develop automated tests instead of playing ping-pong. Once developers start delivering code to QA, all QA has to do is run the automated tests!

I have been playing with Selenium recently. It's really a great open source tool for QA automation. I found Selenium RC very useful for web based applications as it allows automated tests to run in various browser environments - Firefox, IE etc. Furthermore, Selenium tests can be developed in Ruby, Java, Javascript, Perl, PHP, Python and even .NET! QA can choose the easiest option for them.

Handling QA in Scrum environments requires a paradigm shift. Many companies don't have QA persons with coding skills. In such environments developers need to step up and develop automated tests. Gone are the days when a person went manually through each and every page of your website. Scrum requires much more efficient QA and thankfully Selenium-like tools provide the necessary technology.

Meetings v/s Mailing Lists

Some companies have a meeting oriented culture. They summon a meeting to solve each and every problem, however simple the problem may be. A meeting for designing a database table, a meeting for reviewing code, a meeting for clarifying a story, a meeting for getting extra RAM in your computer etc. If you try to measure the amount of time spent by employees in meetings per week, it might surprise you. Meetings are an inefficient way of discussing a topic. I prefer to discuss issues via mailing lists over calling for meetings. I and a friend of mine - Ken Weiner came up with the following advantages of mailing lists:

• Mailing lists are more productive, people don't have to repeat what they said as they get enough time to digest it.

• Email keeps track of the entire conversation. Some wikis such as Confluence also have a way of archiving a mailing list to make it searchable.
  

• Every person gets enough time to read the email and respond to it. In a meeting, one might not get enough time to respond.

• In multi-location environments, mailing lists are the best ways to keep everybody informed about everything. That's how the entire open source development works. Video conference / conference calls may not be feasible every time.

• Attending a meeting consists of higher context switching. You might be in your best productive time and you have to drop everything to attend a meeting. I personally hate to do that.

• In meetings some personalities can overpower others because of their voice, posture or even position etc. Mailing list avoid such overpowering.

• Sometimes uninterested parties attend meetings for the sake of attending. Discussing a topic on mailing list can certainly avoid this. The uninterested person can simply delete the email by looking at the subject.
  

Try to discuss as much as possible on mailing lists instead of calling for a meeting. Mailing lists can serve as an excellent reference for future. Some collaboration tools such as CollabNet can even capture emails sent with an issue number in the subject as a comment to the issue. Tools such as Crucible will help you in doing efficient code reviews. Wikis can help you discussing a topic as well as archiving a mailing list. As soon as you start your Scrum project, you should setup a mailing list for all the stakeholders. You will be pleasantly surprised with the results.

Point Score and Work Remaining in hours

A day before sprint 1 was about to end, the scrum master, team manager and scrum-trained developer were sitting in a meeting room trying to figure out the co-relation between velocity and estimated hours. The question in front of them was - What is the guideline for the team to choose stories? Should we give them a velocity number or the team should make a decision based on total number of available developer hours?

If we are going to use the total number of available hours for picking up stories from the backlog then what is the purpose of velocity? Why do we estimate stories in points? Why use different units? Why not just use hours so that this whole estimation is uniform in hours ?

They had only one sprint worth of data. The team was new to Scrum. The manager felt strongly that they should give some guideline to the team so that the team does not overburden itself or does not take up little work. He also wanted to know the correlation between points and hours.

Here is what Ken Schwaber says in his book - Agile Software Development with Scrum "This (in our case the questions raised above) question indicates the difficulty shifting from a pert chart-based, time reporting structure to an empirical approach"

There is a difference between assigning a point score for a story and estimating hours for a story. Point score is the effort. Work remaining is the time (hours). The point score for a story is an approximate score. This score is used in velocity calculations. Product owner and the scrum master use this for release estimation and planning.

The team only uses estimated hours while picking stories for a sprint. They pick a story from the backlog and estimate the number of hours after clarifying requirements with the product owner. Estimating hours require more understanding of the story than assigning a very rough point score. Furthermore, estimation should be preferably done for tasks - at a finer granularity than story. A story should be divided into multiple tasks such as testing, coding, writing unit tests, coding UI layer etc. That makes a story more predictable. The team only deals in number of hours and specifically remaining number of hours. On realizing this, the manager stopped deriving the correlation between effort and time.

Why Agile is hard?

I was talking with some developers and a manager of a company in LA about their Scrum implementation. They told me about various problems they faced - no buy in from business, inability to estimate exact dates etc.

Interestingly, at the same time, I happened to listen to Why Agile is Hard - The java Posee round up 08 podcast. Same problems were discussed in the podcast. The podcast mentions many interesting books and websites for agile followers. If you are an agile devotee, you should definitely listen to this podcast.

The developers from the company also talked about implementing Scrum only in the engineering team without getting buy in from the business. The business will give them a document of requirements which will be translated into user stories by a team lead.

One developer even told me about doing database design out of scrum sprints to avoid future changes. I think this is fundamentally wrong and against the spirit of Scrum. This is a typical case when unit tests are not implemented. Code without unit tests is difficult to re-factor hence developers tend to think about future requirements; there by defeating the purpose of iterative and incremental approach

Their other problem was accommodating QA in a sprint mainly because the testing was manual. I tried convincing them QAing within the sprint instead of doing staggered QA sprints. I suggested that they should try to automate the tests. While developers are working on the code, QA should work on creating / changing the automated tests.

They hadn't read the bible - Agile Software Development with SCRUM (Series in Agile Software Development). I suggested them to start with the book. Careful reading of this book will answer many of their questions. I also agree with one of the person in the podcast - start with small changes. Specifically for people who don't have unit tests. They need to start with unit testing first.

Company Policies and The Team's Design Choices

Our company is becoming more and more corporate day by day. Ironically as it becomes more corporate, it tries to adopt more agile methodologies.

One of the company's director is an expert in databases. Some teams in the company regarded him as a data architect. Eventually he was officially appointed as the data architect few months ago. We were asked to consult with him for any database schema design or other database related issues.

The data architect then took it upon himself to standardize solutions across various teams. He came up with a database schema design for a feature and proclaimed that every similar feature should use the same schema. Everybody, albeit reluctantly, agreed with his schema design. Now when a similar feature needs to built as part of the sprint, the developer who was reluctant (let's call him "A') in accepting the architect's schema design has to face the data architect again.

'A' rebelled and came up with a simpler easier domain specific schema design instead of the architect's generic schema design. He emailed the design to the team on the mailing list. A team member (let's call him 'B') spotted the inconsistency and asked the developer to reuse the architect's schema. This attracted manager's attention and the manager too asked 'A' to get the data architect's approval.

A meeting was setup to discuss the design with the architect. As expected, the architect and the manager opposed the idea of deviating from the standard, already agreed upon design. 'A' is very unhappy as he will have to now code a complicated solution.

This incident raises many questions. Should the scrum master intervene? He did not and he should not. Design is the team's responsibility and the scrum master should completely leave it up to the team.

What is the manager's role? Should he be involved? This is the grey area. In an ideal scenario, the manager should let the team figure out the design. But in large corporations, they often have policies and procedures which cannot be thrown away because one team is implementing scrum.

What should the team do? Other team members should talk to the unhappy developer and try to comfort him so that his productivity is not affected.

Day 1, Sprint 2 - Who does QA?

Sprint planning meeting went well but in spite of spending 2 hours and 40 minutes we could not allocate all the time at hand. We had about 700 hours at hand, including QA. We were able to allocate only 430 hours in 2 hours and 40 minutes. There were two QA persons. They ran out of all their time. How do we handle this? We had following options:

1. Scrum Master goes to QA manager and demands more QA resources for the project
2. Developers take up some QA work so that amount of QA work required can be divided in QA persons and developers.
   

Scrum Master mentioning second approach was met with wide eyes from the team! No decision was taken in the planning meeting. We had to stop the meeting because the conference room was booked then after.

The Scrum Master spoke with QA manager but QA manager expressed his inability to get more resources. The idea of doing QA was discussed a bit in the morning meeting, but since most of the team was not interested in testing, the Scrum Master abandoned the idea of asking the team to qa their peers work.

It was decided later in the day that the team will work on infrastructure or any other issues they want to work on in their remaining time. That work will be considered "extra work" and will not be demoed in the sprint demo.

In true spirit of scrum, I think we, the developers should have taken up job of testing their peer's work. But I can understand that this is not easy to sell it to developers.