Agile Offshore Development Tip 4: Involve Offshore into Scrum meetings

I have seen distributed teams following Agile practices but each one not really sharing information with other distributed teams. For ex: Both onsite and offshore teams would be conducting Scrum meetings but skipping Scrum of Scrums.

Important thing in distributed Agile development is to include the offshore teams for all important workshops. For ex: Requirement, Retrospective, Modeling days, Iteration planning meeting.

In many onsite-offshore projects, the onsite team handles the design/architecture part and the offshore team is involved in pure development and testing. This model makes many onsite teams don't feel like involving offshore teams for Requirement workshops, modeling days.
Which in turn leads to a huge communication gap and would result in creation of a poor quality product. The above mentioned scenario would also involve lot of hand offs from onsite team to offshore team, resulting in lot of wastes being added to the system.

Systems thinking needs is the key to succeed in distributed Agile development.

TestSuites should be on Feature Themes

Many developers tend to package TestSuites to contain the tests based on technology/layers. For ex: TestSuites to contain the tests on UI layers, Dataaccess, BO.

Since we create unit tests to test a unit of functionality, the TestSuites should contain tests based on the Features/Use cases.

For Ex: TestSuites to contain Unit tests testing feature to add User Or Modify User.

Task creation for fulfilling user requrirements

At the end of the requirement workshop, first thing the Scrum team would be looking forward to is to create the tasks for the features. For the rest of the iteration, only thing they are worried is how many tasks they have been able to complete. In this process, they forget that they have to deliver the Running Testing Features(popularly known as RTF) to the customer.

One way to avoid this task creation madness could be to divide the features into smaller feature chunks that can be handled like a task. (Right now the discussion is going about this in scrumdevelopment forums)

For Ex: instead of writing a task like "Database creation", if we can rewrite it as "Database creation to fulfill the storyX" Or rewriting it as "Handling Database related work to fulfill FeatureX" could make the team to "NOT" lose their focus on features/requirements.

Applying TDD while dealing with database related actions

There are numerous thoughts about how to go about applying TDD while dealing with database access related code. Some of the common thoughts include

1. Replacing DB with Mock Objects to simulate Database
Most preferred one. Advantages include

• No need to worry about DB info, driver info,
  
• tests run faster as compared to other techniques
• No need to change any test code because you changed the database
• Easier to maintain
  

2. Using a local copy of DB
Some programmers suggest to make use of a local copy of database for testing purposes. It has its own pros and cons:

• One needs to be aware of local Database related APIs
• Keeping the local copy of DB in synch with central test DB is bit tricky, especially with a large project team.
  
• Easier to use
  

3. Use central test DB
In this case, test with the cental DB, and apply transaction/roll backs to clean up DB after the use brining the DB back to its original state

• You can be confident that your code works well with the DB
• goes against some of the unit testing principles created by thought leaders like Michael Feathers
• Easier to maintain and use
• Be aware of Database APIs, drivers, etc .

4. Use an in-memory DB (like HSQL) Or any other faster databases

Not recommended much

• Again this goes against unit testing rules
  
• easier to use
• You are not sure whether your SQL queries tried against in-memory DB works with real DB