Offshoring is frequently promoted as a way to produce great products for far less money. So many software development companies boast about sending large amounts of their work to India or China to reduce costs. Unfortunately, in doing so they’re often reluctant to pay the price to create and maintain high-performance distributed teams.

Agile works on the basis of a few simple principles:

• Short Feedback Loops—which leads to iterations, TDD, …
• Radical Transparency—which leads to daily standup, demo/review, …
• Face-to-Face Communications—which leads to high trust, group problem solving, …
• Value—which leads to eliminating waste
• Continuous Improvement—which leads to retrospective, adoption of engineering practices

Thinking back on every project that I’ve ever worked on (Agile or not), the quality of communications was a good predictor of success. So when we run distributed teams, there has to be a focus on making communications work.

At best, the typical approach to this problem is to buy web cams, fancy video- conferencing software, and conduct our meetings sitting in front of them. But that misses the point—these devices improve the quality of communications but not enough. They don’t build trust. To really build trust, you have to meet face to face for at least a week. Unfortunately, trust is weakened through the course of a year, so it has to be renewed. At a minimum, team members should visit each other twice a year.

So, if you really want to get a high-performing team—don’t underestimate the real costs. Be sure to budget for travel—a minimum of twice a year to build and maintain trust. Don’t shortchange your distributed teams.

Almost exactly three years ago, I was trying to use David Allen’s "Getting Things Done" (GTD) system, and I wasn’t seeing the benefits he promised. In the end, I found that it just helped me thrash. I suspect the problem was more my focus than his system—but at end of the day, his approach just didn’t resonate with me.

Today, my system is a little closer to a hybrid of Mark Forester’s AutoFocus and Francesco Cirillo’s Pomodoro Technique. I still use MLO as my task manager but on a more granular level than I used to. Instead of slaving over MLO constantly, now I use it to help generate my list for the day. I use MLO to keep track of a large list of tasks. Mostly, I just use the outline to remind me of things I want to tackle. Every day I glance at the TODO view to make sure that there isn’t anything that is date sensitive that I’ve lost track of. Once it comes to committing to tasks for a particular day, I often use index cards using MLO, email, and anything else as inputs. At the end of a day (sometimes two), I take anything that remains in the card and put into MLO. Then I tear up the card, which is probably the most fun part.

Other habits:

• I sweep my tabs in Firefox every few days and move stuff to reading lists in MLO.
• Once/Twice a week I go offline and go through my email.
• Once a week I take some time to reflect—what is going well, what needs improvement, what do I  have the energy to improve, and what one thing can I do next week to improve it. Aka a retrospective. This is the hardest one to maintain—because you’re tempted to skip it and get more "work" done. Yet, it’s the most important because it drives real improvement.

I use the Pomodoro Technique for the following:

• a reminder to stay on task
• a way of doing a rough estimation every morning

Also, on a two-monitor setup under Win7, I dock MLO on the far left and leave it in outline mode, where I can always see other things I want to do.

Other tools I use include ClipMate Clipboard Extender because it allows me handle more than one item in the clipboard and to clean (i.e., remove html, etc.).

In addition there were several comments with replies: Robert Dempsey:

CEO and Founder of Atlantic Dominion Solutions. We developed Scrum’d: http://www.scrumd.com. A great post and an excellent challenge. To answer your questions:

# Your Definition of Done

We define done for each user story. Acceptance criteria includes the behavior a user can expect from the app when using it, the workflow for the feature, that it needs to be tested (and how it will be tested), any validations that occur, and if there is documentation for the feature that it is updated.

# Whether you use TDD? Or at least Unit Testing?

We do full TDD for all our stories. We didn’t start out that way, but now that we have a full test suite, we keep it that way. Also, if a bug is found, then a test needs to be written for that and the code fixed.

# What do you do for Acceptance Testing?

We have staging servers set up for internal testing. We also have a few select customers that we let into our staging servers, and I show (in person) some of our current and potential clients the features to get their feedback as well. In addition, we use Get Satisfaction for our support site and ask that commentators who suggested features that we implement to check out the release and see if it’s what they wanted.

# How often do you release?

This depends. We try to do monthly releases. Sometimes it’s longer, but typically it’s less. The release schedule really depends on the importance of features to our user community.

# What did you learn in your last retrospective?

You don’t always get it right the first time, but anything you do release needs to work correctly. Also, continuous integration is a huge help as your product gets bigger, and of course, testing is an absolute necessity. We would rather delay a release to ensure quality than release stuff that won’t work.

Marcin Niebudek (creator of TinyPM)

I like challenges, so…

Our DoD for stories:

• code meeting minimal requirements committed
• unit tests passing
• feature is working under FF, Chrome, and Opera
• feature is working without any significant failures under IE
• feature is tested and accepted by at least one team member that was not implementing the story

Our DoD for release:

• WAR and .exe distros built successfully
• all unit test passing
• all functional bugs fixed
• all UI bugs fixed or small UI bugs (mostly for IE) at least scheduled to be fixed
• installation and upgrade documentation updated
• installation tested on Windows and Linux
• new features list updates at product web site

Do we use TDD? Well, I would not say that because our coverage is not 100%, which means some of our code is not unit tested (glue code), but, yes, we do unit testing with "test first" style for all domain and business logic code, and we tend to shift into BDD style right now.

As our Product Owner is also an active developer, for acceptance testing, we tend to verify features within a team, as we have strong and common vision of a product within the team (see also acceptance in our DoD for stories). It’s a low ceremony process (as are all our processes in the team).

How often do we release? Every 2–3 months.

What have we learned from our last retrospective? That we need to shift into feature branches to be able to release small stories more often while the big ones are still in progress.

Do you see any flaws or warning signs in what I’ve posted here? Go on, say it… we’re always happy to improve…

It would be fun to hear from Target Process, ThoughtWorks Mingle team, VersionOne, AgileBuddy, and anyone else I might have missed.

An idea shamelessly stolen from O’Reilly Radar. Every week I will publish a short article with 4-6 relevant Agile links. I’m open to feedback on the frequency etc.

Given last weeks announcement from Jerry Weinberg, it seemed appropriate to kick of with a couple of items related to him:

• Jerry as “freaking people Ninja” – Eric Nehrlich (the Unrepentant Generalist) reflects on a session at AYE with Jerry.
• “The View from Jerry’s Shoulders” looks over his writing and comments on his many books. While I like alot of Jerry’s books I will admit that I’ve found “An Introduction to General Systems Thinking” a tough slog. I gather that The Fifth Discipline: The Art & Practice of The Learning Organization (Peter Senge), maybe more to reading abilities. YMMV.

The Scrum Alliance twittered about a new list: Scrum Alliance community discussion group: “All healthy discussion is welcome. Differences in opinion and thought are encouraged. Spam, abusive language and direct advertisements/attacks aimed at splintering the community’s energy are prohibited and violators will be warned/banned. Heated debate, differences of opinion, methods other than Scrum or desire for a different SA community group are all open topics. Please be respectful of each other and be mindful that email is often toneless and can therefore be easily taken wrong.” My take – this is a good place to discuss issues that would get you kicked off ScrumDev.

Given/When/Then And Example Tables Using the Robot Framework – Shows how to BDD/ATDD style grammar’s in RobotFramework.

The Airplane Factory game: “The Airplane Factory Game is a simple game to introduce people to Agile and SCRUM. And also, it could be easily adapted to Lean, XP, etc. This article will explain briefly the game, showing the rules, some tips and results. Also, you will be able to download it” I’ve not had a chance to try this game yet – but the premise does seem interesting.

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

My reply: Congrats I’m sure you have an excellent application. I’m wondering if you see the irony – you’re posting to an Agile group and say that your app has hardly been tested? What is your definition of Done? Do you use TDD? At least Unit Testing? What was your approach to acceptance testing?

My Promise

Here is my promise to all of my future clients, I won’t show you an agile tool that wasn’t developed using Agile methods. From future tool suppliers I need to know:

• Your Definition of Done
• Whether you use TDD? Or at least Unit Testing?
• What do you do for Acceptance Testing?
• How often do you release?
• What did you learn in your last retrospective?
• ….

