Using the Projector for "Live Screening" Sessions

So a technique we’ve been utilizing recently is projecting my screen all day, and running group sessions in a drop-in format with all disciplines involved.

We exploited a simple technique because I was working with some client SME’s to execute their QA processes and make them proficient in using the new features, in preparation for their Go Live.

We all wanted to see how the system behaved and work some real business examples through the software, so we just used the projector. This was useful so we did it some more, then we formalised the objectives a little, and extended the time frame to all day. This resulted in a cool workshop format for group testing and debugging.

 

The Format

We literally ran the session like a triage drop-in with 3–5 SME’s, with plenty of whiteboard space available to write tasks, problem scenarios, and areas for research.

We took fired up the projector, took a recent test plan and worked through that to get us started, and to make sure we had all the software and environments correctly configured for the day. This took maybe an hour, and it was good for the SME’s to see what we had already tested at a component level and see our automation.

We then took their implementation plans and executed their plan practically on the system in a test environment. This took two or three hours, as we worked through the examples, find found issues, worked through alternatives, debugged the original issue, got a fix and re-tested the fix.

We turned this into plans on our relevant boards and actions for members of the group to take away.

In the end I left the projector beaming my screen all day — we then worked through a whole manner of problems as a team (aside from the original problem with started with) — running through more scenarios through live, writing examples with them on the whiteboard, and showing them more of our automated tests in action, and some of our wiki’s, our backlog, and our project plans.

I also left the projector beaming after the SME’s went home, but used the same techniques to involve the engineering team in debugging and solving problems.

 

Demoing some features. (See the whiteboard in the background with tasks and plans)

What's so special though?

Nothing, really, no black magic.

I suppose the only thing you wouldn’t normally do it just beam the projector all day and open up your work publicly like this. Generally, people do this for an hour during a meeting, but by running it for the whole day, and encouraging a team experience by using the team objective, and working a variety of problems, it really brings the whole working atmosphere to life for the day!

 

Benefits

We got so much achieved. We signed loads of stories off, debugged a load of problems, and the client left with real confidence, not only in our software but the thought processes which go into creating the solution.

The client SME’s got a feeling of some of the challenge’s we as the vendor's face and this was so valuable because we’ve been able to run planning sessions using the same technique — practically demonstrating and illustrating certain aspects of the system, and have the SME’s show you how they use it by walking through their business scenarios.

The biggest overall (and quite unexpected advantage) was group debug ability — when I pulled engineers in to help debug certain issues, we could as a group refer to the large screen, and get into the detail with the SME’s. The engineers really got a

Also because it was up on the screen with an audience it felt “live”, everyone wanted to solve the problems. The featured photo is a powerful one — in that photo is our CEO, Head of Dev Ops and some Senior Engineers, after hours, solving problems on the live screen!! Haha! It was a really awesome moment.

 

Some Tips:

  1. Have everyone around the same table with their laptops - its a team exercise, with everyone working on the same problem to achieve something cool or new (The Objective) on the live screen.
  2. Have loads of whiteboards around, to write down ideas, bugs, or plans.
  3. Have support on stand-by- let your team know this is happening, tell Dev-Ops they might be required too.
  4. If you're projecting all day, remember everyone can see your screen, so maybe close down slack/Teams/Skype.
  5. Avoiding long pauses and silences by having a variety of goals to achieve rather than one strand of work. This allows you to hop between different streams and make progress all day while you're waiting for fixes or deployments. For example, we have run days with multiple objectives:
    1. Sign off this Dev Feature ready for handover to the client in sprint B
    2. Remove all remaining blockers on clients Sprint A in-house regression testing
    3. Review & the proposed backlog for Sprint C
    4. Review and demo the Go Live implementation plan, walk through various tasks.

 

The Future

The technique has become somewhat of a standard operating procedure on our team when SME availability allows. The understanding it allows, and the concentrated progress which gets made is so valuable it is hard to overlook.

The approach described above is quite resources expensive, so the value of the group objectives has to be weight against the cost of having valuable SME’s around a table. The technique scales up and down though, so you can be smart about how you apply it.