Once a week we perform a test where we encourage everyone who works on the product line (~100 people) to follow a script and test several different clients from the product line. At first we started to do this so we could get a feel for the real world performance of the different products. Over time it has become more of a way for each team to see what the other products are like, how their own product fits into the product line, and a bit of a sanity check that everything still works well together. Sometimes it helps promote discussion around design decisions made as well.

There is some effort required by everyone involved. Participants need to download the newly updated clients and "sign in" (which can take 20min) and the organizers need to install all necessary Webserver and Database updates (which can take upwards of a day). The actual event takes about 30 mins.

Recently attendance has been at an all time low (Maybe 10 people join) and we've started to question if the effort is worth running this event every week. We still think that we can get value out of this type of event. We don't want to make it a mandatory event

How can we get value out of this kind of event and increase participation?

migrated from programmers.stackexchange.com Apr 3 '13 at 15:16

This question came from our site for professionals, academics, and students working within the systems development life cycle.

  • God that sounds like hell on Earth. Your employees are clearnly indicating that the morale gained (or real work achieved) is more useful than this. Are you really going to be able to increase the value enough to make it worthwhile? – Telastyn Apr 3 '13 at 14:49
  • Thats what I'm asking. Is there value for doing something like this? We have no qualms about getting rid if it entirely. – Spacebob Apr 3 '13 at 14:53
  • How much of the drudge work (download and "sign in", plus the organizer's work) can you automate? Do you make all your customers go through that pain too? Granted, they only have to do it once, but it's part of their first impression of you. – Dan Pichelman Apr 3 '13 at 15:00
  • I think as much of it as possible is already automated. I said the "download and sign-in" takes 20 minutes because since there are many international participants the actual download can take awhile. – Spacebob Apr 3 '13 at 15:08
  • So my choice is to play with somebody elses work that I get no credit for OR get my "assigned" work done that was vastly underbid and effects my performance evaluation???? – Dunk Apr 9 '13 at 22:56

Once per week makes it seem like drudge work, rather than the helpful, unusual, fun(?) event that it could be. Do you really need this every single week?

The biggest obstacle I've found in the past is lack of Management buy-in. If your boss isn't enthusiastic about helping out, you won't be, either.

In the past, I've organized some testing sessions for non-QAers. We called it a "Test Fest". (fun, fun, fun!)

It usually turned out to be a very valuable exercise.

In order to get buy-in:

  • Advertise. Make it sound like an exciting opportunity to help the product be better with everyone's input.
  • Plan a recap session immediately after the test. During this recap - solicit feedback about the user experiences, but most of all thank everyone publicly!
  • Food always helps.
  • Sometimes prizes (the best bug?) can help. Nothing elaborate - a box of chocolates, a bottle of wine, something like that. Winning a prize is more important than the value of the prize itself.
  • Make sure that people know what they are getting into, how long it will take, and what they will be expected to do. Many people can carve out an hour or two from their schedule if they know far enough in advance.
  • Make sure that people know that you will give them the details of what they will be doing. Some folks may be worried that they will look stupid if they don't know what to do. Don't let them be worried.
  • In my sessions, I had 5 or 6 exercises to be carried out, in any order the tester chose. I handed out sheets with all the instructions needed, screenshots, etc, along with any data needed. Each exercise was on one page, with space to write down any unexpected results.
  • Make sure management is committted. You don't want folks to worry that their managers would rather that they didn't participate.
  • Have assigned "helpers" - people who can run over to a tester who needs immediate help, so that they aren't blocked for any length of time.
  • Make sure that users note the time when they start and end a task, and when anything unexpected occurs. This can help correlate their observations to messages you find in the logs.



I'm not sure you're asking the correct question here. Or at least not asking questions in the right order.

Before asking how to extract value and encourage attendance at this event, you should ask whether you need to do the event at all.

Currently, your company is spending thousands of dollars in employee time on this event every week. But it does not sound as though it knows what it wants to get out of it.

It's possible that the event once had a purpose but now has outlived its usefulness.

Before expending the time and energy to reformulate the event, determine:

  • The need/goal of the company
  • Whether this event is the correct medium to achieve that goal
  • How much the event costs the company
  • Whether that cost justifies the anticipated value (if the goal is met; AKA: ROI for the event)

Only then, if this event is deemed worthy, should you answer how to architect it to provide the most value for both the company and the participants.


Have your IT department throw the clients up on a terminal server? This way, people testing them could just remote into the terminal server without needing to download the latest version. Instead of your entire test population downloading and updating, you only need to update the products on a handful of servers.


There is some effort required by everyone involved. Participants need to download the newly updated clients and "sign in" (which can take 20min) and the organizers need to install all necessary Webserver and Database updates (which can take upwards of a day). The actual event takes about 30 mins.

Then you ask

How can we get value out of this kind of event and increase participation?

I guess, if you are asking how to get people excited to do nearly a full day worth of voluntary work (or just an hour, not sure how to read "upwards of a day") on a weekly basis for something you aren't even convinced (as the event facilitator) as having value, well... there's not really an answer.

We still think that we can get value out of this type of event.

It sounds like you don't even believe this has value. And yet you wonder why people aren't attending (and it's lots of non-value add work to setup?).

The way I see it you can do one of three things. Either mandate people go to this event, make the event have actual value to the developers (you don't believe this now), or have people who are dedicated for testing doing this event frequently (I hope you have some sort of QA/test group).

It might help a lot to define for yourself the, "why are we doing this?" and "what are we trying to get out of this event?" - from your question, it sounds like you are more from the, "hey this is cool, we should do this, I think it's good, mmk?" perspective.


I see 2 ways to do this:

Increase the value of participation for the product teams

I think doing something like providing specific performance metrics and testing newly implemented features would help provide valuable feedback to the product team.

Increase the value of participation for the participants

Right now every participant goes through the same script every week. I think a rotating script that includes new features as they are developed would encourage more people to attend. This would require that the product owners to create scripts for these features as they are developed and The Database schema would have to be updated to ensure that this new functionality could be demonstrated.


How about preparing the clients and updates in advance and install them in black boxes that allow participants to approach the testing as if they were a customer browsing for a new cell-phone. Try to eliminate as much of the effort involved by automating events to reduce downtime.

It appears participation has decreased because the time investment and commitment are too much. I think you could vie for improvement in areas such as this and bring back the joy to this activity.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy