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.

It's pretty usual to see people from Agile world keep on bashing the Waterfall methodology because of its inherent problems. To be honest, a big majority of the organizations still work in Waterfall mode. So sometimes I used to think, why can't people in Waterfall world do improvement in the way they do things. Though organizations are switching to Agile, you can't deny that people have delivered a lot of successful projects in Waterfall too.

In this blog, I am not into bashing mode but would like to ensure that people in Waterfall world benefit with some of Agile practices without changing the inherent nature of methodology.

Standup

From the outset, Standup is just 10 minutes ceremony but it has a huge impact. With answering 3 simple questions "What I did yesterday?", "What I am going to do today?" and "Any impediments?", it's farely simple to bring transparency and problems on table. Only when you acknowledge and know the problem, you can solve it. That's the basic principle, isn't it?

In one of very big Waterfall project (200 people) I worked, only when people were in neck deep trouble, they used to sit together in order to identify issues. That exercise of jotting down issues itself used to take the entire day and even more. Resultant used to be a big excel sheet and to be honest I never knew what happened to that sheet after that.

I consider Continuous Integration as a philosophy and not just a XP practice. It simply says.

"Do things more frequently which cause you a lot of trouble if you do them only once in a while."

In my example, instead of identify project issues once in 3 months, why don't identify and solve them every day. You won't have those intra-team or inter-team interactions issues anymore. That's the beauty of this 10 minutes ceremony.

Apart from resolving impediments, team shares information on what they are doing and that does the self-cleaning within the team. It may sound very funny but it's very difficult to talk about the same small task 3-4 days continuously. Waterfall hides a lot of non-performing people. Standup makes sure that the process itself put some cleansing within the team.

Regular retrospective

Irrespective of being in Waterfall or Agile, everybody has a tendency to improve oneself. Nobody can deny that. Waterfall is infamous in a way that inner-project problems which push you back in terms of improvement have absolutely no vent (forum) to come out.

Problems can be from any side. People may have very good solutions but they remain in their silos and don't speak. That makes a person passive and continuous problems and no change pushes people to go into shell, in the sense of complete surrender.

Retrospective changes just that. What if team improvises itself on fortnight basis without needing any help from anybody. Definitely, at some points management has to step in to help the team. But having retrospective (talk about good points, points to improve, action points and action owner) put some FORMAL mechanism to improve things in the project.

Continuous Integration and Automated Build

In big projects, integration at the time of delivery is a mess. Though I am talking about long back (2008) but it used to take more than a day just to remove compilation problems and make build run in the project I mentioned. That's a waste. Why not have automated build from day 1, have CI in place and people must write tests . Otherwise there is absolutely no guarantee why last build worked and why this one doesn't.

Writing tests regularly to reduce the maintenance backlog

Waterfall is also infamous for maintenance nightmares. On the other hand for some companies it's continued business too. Without bugs they won't get the maintenance contract. The software which only they can maintain as only their developers know where all it will fail. It's an irony but truth .

I am sure customers are becoming smart day by day and many companies offer free-maintenance for some months just to make sure that they are proud on their continued focus on quality and have delivered bug free software.

Irrespective of points mentioned above, it's important to have tests both for customers and for maintainers. Application can never become extensible without tests as otherwise it will just become yet another monolithic structure which is waiting to be re-written again .

People have been talking about TDD or writing tests for a long time for Waterfall, I am not sure how much practically it has been possible for these guys to really do it as actual development phase is just one of the 4 phases (very less time) and also at that time of developers have pile of huge non-prioritized requirements to implement.

Motivation and demotivation are huge factors when it comes to effectiveness of Scrum based project execution. Irrespective of whether Scrum Master/Project Manager came from Scrum developer background, it's important to understand what motivates the Scrum team.

Instead of talking from top-down approach, I will rather talk about what demotivates the Scrum team. If we are able to fix the problems mentioned below, I see no reason why people are not happy in the team. Below mentioned points are based on experience while working with multiple project as developer, Scrum Master and Agile Coach. Please feel free to add more based on your own experience.

