At the Agile 2009 conference I attended a workshop by Alro Belshee and Jim Shores on “Slow and Brittle: Replacing End to End Tests“. In this workshop they presented a couple of cases where End-to-End checking (testing) became a huge issues as the tests became slow, brittle and expensive. While I agree with them and have seen cases of checks (not just end-to-end checks) becoming a maintenance nightmare. Many times, checks create an illusion of safety, but really don’t add much value.

While some of it can be attributed to the poor scope/focus selection for checking (end-to-end or unit), I also think a lot has to do with poor skills, lack of understanding and rigid/flawed organizational structures.

During the workshop, the group I participated in, came up with following points as reasons why people write end-to-end checks:

• Document the interaction and intent
• Being Inclusive: Testers and Programmers can collaborate
• Scaffolding
  • Good starting point for dealing with legacy code
  • Early win: Easy to show people how to automate checking and get them started
  • Good starting point to learn/explore more about the system
• Freedom and Confidence to Refactor code
• Ease: (sometimes they are very easy to create)
• Highlight Design Problems: If you see duplication in your tests, sometimes it could mean poor design.

I know other teams had several other interesting points. So the question is what other approach can you use to do away with end-to-end checking?

One of my proposals was to look more serious at “Eating your own dog food“. I also very much digg the idea about “Self-learning and Self-testing systems”.

Testing is explorative, probing and learning oriented.

Checking is confirmative (verification and validation of what we already know). The outcome of a check is simply a pass or fail result; the outcome doesn’t require human interpretation. Hence checking should be the first target for automation.

James Bach points out that checking does require some element of testing; to create a check requires an act of test design, and to act upon the result of a check requires test result interpretation and learning. But its important to distinguish between the two because when people refer to Testing they really mean Checking.

Why is this distinction important?

Michael Bolton explains it really well. He says:

A development strategy that emphasizes checking at the expense of testing is one in which we’ll emphasize confirmation of existing knowledge over discovery of new knowledge. That might be okay. A few checks might constitute sufficient testing for some purpose; no testing and no checking at all might even be sufficient for some purposes. But the more we emphasize checking over testing, and the less testing we do generally, the more we leave ourselves vulnerable to the Black Swan.

Distributed Stand-up meetings essentially becomes a lot of ceremony and the true value of communication, feedback, team bonding, working towards a common goal starts falling apart.

If you have done distributed stand up meetings you would have noticed that its not easy to communicate to a bunch of people on the other side of the phone. (Telephonic conversations are good when there is just one person on the other side. As the number of people on the other end of the phone starts increasing the quality of communication starts dropping).

Also if you have noticed, when a person does not know who is listening on the other side of the phone, they usually speak very little. May be they just talk about 2 out of the 3 things (What they worked on and what they plan to work on. They skip the learning/roadblocks part). I would argue that you can understand who is working on what by looking at the story wall (you don’t really need a stand-up for that). More on this @ Standup Meetings: Missing the Forest for a Tree.

People have tried using Video Conferencing and other techniques, but it usually falls short of encouraging and fostering true communication. It also leads to a lot of time wastage and ceremony (prep-time, getting to the video conferencing room or setting up the video conference tool on your machine). IMHO, its easy to get distracted when the person speaking is not in front of you. So your attention span starts reducing and if you have a team of 8-10 people, it would be difficult to comprehend and remember who said what.

So if Distributed Stand-up meetings as they stand are not the best options, what else can we do?

I have 2 suggestions:

1) Really light weight option: User a chat (conference) room. Everyone from the team shares their bits simultaneously and then people have a small chat to decide the game plan for the day. This has a nice side effect. These notes get naturally persisted in the chat history. So if someone misses the standup or if someone wants to go back and refer to some day’s standup notes, they have it accessible. Also creates a felling of async, non-blocking io (Remember the good old open source days, this is how we used to work).

2) Slightly more process centric: One-on-One Standing Meeting: Each location has their own stand-up meeting at beginning of their day (or what ever time is suitable for the local team). And then, when both teams are online, one member from each team will update the other team(s) about their progress and anything else which is important that might affect the other team(s).

Usually people think of this as a Scrum-of-Scrums where ScrumMasters from each team present their status. We don’t use ScrumMaster. Instead we make this a rotating responsibility of each team member.  Which means, one team member from each team will represent their team in the standing meeting in a round-robin fashion per day. Next day, the person who represented the team in the standing meeting, not only shares their progress with others, but also shares other team’s progress with the rest of the team. The next person in the queue then attends the next standing meeting. These meetings are usually very light weight and are done in 5-10 mins.

P.S: One pant does not fit everyone, find out what works for you and evolve from there.

So, when it comes to using a tool for Story Wall (read it as Agile PM tools): My first reaction is, you don’t need them unless you have used physical story wall (task boards) enough that you understand their limitations and you want to evolve.

If you are a small, co-located team, it is just simpler to use a physical story wall backed with a wiki or a spreadsheet. As the team grows (smell something is wrong), you might want to break down the large team into smaller self-contained (cross-functional) teams and continue using the same practice at 2 levels.

• Team Level: Each team manages the user stories they are working on.
• Meta Level: At a meta level, we manage the features (epics) each team is working on.

This scales fairly well.

For distributed teams, I’ll use the following approach:

1. Start using Physical Story wall at each location backed with a wiki or a spread sheet. How the story wall is used really depends on how the work is distributed across teams.
   • If all the development and testing is taking placing in one location (offshore), then I would only use one story wall at that location.
   • If development takes places in both location, I would duplicate the story wall on both sides and during the “one-on-one standing meeting” (not a distributed stand-up meeting, I don’t think they work), each side updates their story wall with updates from others side. This ensures both sides are really collaborating.
   • And sometimes, teams can maintain their independent story walls and then sync up once a week.
   • One needs to figure out what works best for their situations.
2. Once the team understands and matures using this. Next step could be to do away with the physical story wall in each location and just use a Wiki or a Distributed SpreadSheet (something like GoogleDocs) to maintain their backlog and story wall.
3. If you belong to an organization where everything has to be “enter-price” class, then I might consider one of the following tools:
   1. Mingle from ThoughtWorks
   2. Silver Catalyst
   3. Jira and GreenHopper
   4. VersionOne or Rally
   5. And so on…

You might ask, what about tracking, planning, project management dashboard (fancy charts: burn-downs) and so on. Well, IMHO a lot of it is hype. You don’t really need all of that. You need some of them and its simple to generate them without having to use a heavy weight tool that adds more complexity than it takes out.

At one point, I really wanted to try out a tool for distributed teams. There was nothing good available at that point (2004), so I wrote one myself using RoR. The tool was fine, but it was very difficult to get the same feel as real story wall. So I dropped the tool and went back to physical story wall (this was a distributed team).