If you can’t answer these questions I’m not interested in your tool.

Update I mis-understood the author’s intent. He’s not releasing a tool, so much as testing the waters to see if there is any interest. For these purposes I think he did the right thing. I still stand behind the statement I would show a client a tool where the vendor couldn’t answer the above questions.

Please try the Movie Example (git hub browseable, zip file) and see how far you can get with some simple refactorings.

References:

• The Art of Unit Testing: with Examples in .NET (Amazon.ca) – Roy Osherove (.NET and soon a Java version)
• Refactoring: Improving the Design of Existing Code (Amazon.ca) – Martin Fowler
• Refactoring to Patterns (Amazon.ca) – Joshua Kerievsky
• xUnit Test Patterns: Refactoring Test Code (Amazon.ca) – Gerard Meszaros
• Pragmatic Unit Testing in C# with NUnit(Amazon.ca) – Andy Hunt and Dave Thomas
• Pragmatic Unit Testing in Java with JUnit (Amazon.ca) – Andy Hunt and Dave Thomas

BTW David Koontz did the hard work of typing in Martin Fowler’s Movie sample – I just modernized it (Java 1.2 –> 1.6).

Caveat Emptor – if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

Monday Morning

9:00–11:00:  will likely be open jam time for me. Come find me there and let’s talk.

11:00–12:30

Kanban adoption at Software Engineering Professionals (SEP) Chris Shinkle (45 minutes) – “In 2004, SEP tried adopting Agile practices. However, Agile failed to have the desired lasting impact across the entire organization. Things changed in 2007, when SEP implemented Kanban for the first time.”

The Agile Playground Tobias Mayer (90 minutes) – “Agility in Action… This session will introduce five interactive games that a facilitator can add to their toolkit for team and management training. The games all illustrate the principles and dynamics that support Agility. The rationale for this session is that people learn best by embodying the learning, rather than just receiving knowledge at a head level. All participants will be immersed in the games; there are no observers. At the end of the session the participants will have a set of games they can introduce into their own organization to enhance their own Agile adoption process.” From my own recent experience: Learning: the Best Approaches for Your Brain, I can say that games are a very useful way to integrate knowledge.

Using the Agile Testing Quadrants to Plan Your Testing Efforts Janet Gregory (90 minutes) – “Different testing approaches are needed because quality has many aspects besides functional requirements, such as making sure the code is reliable and secure. How do you know you’ve done the kinds of testing and quality processes are necessary for your product, especially on an agile project?”

My choice: Tobias “Agile Playground” Caveat: Tobias said he wants at least 16–24 for this workshop, so please don’t overwhelm him based on my recommendation.

Monday Afternoon

14:00–15:30

Help! Already too many amazing options. First a bunch of experience reports:

Enterprise Agile Transformation: The Two Year Wall Chuck Maples; Weaponized Scrum Michael Marchi; Accidental Adoption – The Story of Scrum at Amazon.com Alan Atlas; The Amazing Team Race – A Team-Based Agile Adoption Gabino Roche, Jr., Belkis Vasquez; The Covert Agilist Ken Howard; Descending from the Architect’s Ivory Tower Andrew Rendell. I’m interested in all of these, but they have some stiff competition:

In the end, it’s coming down to three options:

When it just *has* to work: Agile Development in Safety-Critical Environments Brian Shoemaker, Nancy Van Schooenderwoert

What Does an Agile Coach Do? Liz Sedley, Rachel Davies – They’ve just written the book on the subject.

Creating Agile Simulations and Games for Coaches and Consultants Elisabeth Hendrickson, Chris Sims (3 hours). This one is on the Manifesting Stage, for which I was a reviewer, and I championed the presentation. I love the idea of learning how to create games. I’m really hoping that Elisabeth and Chris distill their knowledge into an InfoQ article.

My choice: I’m torn between Rachel and Liz—What Does an Agile Coach Do? I’ve got to work on this a bit myself and Creating Agile Simulations and Games.

16:00–17:30 I may be meeting with Linda in this time slot, so I will play this one by ear.

