Drop in office hours for engagement and change management

[Lisa Yeager]

We are using Jira and the Atlassian ecosystem to drive capacity and workload management and planning across approximately 200 users with very different levels of system experience and understanding. These are not software development teams, rather, that are focused on statistical analysis for clinical trials. 

To support rollout and adoption, we are planning to convene regular, drop-in office hour sessions for all users. Has anyone else tried this approach in a similar context and if so, what worked well and what were your lessons learned?

[Alex Ortiz · Accepted solution]

I've done a few hours before. . and folks tend to be a little shy.

You may want to have some pre-determined questions. Maybe folks can email them in before, or submit them somewhere else.  This is just to get the conversation.  Once you are in a good flow, folks start opening up.  But those first few 5-10 minutes can be quiet at the beginning.

[Alex Ortiz]

I would also suggest having dedicated sessions, maybe 30 minutes, where you demonstrate some capability and then leave time for Q/A.

[Lisa Yeager]

Thanks, Alex. Yes - definitely anticipate some shy folks here. Especially since we have quite varying levels of experience with the toolset. 

[Aaron Geister_Sentify · Accepted solution]

@Lisa Yeager 

First want to say welcome to the community. Hope you find all the answers you need. 

I have used the open office hours method many times and or a lunch and learn with Q&A. I think this is not only beneficial for a team, but it is revolutionary. No system is just automatically learned. 

What works well for me is to have Jira on a screen and showing the teams how we want the system to work for us. Then allow to ask questions. 
Setting an outline of what you will cover is helpful too.

Please go forward and do this and then iterate on the possibilities and feedback you get from it.

Respectfully, 

Aaron

[Lisa Yeager]

Thanks, Aaron - we've had lunch and learns and a couple drop in help sessions that have had mixed success. How long did you run your office hours (eg weekly for an hour for 3 months)? 

We are doing a very structured paired testing process with the users who are helping to configure and test the system, and trying to figure out the best timing to offer drop ins, particularly since we want to provide transparency about the work that is happening...but not take a good deal of time away from the configuration effort. 

[MattD · Accepted solution]

I helped run office hours twice a week for an hour each time. If people turned up, we helped them. But If not, we got on with something else. Sometimes people would tell us they were going to turn up, sometimes not. It was a real high point of how we provided Atlassian tools to a large organization. We made good contacts in a huge range of departments and really got a sense of what users wanted.

We also had a substantial set of documents ready to refer people to for the most common questions, which helped us handle up to 5 or 6 people in each hour. People loved having a time to just ask their questions in a personal way. Thoroughly recommend it!

[Lisa Yeager]

Thanks, Matt! Was your audience in the same size range as ours? And did you just take folks' questions in the order that they arrived, or did you have the ability to offer breakout/parallel conversations (esp if these were virtual)

-L

[Craig Wattie · Accepted solution]

I've taken this approach twice, with mixed results.

Once where we had rolled out an agile framework across the company and wanted a way for users (from many different roles, not just SMs) to ask questions and give feedback to iterate our framework around. This was great in theory but only worked when we actively asked people to bring specific concerns to the call. After the initial framework rollout interest dropped off considerably.

The other instance was with a lean software engineering team that would primarily share code they had written. From there it was either other engineers jumping in to solve or improve the work, or a discussion on how one approach could be applied to other products or teams. They would also discuss new industry trends or upcoming language features. This worked really well because it was more role-focused and tended to get into more detailed problem solving so the teams all felt it was a good use of their time.