Distributed Agile

Agile Offshore: Why Distributed Demo / Showcase is so Important?

ShriKant Vashishtha · January 14, 2013 · 1 Comment

Demo is an integral and important part of Scrum ceremonies. Important because that’s the whole point of being Agile. You get early feedback from Product Owner and stakeholders and fine-tune the product if required. Also this is sometimes the only occasion for offshore team when sponsors and business actually get to see the real contribution of offshore team. There are valid reasons also when someone from onsite team gives the demo. They include:

Language problem. I worked with a French team in which stakeholders and business were more at ease to talk in French.
Completely opposite time-zones which may not allow a lot of collaboration.

The advantages of distributed demo far outweighs the ones of onsite demo.

Agile Offshore : Business Analyst – Complementing the Role of Product Owner

ShriKant Vashishtha · December 18, 2012 · 1 Comment

Let’s take a scenario.

You have a product owner at distributed location but somehow he is not able to provide sufficient time to distributed team. Because of that team doesn’t get enough understanding of user-story.

Does it sound familiar?

Mostly it’s about PO getting involved in too many other things. That results in not having user-stories READY, analysed or communicated properly.

That brings another question related to suitability of people assigned for PO role. Not everybody is good in analysing and writing good user-stories.
[Read more…] about Agile Offshore : Business Analyst – Complementing the Role of Product Owner

Worldwide Distributed Agile Team – Some Thoughts

ShriKant Vashishtha · December 23, 2011 · Leave a Comment

Question: How do you think we can handle Agile approach with a worldwide distributed team (Latin America, US, France, UK, Germany & Hungary)? I can have developers at one location, but not Product Owner nor QA team. Any experience to share?

Answer: Try using ATDD where QA creates the acceptance tests at the beginning of Sprint. ATDD which is based on FitNesse or BDD. QA/BA along with Product Owner writes the test cases and developers have to implement their code in order to satisfy the acceptance criteria. This QA sits along with product owner. Apart from that have regular testers also on each distributed location.

Use Skype group video or Google+ hangout for distributed meetings. Use sync.in to write stuff simultaneously from distributed sides within the meeting.

Have collocation between the distributed teams which are going to collaborate together. That is required to have a good personal bonding. As you said, you can have developers can be at one single location – that’s a good idea. Otherwise multiple distributed teams and then multiple time-zones are very difficult to handle.

Have local as well as distributed standup. Make sure that the entire team is working on shared user-story, shared code-base and people use distributed pair programming.

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).