Learning through teaching

Posted on by
3

I am not sure ‘teach’ is the right word, probably it should be skills sharing but anyway let’s call it teaching for ease. I was keen to talk about how teaching others has helped to improve my own skills and understanding.  Since I discovered the magic of Tableau and then went on to implement Tableau in my organisation, part of the journey was getting my team trained.

After purchasing my first Tableau desktop license I had a little bit of training to get me started but then went on to teach myself. I then built the first dashboards for our pilot site which all worked and did the job they were intended to do so I felt pretty confident I could teach my team how to use Tableau desktop. Despite coming from a family of educators I wouldn’t say I am a natural teacher but I did my best to get everyone going with Tableau.

I created a small syllabus of things that the team needed to get them started and we blocked out Wednesday mornings for sessions. The team quickly picked up the skills they needed, and started to teach themselves, helping each other learn new tricks and use Google for the rest. Just after implementing Tableau I went off on maternity leave for 8 months so left them to it! On my return Tableau was firmly embedded in the team and their skills had rocketed, leaving me to catch up. We then all topped up our Tableau skills with some formal training through Interworks which really helped us to push further on with our dashboard developments for the organisation. 

The internal introduction to Tableau followed up by formal training once people have got to grips with the basics seems to work well, so we have continued in this way for the last few years. I have continued to teach my new staff and colleagues the basics of Tableau ever since. I passed my Tableau Desktop Associate Certification last September and although I had been using Tableau for a few years I had to do a lot of revision to get me through it. There was lots of functionality in Tableau that I simply hadn’t ever used, and I was also doing things in Tableau but didn’t necessarily know why.  I am definitely no Tableau Zen master by any stretch of the imagination and actually through training some of my team again I realised I was still doing stuff in Tableau with results but couldn’t explain why! So I have been trying to make sure I do understand what I am doing so that when I show others I can explain why, and encourage them to understand why certain actions result in certain outputs. Therefore learning through teaching!

