Patterns

What Motivates Scrum Team?

ShriKant Vashishtha · October 21, 2011 · 2 Comments

Effectiveness of Scrum based team depends a lot on motivation level of team members. It’s important to understand the factors which motivate a Scrum team irrespective of the background of Scrum Master/Project Manager.

I this post first I will focus on the reasons of de-motivation. If we fix these problems, I see no reason why people are not happy in the team. The points mentioned below are based on the experience of working with multiple project as developer, Scrum Master and Agile Coach. Please feel free to add more based on your own experience.

Why to Use FitNesse or ATDD on Top of Selenium?

ShriKant Vashishtha · September 21, 2011 · 4 Comments

For Web Application development Selenium is a defacto tool for functional testing with its click and capture capability through browser plugin. At the end of recording, Selenium script can be converted in a test-case in almost any programming language.

Immediately after you begin talking about functional testing people jump on the tools and would like to know what tools you are using or going to use.

And in practice that’s how it works. Somebody will say let’s use Selenium and somebody else will come up with a suggestion to use Xebium or FitNium. In some projects which-tool-to-use becomes very clear within a day but unfortunately fewer understand the business-case of using Xebium or FitNium instead of pure Selenium.

This post tries to answer following questions:

What’s the need to cover Selenium with FitNesse to begin with?
In practice does FitNesse + Selenium work any better compared to pure Selenium, based on the reasons mentioned in last question?

Why Selenium + FitNesse (Xebium or FitNium)?

Distributed Agile: Acceptance Test Driven Development (ATDD) in Practice

ShriKant Vashishtha · September 20, 2011 · 2 Comments

In one of my posts (Agile Testing – Incremental Functional Test Approach) I discussed about the impedance mismatch between developers and tester in Agile team. The basic issue is – testers receive the user-stories at the end of sprint when you definitely won’t have sufficient time to test it. To resolve that problem, we came up with an idea of splitting the user-story in functional tasks so that at the end of each functional task, tester could test it. That way tester can test in incremental way rather than waiting endlessly for a Ready for Test user-story.

Moving a step further, how about getting away from breaking user-story into functional sub-tasks and just write acceptance tests at the beginning of sprint itself? Developers then have to make sure that they develop the code to satisfy those functional test cases. Here acceptance test cases are not written in English prose but in a DSL structured in English (understandable to anybody).

Distributed Agile : Bridging Communication Gap with Virtual “One Room”

ShriKant Vashishtha · September 18, 2011 · Leave a Comment

While working in distributed Agile, one of the repeated patterns is “2-dimensional (2D) communication”. Distributed communication generally happens with Skype video and Mikogo desktop sharing tools. Skype kind of video-chat solutions help in bringing distances closer as team members can look at body language of their distributed partners while talking. At the same time, distributed desktop-sharing tools (Mikogo, yuuguu, Skype screen share etc) enable distributed pair programming as developers from both sides can look and use their own machine. Sitting posture is much more comfortable than collocated pair-programming.

Initially communication mode works well but after a while (say after 2+ months) it becomes monotonous, technical in nature and less focused on soft-nuances of communication. People talk when they need to and only to fix technical issues. Human touch goes down as time elapses which is a usual phenomenon of distance communication. Discussions on personal life, things beyond project scope and fun talks cannot happen in an environment in which your sole purpose of talking most of the times is resolving a technical issue.

Chain-Link Pattern : Developer/Tester or Sales/Delivery Relationships

ShriKant Vashishtha · July 9, 2011 · Leave a Comment

In my last blog I discussed how in an Agile team “we vs they” (between developers and testers) phenomena can severly damage team dynamics. The idea is – it doesn’t work when two links of a chain consider them isolated and independent links. As soon as they think so, they are really not working towards one common goal.

Today I had a similar discussion with one of my friends on the dynamics of Sales and Delivery teams in a software development company. For software delivery (implementation) team, Sales is like a foreign word sometimes. For them Sales people must be working in their own islands. Similarly Sales team in itself might be very cohesive team but they again might be living in their own world. For them Sales in itself can be an individual topic which works based on the relationships, links etc rather than with the help of any technical expertise.