Sunday, November 22, 2009

When should QA be engaged in an iteration?

Someone going through my blog recently emailed me a question about when QA should be engaged in an iteration - should it be in the middle of the iteration or should it be at the end of the iteration? I believe the hidden question that the gentleman had was, what can QA accomplish in the very first few days of the iteration, while development is busy designing interfaces and coding to stories?

According to me the QA team should be engaged throughout the iteration. QA function is an integral part of the Scrum team. They are involved in planning meetings, they have stories just like development engineers and they have tasks to which they report everyday at the daily standup. The QA team brings a different perspective to the scrum team and plays a very important role in the scrum team. They help the scrum team meet the "Done" criteria for each story.

So what are the few activities that QA team members in a scrum team can help with?
  • The QA team can work on design of integration and Acceptance tests that will help development ensure the stories are developed to Product Owners expectation. 
  • The QA team can work with development on creating Mockups and generating dummy data to which they can start writing automated tests until the real interfaces are available.
  • The QA team can help prepare hardware setups in advance, if needed. So when the code is ready there is no delay verifying the stories
  • They can run the Performance and Scalability tests and ensure P&S guidelines are met.
  • They can run manual tests on nightly builds to make certain new functionality is coded to requirements and no regressions are introduced.
  • They can verify and close the defects fixed by the development team.
  • They can open new ticket for all the issues encountered during their daily testing and help set high quality standards for the code under development.
In short, QA function is a very important function in the scrum team. I have heard comments like ‘Developers can play the role of QA engineers if there is shortage of QA resources’. But, honestly QA brings a different mindset to the scrum team - most of the developers think "How do I make this work" and QA brings the mindset of "How do I make this NOT work".

Tuesday, November 10, 2009

Making Release prediction on an Agile Project?

Let me show a very easy way of how a release can be predicted using an example.

Let's say, for a particular product under development, there are 5 scrum teams. Each team has special expertise and they contribute to a very specific area of the product i.e. UI, Infra, Security, etc. For this exercise also assume there are 20 epics that need to be developed before the product can be shipped to the customers. The management is trying to figure out a tentative schedule that can be published to the customers with enough confidence. How do we do it? The simple answer is using "Velocity".

And here are the steps to achieve it

Form a core team with subject matter experts from each of the 5 scrum teams, include the product owners and the Architects. This core team should breakdown each epic into sizeable stories that can be estimated.

These stories should then be assigned to respective teams. The output of this exercise might look like this.

Team A = 30 stories
Team B = 20 stories
Team C = 25 stories
Team D = 40 stories
Team E = 35 stories

The next step is to ask teams to do some high level story point estimation using planning poker for their assigned stories. Note that these estimations might not be very accurate, as most of these stories might not be granular enough to start work on. Let the team take a stab using their judgment and come up with estimations for each stories. Add story points for all the stories for each team and come up with an aggregate number for the overall effort. The output of this exercise might look like this.

Team A = 30 stories, 200 story points
Team B = 20 stories, 300 story points
Team C = 25 stories, 350 story points
Team D = 40 stories, 150 story points
Team E = 35 stories, 400 story points

You also need to determine the average velocity at which each team delivers business value. It sounds simple, but based on my experience, it can take as many as 6 to 7 iterations to predict with confidence what an average velocity of a team is. Now let's say these teams have been together for a while and are self-organized and their average velocity might look like this.

Team A = 20
Team B = 30
Team C = 25
Team D = 10
Team E = 25

Based on these numbers, you can easily calculate how many sprints the team will take to deliver the stories in their backlog. Here's the output after calculation

Team A = 30 stories, 200 story points, 200/20 = 10 iterations
Team B = 20 stories, 300 story points, 300/30 = 10 iterations
Team C = 25 stories, 350 story points, 350/25 = 14 iterations
Team D = 40 stories, 150 story points, 150/10 = 15 iterations
Team E = 35 stories, 400 story points, 400/25 = 16 iterations

Based on this calculation, you can easily predict that it will most likely take 16 iterations to have a release candidate. And if each iteration is of 2 weeks, it will take approximately 8 months to have a potential release.

Friday, November 6, 2009

Agile Retrospectives...

Recently I conducted an iteration Retrospective for one of the Scrum teams which resulted in a good discussion. The feedback helped in making some specific decisions for the team. These decisions had to be communicated to management as this team decided to do things a bit differently than other teams.