• Consider the team as stakeholders of creating exciting product. Sometimes developers have no clue what they are going to achieve in next 2-3 sprints as PO doesn't share the product roadmap. This definitely cause demotivation as every individual leaves home for office to work towards a purpose.
• It will be good idea to encourage team to provide inputs which focus on effectiveness rather than efficiency. Suggestions with which business logic could be simplified. So you are not really talking about numbers but real effectiveness of the software product.
• Getting involved with legacy technology or with non-challenging work. People leave companies just because of this reason many a times. It's important to have rotation of developers instead of keeping one single time for a long time.
• Celebrate success. It's a very important point but often ignored. There can be thousands of good ideas to celebrate and which don't cause a lot of money too everytime. For instance our team used to watch a movie together in the company's conference room along with pizzas and beers.
• It's very important to appreciate the small achievements of team members. If that appreciation comes from customer, that's even better. But it's important to have a culture of appreciation.
• Haven't you observed many a times that some people are not comfortable with another team member. I have seen that if team and organization has a feedback culture, these problems do not remain for long. Anybody should be able to give feedback to anybody. That can be done through interesting games. It helps in removing any negativity between the individuals.
• Physical Scrum board and information radiators. It's much more encouraging to see burndown going down for a team-member when he moves his one user-story to DONE.
• Team outing for instance for trekking, travel on the weekend. These non-technical activities really helps in team-bonding. Lunch people have every day with each other.
• Everybody should be considered as team members and no segregation between developers, architects and testers. Team has to nourish the feeling of "US", "ONE TEAM" and working towards Sprint goals. Heroism shouldn't be encouraged. Though personal efforts require appreciation.

Before moving to Agile I worked with Waterfall for around 10 years. Throughout those years I could see people working day and night in development phase. Sometimes teams used to work from 9AM-8PM rhythm non-stop even without knowing why are they doing so.

Whenever product was shipped to customer or whenever any critical production problem occurred, it was quite usual and at the same time pitiful to see team staying entire night to fix the issue.

I heard the word burnout many times. I could see the signs of fatigue on the faces of some people but apart from that I never could understood what burnout actually means.

So here is a story.

One fine day, customer asks a team (working with Waterfall so far) to start working with Agile methodology.

Team starts working using Scrum. Though they followed all practices and ceremonies of Scrum as well as XP practices, one thing still didn't change. The very familiar environment of demanding customer, strict deadlines, pressure from

Though it may look surprising to you guys, it looked very familiar to the team coming from Waterfall background, .

Apart from some similarities with Waterfall, many things were very different. The sprints were continuous, one after another. One ends with a demo and another one begins the very next day. Till the very last day of Sprint, people used to be busy in doing the fine-tuning and related things.

Even after all these efforts, customer didn't look very happy with team's productivity. Customer was getting pressure from stakeholders to finish the project early which had nothing to do with existing team. So, that explains team's so called inefficiency.

Team coming from Waterfall environment generally responds pressure with working extra hard and that's what team actually did.

Extra hard work got into a vicious loop which didn't seem to end and before team could even realize anything, they could feel the very signs of burnout. Getting into depression, not able to do any work, discussions bothering you a lot and you go to the workplace where you never want to really go.

Below mentioned presentation which I did at Agile-2009 conference talks about yet another but a bit similar case-study in which team had a burnout. Take a look:

So that was all about story. Let's see why people in Waterfall are always in hurry to finish application without looking at quality aspects much.

Quite Less Development Time in Waterfall

Waterfall means a long time spend on requirement analysis and design. So in entire 6 months of SDLC, around 3-4 months go to other phases (requirements, testing and design) and only 1 part of the whole SDLC becomes the part of development.

As you can see, very less time to do any effective development with all quality stuff intact. That eventually translates into low quality, software with a lots of bugs, high maintenance cost, redundant requirements etc.

Among all these problems, there used to be a silver light for the developers. Even though they used work day and night in the development cycle, that time was not too long. In between they get relatively much less pressurized environment of working out other phases of methodology.

Let's look into the reasons why team got into burnout mode while moving to Agile from Waterfall.

Why Agile Adoption Caused Burnout?

At one end Waterfall churns out a lot of waste in which sometimes you have no clue who is doing what, on the other hand in Scrum, you just don't stop. Scrum comprises short iterations of 1-2 weeks. At the end of each Sprint team has to create production quality software along with all facets of Waterfall phases running along at the same time.

So in our story what really caused the burnout and how it could be stopped? Let's see.

• Team coming from Waterfall and in turn hierarchical background could not really say NO when management continued putting pressure on team for delivering faster.
• Pressure in Scrum has much more far-fetching impact (burnout) than in Waterfall.
• Before moving to Agile it's important to focus on having training on Agile values and mindset for management, customer and team as Agile implementation is not yet another PMI or CMM implementation.
• Team must believe in the golden rule - "under-commit but over-deliver instead of over-commit but under-deliver"
• Team and not management should have complete say in estimation (the amount of effort required)
• Management should have helped customer to identify only high priority user stories for each and every sprint. Otherwise, people put the same effort for low or no business-value user-stories

Makes some sense? I would be happy to hear your comments.

These days I am looking at Grails functional testing part. For recording Selenium scripts, generally the best thing to use is Firefox IDE plugin. It's possible to convert the Selenium scripts to a test-case in the related programming language (Java, PHP, C# etc). I was looking for a similar formatter for Grails also which is available at github.