Team Start-up: one of the first Agile Adoption activities Lyssa Adkins (90 minutes): “Starting up an Agile team is one of the first things you might be asked to do when a company wants to “go Agile.” What do you need to know before starting up a team? In the start-up, how much do teams need to know about Agile before they “go”? What do they need to know about each other…what the project is all about…who they will become as a team? These and other questions are answered as we walk through good ways to start-up Agile teams.”

Giving and receiving effective feedback Elizabeth Keogh (45 minutes) – “Find out why we give personal feedback, how to provide effective feedback, what makes feedback ineffective and how to deal with poorly phrased feedback. Learning what makes feedback effective helps you to seek your own feedback and improve, whilst being able to support the people around you.”—echoes of “Giving an Taking Design Criticism with Rebecca Wirfs-Brock”

10 Temptations of an Agile Coach (new or experienced) Stevie Borne (45 minutes): “Regardless of your coaching experience, there are a wide variety of temptations you can fall into that affect the quality of your coaching”

Effective code reviews in agile teams Wojciech Seliga, Slawomir Ginter – I was tempted by this one, but as I read the description it feels a bit like a vendor talk. “The session includes a demo on how Atlassian Crucible integrated with leading IDEs via Atlassian IDE Connector facilitates the whole process”  Not interested. To be clear I like Atlassian and their tools, but it feels like the talk has less value without their tools $$$. See the exchange in the comments below.

My Choice: Team Start-up: one of the first Agile Adoption activities—Lyssa Adkins

1.1 Rights You Grant to Spigot.
By installing the Toolbar on your computer, you expressly authorize and request Spigot to:
a) act as your search agent to conduct inquiries on your behalf using Spigot’s search engine and technologies and partners’ sites, and collect relevant information and display it to you;
b) take actions Spigot deems appropriate to provide the Toolbar to you and to act on your behalf in obtaining information from partners and displaying that to you;
c) read and interpret your search requests and results on certain sites and use this information to conduct searches on your behalf, offer alternative results and to personalize The Toolbar for you;
…

f) modify your Microsoft Internet Explorer and/or Mozilla Firefox browser settings for the default search engine, address bar search, “DNS error” page, “404 error” page, and new tab page to facilitate more informative responses as determined by The Toolbar;
…

The real offender here is stealing 404 error pages. At my current client my wireless internet connection is sometimes less than perfect and when I ‘404’ errors I was redirected to Urlseek’s obnoxious website (sorry I won’t link to this crap). Some digging proves that you can uninstall the toolbar separately from the PDF creator, but even so this is low underhanded and unpleasant. In addition I suspect Sourceforge would be a little unhappy to hear that this nastiness is hosted on their site.

If you enjoyed this post, subscribe now to get free updates.

My client is building an ASP .NET application and we're trying to decide how to test it. The issues I have to deal with:

• The two QA people have no coding experience so any tool that requires significant coding will require more development support.
• The application will be run in IE on the IIS webserver. No other combinations need be tested.
• The application is really a document creation and management system. Once the documents have been created and approved they're submitted to an outside system.

My discoveries so far (via this list and the opensourcetesting.com) and some follow-up questions
Tools:

• Selenium seems to be written about the most although some users complain about slowness and less than intuitive api.
• Watin (now supports firefox) api seems to be well liked – but assertions have to be written in manually i.e. in code.
• Apodora – never heard of this tool before. From Open Source Testing: "Apodora is a framework/tool for automating functional testing of web applications. It provides the user with programmatic control of the web browser allowing them to interact directly with the browser's user interface. It uses a database backend in order to remember how to find your html elements. This also makes your scripts easier to maintain."
• FitNesse .NET – not entire convinced that the application is well suited to FitNesse style tests. But the team will make the decision. I really think I need to read chunks of Gojko's first book before passing any real judegement.
• Canoo WebTests – xml may be hard for customers and non programmers to write. Am I missing the point?
• Concordian – seems like a clever idea that will create a lot of work for developers.

Frameworks/IDEs