I have implemented a Tableau competency framework within our organisation for people who are responsible for building dashboards. This framework is based on Fi Gordon’s Tableau Quest (thanks Fi – https://www.vizchic.com/tableauquest/). I have named one of the challenges ‘train the dragon’ which basically requires them to present/train a specific Tableau functionality to others. On a mission currently to encourage my team to take on this element of the framework so their skills continue to grow.

I have also started running workshops on Agile project management this year, and so far have run two workshops with another couple planned in September and October. Again I am no Agile project management expert, and I have no certificates to back up my skills. But what I do have is a few years under my belt using Agile project management within my team and seeing my team use it with good results. The external courses some of my team have attended recently had been poor (all theory and no practical!) so I thought I would try do this myself with help from my colleague Lucy based on our experience and knowledge. The workshops have gone pretty well, with positive feedback and people putting their learning into practice since; which is great! As I said I am no Agile project management guru, but by having to teach some of the theory it has forced me to really understand the theories and methodologies that underpin Agile. After each workshop we have run I have come away more confident about using Agile within the organisation and our team, simply by actually understanding it more through teaching others.

I would encourage everyone to ‘teach’! It will make you more confident in your own ability; you know more than you think you do! You will learn why, because when you share your skills with others they will ask ‘why?’, and you need to know the answer or be able to find out (even if it’s together!). It doesn’t matter how big or small, it doesn’t need to be a whole workshop or a full training session just start sharing what you do know!

Hope you enjoyed reading my blog!

Dude, where’s my dashboard?!

Posted on by
Reply

One of the most useful things we have ever implemented in our Information Team is unique identifiers for our ad-hoc data requests, routine reports and statutory returns. I can’t take the credit for this. An Analyst who joined my team about ten years ago (and has since moved on) brought this from his previous job. It was so obvious when he suggested it!

It helps so much when people are talking about a certain report. We can make sure we are all talking about the same report. It makes our ad-hoc reporting process easier too. If someone wants a refresh of an ad-hoc that has been requested 6 months earlier we will ask them for the ad-hoc ID and we can quickly find the report they are referring to plus the query that had been written to support it. This has massively streamlined the ad-hoc process, and reduced the need to recreate something from scratch. We have different prefixes depending on the type of report (ad-hoc, statutory report etc), and it made our folder structure more organised too.

Over the last decade pretty much everything we do has been given a unique reference identifier; datasets, data warehouse fact and dimension tables, key performance indicators, procedures etc. It make things so much easier to find, and ensures that we are always talking about the same thing!

Moving forward to the implementation of Tableau in 2016, although we have a Tableau report log which allocates each workbook with a unique reference identifier (TABxxxx) I wasn’t keen to put these IDs on the Tableau server for our consumers to see. I wanted it to seem less formal for our dashboard consumers, and I never thought there would be that many dashboards in each area that would mean we would get confused about what dashboards we were referring to! During the implementation a few of my team disagreed with me, and kept pushing for IDs being published in the names of our dashboards. I finally lost this battle which was made easier to lose as I was soon off on maternity leave and had other things to worry about!

3 years on and I still get reminded of my bad decision by at least one of my team! I will admit that I was wrong (and this is rare occasion for anyone who knows me…). There are now over a 1000 dashboards across our Tableau server site, and most of the dashboards have their unique ID in the title of the workbook. The ones that don’t are generally the ones that I published during implementation (sorry!). We will definitely be fixing these in our next upgrade.

Like everything else we did prior to this, the IDs make it so much easier to support our Tableau consumers. When someone contacts us with issues or changes to a dashboard we can simply ask them to tell us the ID, and we can make sure we respond to their request quickly and effectively. For those that don’t have IDs we have to ask for a link, or try and find it, which isn’t as effective especially if the request has been emailed over. Plus it is then not as easy to record the info about the issue on our Information request database for someone to action later. We don’t use Tags on Tableau (though it is something we are thinking about), but the search area of Tableau works really well with the IDs.

I have learnt my lesson about IDs, and recently created some new committee reports which contained a lot of key performance indicators (40+). Whilst creating these I decided to add an ID next to each indicator, and page number on each tab of the report so that when the committee were talking about a certain key performance indicator they could reference the page and ID allowing everyone to turn to that indicator quickly. It went down well, and will really help when changes are needed too.

So if you are just about to implement Tableau server (or re-looking at the way you navigate around Tableau or in fact navigating anything similar) I would absolutely recommend adding unique reference identifiers to each of your workbooks. It makes life so much easier – it’s a real no brainer!

Hope you enjoyed reading my blog!

Why Agile Project Management could work for you!

Posted on by
3

About 6 years ago I started to hear a lot about Agile Project Management, Scrum and Kanban, and was keen to understand what these things were all about and whether we could use these methodologies in my team. One of the team went on an Agile Project Management course and came back really enthused. So we took one of our big development projects and tried to run it using the principles of Agile Project Management. Whilst we got some positive results, it didn’t really take off. I think the biggest problem was that we hadn’t considered how this could work alongside our day to day work, and which developments would suit this approach.

About a year later we had a major issue with one of our statutory submissions. The main cause of this was a reliance on a key individual who was juggling lots of different work, supporting other staff plus constantly responding to day to day queries. Juggling competing demands was a real challenge for the team and one that is common in most workplaces. I needed to find a solution to the problem relating to this submission which included removing the reliance on one individual, and ensuring we had a quality assured and robust process in place for this submission. I decided that we would re-look at using Agile project management methodologies to get this sorted. I spoke to senior management in the organisation and asked them to support us solving this issue through using Agile Management. It was really important that I got this support so that senior management could help me make sure people understood the impact this could have on our other workload.

We set up one of our offices as a ‘sprint office’ and identified key stakeholders, a product owner, scrum master and the development team with a mixed skill set. We sat down and agreed a clear Product Backlog; this then allowed us to agree the Sprint Backlog and the timescales that these could be delivered in. We agreed that the development team would work on this project from 10am to 4pm for 2 weeks allowing time at the beginning and end of the day to catch up on emails, pick up any other work and support the wider team. Between 10 and 4 they would turn off emails and phones, and no one was allowed to disturb them unless it was something urgent. Even then they had to come via me so I could understand why they needed to interrupt them. In practice no one actually needed to disturb the development team and everyone was happy to wait to talk them before 10 or after 4 without a detriment to the wider team and our other workload.

At the end of the two weeks we had got the products that we had agreed to during our Sprint Planning Session. During the Review and Retrospective we agreed to have an extra week to improve them even further. Everyone was keen that we didn’t wait to do this so we started the final sprint the following week. The project/sprint was a great success; at the end of the 3 weeks, knowledge had been shared, the process had been completely re-built, the process had been tested with a quality assurance element incorporated, and procedures had been written and tested by the development team and by others in the wider team. This meant that we had now removed a reliance on one individual; we had a quality assured process and could assure the wider organisation and senior managers that there was very little chance that we would have any further issues. With this new approach having such great results we were able to get support from the wider organisation to use this methodology in the future.

I had always worried that if I took a few people out of the team to work on something in protected time that we wouldn’t be able to manage the demand and priorities outside of this. It was great to see that this wasn’t the case and I was able to challenge our priorities and manage our workload alongside using this methodology. This was mainly because people could see how many benefits Agile was delivering and they only had to wait slightly longer for other work.

Since then we have continued to identify and run projects using elements and principles of Agile project management with varying success. The varying successes are generally down to having the wrong mix of skills in the team, not always having a clear Product/Sprint Backlog and not always having engagement from key stakeholders. Despite this we have learnt from both those that have gone well and those that haven’t,  and worked out what recipe is required to make these a success, and  the results are always an improvement on what we would have previously been able to do.

It is also brilliant to get positive feedback from those who have been part of these projects, they have really welcomed having focussed time on something so they can do a really good job on this and they always learn something new. It is great to see the team motivated to run sprints and I love seeing real collaboration in action.

I also try to embed the principles of Agile project management into our approach to managing all our workload. It’s not always possible to have sprints to do everything as there is not always enough resource and capacity to work in this way. However one of the main principles of Agile is time management so these can definitely be applied without having a formal project.

I recently organised a one day ‘hackathon’ for my team.  I was reluctant to call it a sprint because it was one day and we weren’t going to be using kanbans or have scrum meeting plus there was 17 of us. During a previous away day we had all agreed that due to the staffing changes over the last 18 months we really needed to revisit our processes within the team. So we hired a room big enough for the 17 of us, I organised the day into sections and split the team into 4 groups. We had 16 processes to re-write so each group took 4 processes and had about an hour to write their four. During this first hour the group discussed the processes and debated how these were constructed. Then we circulated the processes round the groups giving them 40 minutes for the following sets of processes so they had 10 minutes per process to review it and add to it. By the end of the day we had 16 processes drafted which everyone in the team had had chance to review and add their ideas to. So not only did we have processes that we could now take back into the office and test out, everyone had been involved in writing them, and everyone had learnt about other processes from other work areas in the team.

If we had tried to write these processes alongside our usual work they would have been written probably in isolation with little input from others in the team. It would have also taken weeks to get them done and embedding these processes into practice would have been more challenging. The processes are now more efficient and all have a similar structure. By taking just one day out of the office (less than 7 and half hours) we have progressed a very important piece of work, and we have only delayed our wider workload by a day. No different to having an extra bank holiday thrown into our working week!

I would highly recommend finding out more about Agile Project Management and thinking about how this could be embedded in your work place. These project management methodologies are primarily used for software development but I definitely think they can be used in most business settings. It is also worth noting that if it doesn’t work then you haven’t lost much time to try things a different way, you may have lost a day or a week but you haven’t lost months trying something that literally doesn’t work. Fail fast and learn quick!!

My favourite things about Agile Project Management:

Kanban charts – I love using a Kanban chart to manage a scrum. All you need is post it notes and a board to stick them to. There is something so nice about picking up your action on a post it note and moving it through “to do”, “in progress”, “testing” and “done”! Take photos each day to see how the board changes during the sprint, and how all the “to dos” end up (hopefully) in the “done” column!

Time-boxing – this is such an obvious thing but we all lose time doing certain tasks and trying to perfect elements of your work and end up working late. Be strict on the time and then you will get through the actions that you had planned.

Clear Product Backlogs and Sprint Backlogs – It is so important to have a clear project scope. Don’t over promise, agree what can be achieved during the time you have with the product owner, scrum master and development team. And allow time for problem solving! This will all help to reduce the chance of scope creep and ensure you complete everything you had agreed to complete.

Focussed time – this is one of the best things. How nice to be able to concentrate on one specific job at a time without interruptions. Guaranteed to give you a better output!

Collaboration – working in this way means real team working and collaboration! It gives you opportunity to share ideas, problem solve together and learn together.

Scrum Master – having a Scrum Master coming in and keeping you on track is just brilliant. They also take away any impediments so the development team can concentrate on the things they can get through without been pulled off the project to liaise with people outside of the project and solve problems that are probably too big for the time allowed.

Engagement and Product Owners – having engagement from key stakeholders during the sprints means that they are involved all the way through the process, they can give feedback along the way, and there are no surprises at the end so they end up with something that they have helped to shape.

Iterative development – much better than getting to the end of a build and finding out that it isn’t quite what the customer wanted. Keep sharing and tweaking until it does the job it’s intended to do. Think of it like having a renovation to your house, you would constantly be checking in with the builder to see what they are doing and changing your mind along the way!

Top tips for making this a success:

Go on a course – classroom courses for Agile are much better than online. You need to feel how this works not read about it. Make sure the course includes a practical exercise to test out the theory.

Sort out the space you are planning on working in – make sure it has the right equipment, lots of whiteboards and a door you can shut. Remove all interruptions (divert those phones and put your out of office on your emails)!

Get a good Scrum Master – make sure you have someone who is able to make decisions, lead a team, and take away impediments and get them sorted.

Make sure to have a development team with good mix of skills and knowledge – they need enough knowledge and the right skills to progress the task, and are able to organise themselves to get through the work.

Time-box like a ninja – be strict! If you say you will finish at 4 then finish at 4. Rest time is as important as focused time! If you say you will give a task 20 minutes then stick to it (you will learn by trying, so this may come with experience). Check out the Pomodoro Technique!

Make sure your product owner and other key stakeholders are available during the identified sprint time – This is critical to make sure the end product delivers the agreed objective and you are not guessing what you think they might want. The time allowed is strict so engagement needs to be the same.

Hope you enjoyed reading my blog.

If you want to chat more about Agile and time management then drop me a line!

Have you heard the one about a pie chart?

Posted on by
Reply

It’s been almost four years since I attended my first Tableau conference in London and just over 4 years since I discovered Tableau.  I remember sitting in a few of the customer speaker sessions at the conference and I clearly remember one of the speakers joking about using Pie Charts. I smiled thinking I didn’t want to seem like I didn’t get the joke as everyone laughed along!  Then it happened again, another speaker and another pie chart joke!! Fast forward to today and now I’m the one doing presentations for various reasons and I can never resist sneaking in a really bad pie chart to highlight the need for good data visualisation.

So what is the deal with pie charts then? Why are they the ‘in joke’ of the data viz world?! If they are so bad why do they even exist and why is it one of the first types of charts you learn at school?

Most data visualisation books will talk about the use of pie charts and the reason why they get such a bad rep in the data viz world is because the human brain struggles to compare angles. Data visualisation is about making data more accessible and enabling understanding. If pie charts aren’t easy to interpret then they are simply not a good choice of data visualisation.

One of the dangers of pie charts is the use of colour, if you have more than a few slices in your pie then suddenly you have a multitude of colours that might not work together. I have seen so many where there are also similar colours being used and you don’t know which category is which.  I tend to discourage anyone from using pie charts at all especially if they are new to the data visualisation as it is easy to get it wrong. I usually tell people if it’s got more than 3 slices then don’t use pie charts, and if they are still keen to use them to maybe consider using a donut chart instead. The angles in a donut chart are easier to read and you can utilise the space in the centre for extra info, it’s still best to avoid too many slices though.

When I am training new analysts how to use Tableau or running a workshop on data literacy I do tend to talk a lot about pie charts, and I have loads of examples of really really bad pie charts. I personally think it helps to get people to understand what data visualisation is all about.  Rather than just joking about pie charts, I show them why they don’t always work and what other charts work much better.

I haven’t included a pie chart in any dashboard I have built since attending my first Tableau conference. I really struggle with choosing colours that work for my dashboards so I think it’s just better to stick with minimal colour selection and no pie charts!!

So let’s have a quick demo so I can briefly show you what I mean…

Let’s take some little league data using a pie chart to break down the number of runs by 5 different teams:

It is hard to see from the pie chart how much difference there is between the different home team’s runs, the slices all seem fairly similar. You can just about make out which team had the most runs, but you would struggle to see second place.

Now let’s use the same data but presented in a simple bar chart and one colour:

As you can see presenting this same data in a bar chart you can now quickly see that Bears are quite a bit ahead of the other teams, this wasn’t so obvious in the pie chart. If I then sort the bar chart into size order you now easily see which team is in second and third place. That isn’t possible with the pie chart, even if the pie chart had labels on it, it would still take some time to interpret.

I could give you loads of examples to labour my point, and show you alternative charts that work better than pie charts, but I will leave it there! There are lots of great data visualisation books and websites that will explain all this much better than I can. Go check them out!

Thanks for reading my latest blog.

Ella

Reflections of a Tableau User Group Leader

Posted on by
3

Why I love being a TUG leader!

I set myself some objectives for 2019 to give me a big nudge to keep developing myself. I even popped them up on my white board in my office at work to remind me of them and see if others would also make sure I had achieved them. It’s April already and I can honestly say that I am struggling to get going with most of them. Like everyone, life gets in the way, but one of them was about starting to blog so here goes!

Last week I helped to run the fourth UK Northwest Tableau User group (#NWTUG), afterwards I was absolutely buzzing after having such a good day and already thinking about the next one. With this in mind I came away thinking I need to blog about why I enjoy leading a user group so much. I am hoping this would inspire others to get involved in similar forums or even create them. So my first official blog will be about this…and I need to do it now before more time passes and I forget how that day felt!!

It had never really entered my head to create a user group, but when I was approached by Rory Heath from Tableau and Vicky Lockett from Interworks Europe about creating a Tableau user group in the Northwest I thought why not. This was almost two years ago and in December 2017 I ran the first Northwest Tableau user group.

I spent loads of time preparing for the first event; who might present, working out how long it would last, how I would get people to attend etc. I reached out to people I knew from the Tableau world to come along and present, and got loads of help and support from my first official Tableau buddy Simon Beaumont (and now Tableau Zen Master!). Simon had just starting running the UK healthcare user group so his experience with this kind of thing was invaluable.

I have to be honest on the morning of the first user group I was a bag of nerves, despite over 100 people registering to attend I was worried that no one would turn up. I think on the day we had over 90 people attend, all looking on me to make sure the day was a success and that they went away with their objectives met. So standing in front of 90+ tableau and data enthusiasts I had to get over my nerves and crack on. The day was a success with loads of great speakers, all the attendees seemed to be enjoying themselves and loads of people approached me afterwards about getting involved in future ones.

Leading on this kind of event on my own wasn’t easy and I quickly realised that I wasn’t going to be able to keep setting these up alone. Luckily Lorna Eden (a graduate of London’s data school) got in touch with me just before the first user group to say she had just moved back up north and was keen to get involved in the leading the Northwest group with me. Unfortunately she wasn’t around for the first event but I did pick her brains before the day to get ideas about what she thought should be included. Lorna was actually in Australia at the time, but whilst running a live poll using SLIDO to get to know the attendees she joined in from Oz!! I also got chatting to one of the presenters on the day (Colin Wojtowycz aka Datawoj), about whether he wanted to help run future user groups, we seemed to get on well so thought he would be great to get involved alongside me and Lorna.

Since the inaugural user group 18 months ago the three of us have now run three successful (we believe!) user groups, couple of evening events and then a full day event at Manchester Metropolitan University last week. It is so much more fun being part of a little team with Lorna and Colin, and I have really enjoyed getting to know them both. The three of us have very different ‘data jobs’ and I think this helps us to understand what different people may want from these types of gatherings. We have got together a few times between the users groups to talk about future user groups and also more recently we attended an event in Manchester where myself and Lorna presented about Tableau whilst others talked about PowerBI and QLIK. It was nice to attend this without having to do the organising, and despite hearing how good the other products are, Tableau is still the best in our eyes…!

I also help to run the UK Healthcare User Group too now! When Simon Beaumont asked if I would help him run the UK Healthcare TUG too, I couldn’t resist. I had attended a few of the users groups and always really enjoyed going to them. The fact that it also in healthcare I felt that this would be great to help meet other fellow healthcare analysts and leaders, and share ideas that would specifically support my work as NHS leader.

Ok so I have talked about my user group journey but why do I like doing these so much?!

It may be hard to believe if you have seen me present or if you have worked with me, but I can be shy and my shyness in my youth was crippling. I have always however tried to push myself out of this innate shyness and challenge myself. When I was 18 I travelled alone to Australia for my gap year and then had to force myself talk to people I didn’t know, but if I am being really honest with myself and think back (way back!) about that time I generally waited for people to make the first move and start chatting to me first.  I have always recognised how beneficial networking for work is but again struggled in large groups to talk to new people and always struggled to find forums to reach out to.

Over the last couple of years I have done a lot of presentations external to work which has really helped to grow my confidence in public speaking. My discovery and experience through using and implementing Tableau have given me something I am now really passionate to speak about to whoever will listen. The more you present the easier it is, but don’t get me wrong I still get nervous. One of the great things about user groups is the opportunity to network with new and different people, sharing ideas and experiences is a great way to develop yourself and your work. I watched the attendees on Monday to see how many people reached out to speak to new people, but noted that generally people end up talking to people they know. This is exactly what my preference is too and we are after all ‘data’ people, and being one of the organisers means that more people approach me to talk. I however tried my best to talk to new people because I know like myself that not everyone is comfortable to do so. On reflection, I will definitely talk to Lorna and Colin about how we can get people talking to each other more. We have done similar things at work so I do have ideas, but I won’t share them just yet. Don’t want to scare future attendees off ha ha.

As I have said presenting about things I am passionate about gives me the confidence to talk, and presenting in these safe environments is a great way to get that experience.

We had about 70 people attending our Northwest group last week, with a few other Tableau user groups leaders also attending from other parts of the country (London/Yorkshire/Midlands) which was great. Another opportunity to share ideas for future events with fellow leaders! We actually had nearly 100 people registered for the event, I was impressed with the turnout despite the attendance rate but actually felt sorry for those who didn’t end up attending as they totally missed out on so much learning and networking opportunities. Hopefully we will see them at the next event!

As I said I came away from Monday loving the user group, the attendees seemed to get loads out of the day. We followed the day with a trip to a local pub and a lot more people joined us than I would have imagined, which again I think is a good sign of a successful day more than the lure of free drinks?! Well maybe…

One of my favourite things about running a user group is bringing people together. It is also great to create a fun environment for these kinds of events, I love a game! Work doesn’t always have to be dull, you can’t underestimate how much better people work if you motivate them in the right way. Happy workers and all that! We had loads of the attendees last week come over and say how much they enjoyed the day, if this isn’t reason enough to set up the next one then what is?!

My 5 top reasons for attending a user group:

  • Ideas gathering to take back and explore
  • Learning new tricks
  • Meeting new people
  • Break away from your usual day to enable reflection…
  • They’re fun!

My 5 top reasons for leading a user group:

  • All of the above plus…
  • Working with new people
  • Helping others by sharing experiences and ideas
  • Bringing people together
  • Ability to motivate people to learn

I am sure there are rules over the length of blogs…but it is my first after all, so I will learn and improve I am sure. I have really enjoyed writing this, it is really good to look back and reflect!

Hope you have enjoyed reading my first blog. Feedback welcome!