I tried to install it but it complained with an error "Firefox extension not compatible with browser" which simply means that the plugin has not been tested with related FireFox version. As Firefox versions are progressing like anything, people are having hard time to find suitable plugin version. As I said earlier, though the plugin is not tested with relevant Firefox version, it doesn't mean that it won't work with latest Firefox version.

For Grails Selenium IDE formatter issue, I looked at a blog which provided the solution to my problem. I edited the Grails IDE formatter source code based on the directions mentioned in this blog and it worked like a charm.

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

The basic idea of using FitNesse on top of Selenium is to enable a tester or a customer to start writing a functional test cases even before developers start coding. That's a big advantage as testers then are able to utlise their time to do some worthwhile work at the beginning of the Sprint.

That way FitNesse test cases become the concrete acceptance criteria in front of developers too.

This is the basic fundamental idea of "ATDD"

Here is a screenshot of a Xebium (can convert FitNesse test case into Selenium script and vice-versa) test case:

Above test case is written in following pattern or DSL:

start browser <browserName> onURL <url>

ensure do open on ...
ensure do verifyTitle on ...
ensure do verifyTextPresent on ...

stop browser

The test case language is far simpler than any other technical test counterpart. As a result any tester can easily learn and write test cases using Fit framework. Even though the premise is to enable people without any technical know-how to write acceptance test cases, it doesn't look that easy for a non-technical person by looking at the DSL and its essential grammar. It requires some learning curve and I am not sure if every non-technical person will be wiling to write a test case using FitNesse based DSL.

Better choices for Selenium + ATDD

In my last blog "Distributed Agile: Acceptance Test Driven Development (ATDD) in Practice" I talked about ATDD in practice for Distributed Agile teams using "Behavior Driven Development (BDD)" frameworks like "easyb". Tester/customer write the test cases in pure English based DSL and developer and tester then fill the implementation of the test case.

Here is an "easyb" scenario which a customer/tester writes and you see how easy it's to write and explain:

scenario "User submits valid credentials and gets to the home page",{
    given "Open the login page",{
    }
    when "User enters valid credentials and submits", {
    }
    then "Album List specific to the user is shown to the user", {
    }
}

As I said implementation has to be written by a developer, here's a Selenium implementation in Grails, using Page Object Pattern,

def loginPage
def homePage
scenario "User submits valid credentials and gets to the home page",{
    given "Open the login page",{
        loginPage = LoginPage.open()
    }
    when "User enters valid credentials and submits", {
        loginPage.username ="john"
        loginPage.password = "pass1"
        homePage = loginPage.submit()
    }
    then "Album List specific to the user is shown to the user", {
        homePage.verifyPage()
    }
}

Conclusion

We can use BDD based frameworks to our advantage to write Selenium test cases in ATDD fashion which brings a big change the way acceptance test cases are written and executed. Also in practice, it's much-much easier to get some direct interaction of PO with the application without being too verbose.

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

However currently the way we practice acceptance criteria (from PO) implementation is mostly adhoc in Scrum based projects. In practice, I am not sure how many Sprints are actually tested thoroughly by Product Owner and how many POs still define any acceptance criteria in the user-story. Again, the translation of written acceptance criteria in English (or native language) to technical tests also is not sure to get verified from PO side depending on the technicality of test cases.

Another problem from distributed Agile perspective is - tester may be sitting with the offshore team and may have less oppurtunity to talk to PO which happens in practice in many projects where PO is involved in many other things other than project. Ideally PO should be fully dedicated to one project but in practice, I have seen PO to be involved in multiple things. Getting his time for explanation sometimes becomes precious to the team especially at distributed end where core working hours between both onsite and offshore team are even less because of timezone difference.

So we have a problem statement as follows:

• PO may not have sufficient time for the distributed team as and when needed by the tester sitting with distributed team
• Acceptance criteria (in English) are either not written or sometimes lose their validity in technical translation.
• Customer is not sure right translation of English prose based acceptance criteria into technical acceptance test. Also criteria sanctity may get lost in regression tests later.

Because of all these issues, though Sprint Demo become successful but that may or may not ensure into production ready application.

Let's take a different approach.

How about PO or QA person sitting at customer location starts writing acceptance tests in English based DSL. However now that English based DSL becomes acceptance criteria in technical language for developers too. Woohoo...That's a win-win situation. Isn't it?

Here is a functional test-case written in easyb (BDD based framework)

scenario "User submits invalid credentials and gets to the login page again",{
    given "Open the login page",{
    }

    when "User enters invalid password", {
    }

    then "User should be with login page again", {
    }
}

That's all a PO or a QA person has to write to create a functional test for "invalid-credentials check" on login screen. How this test case gets implemented is more of a developer's headache .

In above snippet, the "scenario" itself explains what's functional test all about, "given" is the pre-condition, "when" is the actual work done for executing the function and "then" is the post-condition or the result of the test case.

As you can see the test case is written in English but it serves as the technical specs for the developers and they need to make sure that they pass this acceptance test as part of definition of DONE (DoD) for the user-story.

Conclusion

This is an example of Acceptance Test Driven Development in practice for distributed teams.
Here PO/Business analyst/Tester is involved in writing the test case they want to get implemented with local or distributed development team in their own technical DSL.

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.

Sometimes distributed chat create a feeling of mistrust unknowingly which eventually doesn't work well with "One Team" concept. Let's take an example. Developer A from team India asks something from developer B in Holland on some urgent issue. This communication starts with a chat message from developer A. Though developer A must need a response from developer B in order to move further, at that time he doesn't get any response. This communication failure might introduce some misunderstanding as developer A may think that B doesn't want to talk to him on purpose and has started ignoring his messages. In practical life, there can be many reasons why B doesnt respond:

• He is not on the seat.
• He doesnt look at chat messages coming from many different people as they distract him from work.
• He is in middle of something else.

Video chat doesn't solve this issue as A will be able to see B only when both have "when needed" (more appropriate phrase may be "lazily loaded" - influenced from Hibernate ) communication. Misunderstandings and miscommunication eventually brings down the trust and "One team" feeling.

Based on our experience, 2-3 months after initial collocation, distributed communication become more and more technical as people lose human touch and physical sense of the individuals on other side. To subside that, in our projects, we encourage frequent collocation (in every 2-3 months) to evolve personal bonding and trust.

However implementation of "Virtual One Room" concept brings down these problems significantly.

The idea is to setup big TV monitors on both distributed locations and connect them through Skype video all the time. That way each distributed team member can see all other team members on either side.

It provides following benefits:

• People greet each other while coming, leaving or going for lunch. Sometimes parties, good moments and jokes are visible on other side.
• Now you yourself can see who is on seat and who is not. Your question "why this guy didn't respond to my query" gets immediately answered. You communicate when person on other side is available. In case it's urgent, you ask to other available distributed team members to connect with that guy. It brings down some immediate causes of misunderstanding and help in improving communication.
• It gives "One Team" feeling to everybody as they can see everybody in the whole distributed environment even if they are sitting thousands of miles apart.
• Sometimes people do not look at your chat message immediately just because they don't want to get distracted from their current work. To handle this situation we as a team made a protocol which worked well for us. The protocol is - in case such things happen, people can give direct Skype video calls to their distributed partners.

The concept of "Virtual One Room" has worked well for us in bridging the communication gap to a certain degree.

Installing new version of Grails is easy. However it's quite a pain to make it running on Cygwin. The problem is as follows:

Jdk 5 introduced "javaagent" as one of the JAVA_OPTS and it has been used in running Grails 2. Shell scripts convert $GRAILS_HOME in cygwin format for running grails. So for instance if $GRAILS_HOME is c:/grails, it becomes '/cygdrive/c' in cygwin format. This makes

AGENT_STRING=-"-javaagent:$GRAILS_HOME/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-0.8.4.jar

to something like this:

$ echo $AGENT_STRING
$ "-javaagent:/cygdrive/c/grails/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-0.8.4.jar

which JRE doesn't understand while executing 'java'. It expects -javaagent value to be something like 'c:/grails/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-0.8.4.jar'.

To make it work, following changes need to be done in $GRAILS_HOME/bin/startGrails script:

Introduce a new variable something like GRAILS_HOME_FORWARD_SLASH before making any change to environment based $GRAILS_HOME.

# For Cygwin, ensure paths are in UNIX format before anything is touched

GRAILS_HOME_FORWARD_SLASH=`echo $GRAILS_HOME|sed 's/[\]/\//g'`

Also change the way AGENT_STRING is defined as follows:

AGENT_STRING="-javaagent:$GRAILS_HOME_FORWARD_SLASH/lib/com.springsource.springloaded/springloaded-core/jars/springloaded-core-0.8.4.jar -noverify -Dspringloaded=profile=grails"

This change lets you work with Grails 2 now on Cygwin

I like tree command on linux which provide you the snapshot of the directory structure and files in a tree view. Something like this:

As most of the times I use CygWin on Windows, I wanted to get 'tree' working here too. I could fine the source of it at which I compiled and installed based on the instructions mentioned.

Though it worked but I started getting problems because of non-ASCII characters used in the 'tree' output. For that I installed . 'mintty' is even cooler to use on top of cygwin. At the same time I got 'tree' command working the way I wanted.