One question raised by management was if the Retrospective notes could be shared with everyone in the organization? 

According to me, Retrospective is a private meeting that the team conducts within itself. If retrospectives are conducted correctly, the team will show you exactly "what went well" and should be continued and also "what did not go well" and needs improvements. The "what did not go well" session could result in some heated and healthy arguments at times even with good facilitation. The question is, should this be shared outside this team? I guess, not. But at the same time, the things going well should be shared with the outside forum. Firstly to encourage and praise the team, and secondly so other teams can benefit from their experiences. 

But, what about things not going well? Should they be shared? My advice is, anything that could impact the team's performance or demotivate them, should be avoided at any cost. The notes can be shared, but should be filtered if it's going to be public knowledge. At the same time, management should be informed about the challenges the teams are facing and improvements the team plans to put in place. This way, management can help remove any roadblocks or impediments.


Thursday, November 5, 2009

My inferences from Agilepalooza - A Question on Legacy code

Let's continue this blog on the theme of AgilePalooza discussions...

I had a question on what is the correct way to handle legacy code that is inherited by the team that has no unit and integration tests? How does the team confirm that any new feature being developed has not introduced regression into the legacy code base? Should the team spend time in developing integration tests for legacy code before new features are implemented? 

These questions generated lots of good discussion at the AgilePalooza session. I was surprised that there are no simple answers to these questions. Most of Agile projects, according to the speakers experiences, start fresh.  I tend to agree with the exception that, there will be instances where it would be easier to inherit ready made modules rather than develop from scratch.  

Here are some possible answers that came out of the discussion panel

  • Don't worry about legacy code too much. Ensure all new development happens with Agile/Scrum practices i.e. proper unit tests and Integration tests, etc...
  • Dedicate some time in every iteration for performing manual testing to catch regressions.
  • If you are working on Legacy code during new feature development, take some time to organize that area of the code. Add unit and integration tests for that part of the code .With time the code can be re-factored and overall  test coverage can be improved.
  • The most convincing answer according to me is - Encapsulate legacy code into end to end functional/integration tests before new feature development begins. For any new feature under development these tests would help determine if any functionality is broken. 

In short, there's no textbook definition of how legacy code should be tackled in Agile development. Each project team has to analyse and make a decision for themselves on how much they want to invest upfront to tackle legacy code that would help them be more agile.

Wednesday, November 4, 2009

My inferences from AgilePalooza

It’s been a while that I have posted a blog and I had promised myself today to put my thoughts on events over the past week or so. First off, things are getting too busy at work with new assignment of Scrum Master Duties, in addition to a full plate of work I already had. But no complains there as I enjoy being a scrum master and eventually what matters is the satisfaction I get on the contribution I made to the success of a project.

Last week we had an entire day event “AgilePalooza – EMC Private day” organized by VersionOne  at EMC.  One would expect such sessions to be product centric and more of marketing and sales pitch about their product. Anyone coming to this event with that expectation would have been disappointed as that was indeed not the case. The entire event was filled with tons of good Agile/Scrum experience. There were really knowledgeable speakers like Mike Cottmeyer from Pillar Technologies and Giora Morein from Big Visible, sharing their experiences on enterprise Agile/Scaling. There were some good discussions on certain topics that I would start listing out in my upcoming blogs.

But here’s one...

I mentioned in one my earlier blog that Velocity of the teams can’t be compared and that’s still true. However, one of the speakers mentioned that Velocity metric can be used to compare teams and see which team is more efficient. I was taken aback a bit, but this makes sense…

Here’s an example – In this hypothetical example, consider both teams started at the same time, with the same expertise, with the same sprint duration and the same estimation skills. The table below tells us that Team A is improving with each iteration. Their velocity is going up with each sprint and seems like 30 is an average velocity this team will attain in future iterations.

Team A velocity over certain interval
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5

Team B velocity over certain interval
Sprint 1
Sprint 2
Sprint 3
Sprint 4
Sprint 5

Compare it to team B and it seems that they have been struggling. The velocity of team is in the range of 10 to 15 and at no point can you predict what can be realistically achieved by this team. So if comparison is done in this order there is no doubt Team A is far superior to another.

Any thoughts?