Learning through teaching

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!

Why Agile Project Management could work for you!

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!