• Robot Framework – “Robot Framework is a generic keyword-driven test automation framework for acceptance level testing and acceptance test-driven development (ATDD). It has an easy-to-use tabular syntax for creating test cases and its testing capabilities can be extended by test libraries implemented either with Python or Java. Users can also create new keywords from existing ones using the same simple syntax that is used for creating test cases.”
• CubicTest – an Eclipse Based IDE for Selenium, promises “…It makes web tests faster and easier to write, and provides abstractions to make tests more robust and reusable.”
• StoryTestIQ – “STIQ is a mashup of Selenium and FitNesse. It is "wiki-ized" Selenium with widgets and features that make it easier to write and organize Selenium tests.”

Questions

Selenium

• Are the problems with Selenium slowness, need to insert delays after entering text and less than intitutive api real? (http://adamesterline.com/2007/04/23/watin-watir-and-selenium-reviewed/, http://www.testdrivendeveloper.com/2008/07/22/ComparingWatiNAndSeleniumForUITesting.aspx, http://hammett.castleproject.org/?p=120, ).
• Do you spend more time debugging the tests than finding real problems?
• Is Jay on the money is his positioning of Selenium: http://blog.jayfields.com/2008/07/immaturity-of-in-browser-testing.html “Selenium is best used by developers or testers when testing the most valuable (to the business) happy paths of a Javascript heavy web application that must function in several browsers”

Watin

• Does it support dialogs now?
• Does it suffer the same slowness problems as Selenium?
• Is it as hard to use with IE as Selenium can be?
• Is it compatible with Robot Framework?

If you’re using Selenium are you using any wrapper framework/IDE?

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or
Consulting please visit the corporate site: The Agile
Consortium.

So it seems to him that Jsunit is the only choice we have. It is not perfect though because it does not provide an easy way to apply  the TDD process for the following reasons:

• It does not provide a simple and integrated way to run JavaScript unit test
• It forces you to write the unit tests in a html file instead of a .js file.
• It forces you to have a local installation of the jsunit framework in order to avoid absolute hard coded path to reference js unit files.

As a consequence, you have to switch back and forth from you IDE and all the browsers we want to support while "TDDing" in JavaScript. It is feasible but doesn’t seem very effective.

I tried asking about this on StackOverflow generated some interesting answers:

• Look at the Dojo Object Harness (DOH) unit test framework which is pretty much framework independent harness for JavaScript unit testing and doesn’t have any Dojo dependencies. I found a very good description of it at Medrix Observations: Dojo D.O.H. Unit Testing. Interestingly we have at least one team (Yvon’s) that is experimenting with Dojo. (got several recommendations for this)
• Apparently MochiKit – yet another library has a framework called SimpleTest buried inside it.
• Yahoo Unit – a standalone tool from Yahoo.

Asking on the Test Driven Mailing List got another batch of answers:

• QUnit from jQuery (got several recommendations for this)
• Mocking tool for JavaScript
• Use GWT and do all your work in Java

In addition two people didn’t answer the question directly but instead sent my in the direction of some books:

• Secrets of the JavaScript Ninja by the project lead for jQuery (which will have a chapter on Unit Testing)

Conclusions

There isn’t one good place to ask JavaScript/Unit Testing questions. The best so far seems StackOverflow.com seems to be the only real option.

Of the Unit Test Frameworks the real options seem to be:

• JSunit
• The Dojo Object Harness (DOH) unit test framework
• QUnit from jQuery
• YUI Test: see YUI Test – The New Kid on Block

I also did some digging for Mock Frameworks and have only come up with a list of tools:

• JSMock – JSMock provides expectation recording and matching, and has the ability to return, throw, and stub on object method calls
• Jack – The project aims to help developers write short and readable JavaScript tests.
• MockMe – written because of Johanne’s dissatisfaction with other JavaScript Mock tools.
• QMock – very new

There is some good writing that will give you a flavour of TDD with Javascript:

• Test Driven AJAX a presentation from Agile 2008 (long but through)
• TDD and Javascript with JsMock
• Test Driven Javascript
• TDD and Javascript with JsMock

Best ongoing sources: Pathfinder Blog and Ajaxian seem to be good reading.

What tools did I miss? Are there any good JavaScript mailing lists where the participants discuss TDD?