HOW TO BECOME A DELIVERY MANAGER.

(Adventures of A Delivery Manager W/E 24/1/20).

I decided to try and create a bit of value by writing about something that I’ve been asked quite a lot about in the last few weeks.

How To Become A Delivery Manager.

In this article, I’ll share some commonalities I have identified by speaking with other Delivery Managers, some useful tips for people thinking about embarking on this path and finally the essence of my own personal journey and relevant pointers that I think might be useful.

The Path Itself.

The first thing that seems relevant to share about this pathway, is that there isn’t one.

By that I mean that having spoken to lots of Delivery Managers, Scrum Masters and Agile Practitioners generally, there really doesn’t appear to be a particular set pathway to becoming a Delivery Manager. Almost everyone I have spoken to both here at HackIT and in the wider Agile community has their own story about how they landed their first role.

The journeys and stories vary enormously. Some made a conscious decision to become a Delivery Manager and actively pursued the role. Others have become Delivery Managers in a more organic fashion and some practically by accident! But even the most active and determined folk largely describe a fairly unique path into the role.

But that stands to reason. 

Agile Project Management by its very definition celebrates and thrives in the world of ambiguity. In fact, the Scrum Guide itself defines Scrum (a very popular framework used by Delivery Managers) as; “A framework within which people can address complex adaptive problems, while productively and creatively delivering products”.

Given that Agile at its very nature is complex and adaptive and the Delivery Manager is the person that serves that process and the structures beneath it, actually, of course there isn’t a ‘standard’ way to start in this career. Maybe that in itself is a bit of a natural filter, but even if it’s not, it might explain in part why most Delivery Managers are quite flexible and adaptable folk.

Who Can Be A Delivery Manager.

The second commonality that seems to be that Delivery Managers are a phenomenally diverse group of people. They are represented by pretty much every demographic and come from all manner of backgrounds and there is certainly NOT a prerequisite that they have a digital or ICT background. 

I have met excellent Delivery Managers with backgrounds in public service and private enterprise alike and with career histories including dispute resolution, art and retail. Many (like myself) have had a brief encounter or exposure to excellent Agile Project Delivery and/or enjoyed the energy and pace brought about by a well run Agile Project and wanted to know more.

What I’m trying to say here is that no matter who you are, where you are from, what your career background has been to date… if you want to become a Delivery Manager and you have the skills (or are prepared to learn them), then you can. 

Getting To Know Agile.

Start with the basics.

The Scrum Guide and The Agile Manifesto are an excellent start. There’s also a huge amount of good books on Amazon – the star ratings and reviews are generally pretty accurate. 

Mostly I looked for fairly light and straight forward books – I particularly liked “Brilliant Agile Project Management” by Rob Cole & Ed Scotcher.

It’s good to know what’s behind Agile.

On the face of it, Agile Project Management and the role of Delivery Manager look simple, but it’s worth remembering that what is simple is not necessarily easy. A good Delivery Manager, like any good professional, might well make their job look easy – but it’s not necessarily the case that it is.

By getting to know Agile, its frameworks and the roles within it, you can get a much better feel for where you fit in and what you might need to do to upskill yourself so that you can more accurately form your strategy for landing the job that you’d like.

Start Talking To People.

Delivery Managers are quite often ‘people’ people. It’s also common that they enjoy their jobs and that they also like to talk about their jobs too, so you can feel pretty confident in making contact with a Delivery Manager (even one that you don’t know), and getting a cheery reply.

If you go a step further and make contact with a few Delivery Managers, you’ll almost certainly find one that is willing to talk in some detail about what they do and give you plenty of detail about the role (and most likely how they got their job).

What’s also likely (if you ask them to), is that they’ll introduce you to other Delivery Managers and Agile Practitioners and before you know it, you can fairly easily find yourself in and around a community of Agile Practitioners. 

There are also endless meetups, forums and groups where you can meet people and get chatting, with each of the conversations possibly holding a golden nugget of information that might help you take things to the next stage. 

Chatting to lots of Delivery Managers is also really good for learning about the harder and tougher aspects of the job that it’s also important to get to know. Agile celebrates failure, but that doesn’t make it any easier when it comes along and it’s good to get to know the gritty elements of the job that aren’t a fluorescent rainbow of post-its in a laughter-filled workshop.

Start Practicing Right Now.

One thing that I always recommend to people is to just BE a Delivery Manager right now.

There’s always a way.

What can you do, in your current professional (or even personal) life right now to start BEING a Delivery Manager?

Can you introduce a regular review (retrospective) to a team or situation that you are working in or on?

Can you start doing a daily stand up meeting to inject some pace into something that has been dragging on for a while?

Can you trial a ‘lean coffee’ or ‘unconference’ approach to deciding what to talk about first in a team meeting or even a family holiday discussion?

There’s always a way to practice… (we’re called Agile ‘Practitioners’ afterall!)

The more you can find a way to BE a Delivery Manager, the easier it will be for you to integrate your experiences into opportunities that show up. As those opportunities show up more often, the experiences begin to mount up. Before you know it, you’ll have a load of applicable examples to give at interviews or talk about when you are networking and meeting people.

It really doesn’t matter about the scale of the use, or how and when you have used the techniques (Agile Practitioners and interviewers are usually pretty good at making the ‘translation’ into how such things might be applied in relevant and current projects).

In my case, I captured my uses as often as I could and posted them (with permission from anyone involved) on LinkedIn, so that anyone who might have looked at my profile ahead of an interview or meeting me could see that I was ‘walking my talk’.

It’s relatively common to hear Delivery Managers chat about the role as a ‘being’ way of life rather than a ‘doing’ way of life. 

I declared myself a Delivery Manager/Scrum Master long before I was officially awarded the title by an employer.

To Qualify Or Not To Qualify, That Is The Question.

There are lots of opportunities to ‘qualify’ in Agile. The most commonly recognised certification in the world of Delivery Managers is called “Certified Scrum Master”. That said as a certification, it’s not a definite requirement – lots of places hire Delivery Managers and Scrum Masters without it. (I didn’t have this certification when I was hired and took the course whilst in my probationary period).

As a course, Certified Scrum Master is more of an overview of the Scrum Framework. It seems to be designed to impart the basics of Scrum upon the participants in a way that they can understand and introduce to their workplace. It’s a good course – I enjoyed it a lot and it certainly helped me to identify what is a part of the Scrum framework and what is other stuff has been introduced locally in my workplace.

However, it doesn’t cover the softer skills, the emotional intelligence skills and the nuances of navigating human beings that are pretty critical part of the Delivery Manager role. 

Once you’re in an interview, it’s much more about the ‘how’ and the ‘why’ aspects that are more likely to be of interest to the interviewer(s) than the ‘what’.

That said, increasingly (especially larger organisations which perhaps have HR or Admin teams who may want to add early filtration), Certified Scrum Master qualification may be sought as a form of entry criteria, so it’s not an entirely bad idea to get it. But if you don’t have a few hundred quid going spare when you are job hunting, it doesn’t need to stop you. 

If you don’t have a certification, look out for the employers who are agile through and through or write a compelling cover letter and get that to the actual person hiring (who may be more likely to be looking for more nuanced and transferable skills over certification). Of course, you’ll need to be able to effectively demonstrate your transferable skills in a way that is meaningful for the role that you are applying for.

My Personal Pathway To Becoming A Delivery Manager.

I’ve decided to de-personalise the journey, mostly because I think that the people, companies and opportunities are pretty interchangeable and it’s easier to translate my journey into your own situation if the content and context are neutral.

Like many – I was ‘exposed’ to Agile Project Management as a bit of a side hustle project that happened to cross my regular job as a Team Manager at the time. The nature of the project interested me and so I was keen to take part and lend my voice and experience to the subject matter at hand, so I joined the group.

I’ll skip over the part about how I was utterly sold on Agile, because if you’re looking to become a Delivery Manager, I’d say there’s a fair to middling chance that you had your very own experience that has compelled you to adopt the Agile life too!

The important part is that I was very clear that I wanted a piece of it.

I didn’t actually know at that point that what I wanted to be was a Delivery Manager, but I decided to move forwards anyway and I did that by starting to ask questions. 

My first was to both the Service Designer and the Delivery Manager of the agency who had been hired to deliver the project. It was simple and open…

 “How do I get to work for you?” 

I largely expected a bit of a fob off, but I was delighted when I received a name and an email address to contact!

I learned quickly that persistence is a definite requirement of this journey. (It’s also a pretty useful skill to have on the job too). I’m not sure if it’s a herd thinning tactic used by potential employers, but the pattern of a flurry of activity and conversation followed by a lull where I chased and followed up happened on more than one occasion.

This particular leg of the journey culminated in a skype conversation with the Head Delivery Manager and everything went quiet. Three weeks later I received a short email telling me that I was a nice person but I wasn’t experienced enough for the job. 

I decided to push for some more detailed feedback.

I’m glad I did and the Lead Delivery Manager more than rose to the occasion. In fact, they agreed to meet me for coffee after work and spent about an hour with me offering fantastic tips, advice and direction. It was also the moment that it became apparent to me that Agile Project Management was actually a ‘thing’ and that it was a whole world that could be tapped in to and explored. 

Until that point, I had thought that it was the culture, behaviours and methodology employed by that particular agency. When they started sharing with other companies that I might want to take an interest in, materials that I might want to explore and people I might like to meet, the penny dropped… Far from a single door closing, this was an entire city’s worth of doors opening.

From here, I expanded my activity in line with the possibilities that had just opened up.

I immediately contacted the names offered to me (and name dropped my referrer with their permission). I also started researching the companies and materials that they had recommended too. They were all 24 Carat nuggets of information gold and acted like the stepping stones to the knowledge and opportunities that was interested in.

I began to see that there were basic patterns and elements that were simultaneously growing me as an individual, expanding my knowledge as a professional and moving me forwards on my pathway toward a career as a Delivery Management.

  • People
  • Knowledge
  • Practice
  • Networking

People.

Once I started getting into my groove, I started to expand my interaction with experienced Delivery Managers and Scrum Masters. This was always my favourite part as I got to meet so many new and cool people and enjoyed every single exchange.

I took two approaches to interacting with people.

Cold leads and warm leads.

Before I knew quite a few people or had lots of contacts, I had to start somewhere. I personally chose LinkedIn for approaching ‘cold leads’.

I searched for Delivery Managers and Scrum Masters and sent a personal message to pretty much every single one that the search function returned. I explained that I was a newbie looking to become a Delivery Manager and offered to buy them coffee or lunch in exchange for them sharing their story with me and any tips that they might have.

Out of the two or three hundred messages I sent, about 20% (40-50) replied to me in some form or another (including a couple of confused couriers who pointed out they delivered mostly parcels).

Of those who replied to me, about 20% of those actually agreed to meet me and I set myself a ‘training budget’ so that I both could honour my offer to buy them all coffee and lunch and also think carefully who I wanted to meet the most (because that budget wasn’t unlimited!)

In order to make the most of these meetings, I prepared a set of questions which I iterated each time:

  • How did you get into Agile/become a Delivery Manager/Scrum Master?
  • What do you really like about it?
  • What don’t you really like about it? What’s really hard?
  • Do you think it would be a good idea for me to put in a cheeky application yet? (This was an important question for me to judge when to begin applying and to be taken at least semi-seriously).
  • What resources/books/courses would you recommend to me?
  • Specific Question I want to know… i.e. how does your team get put together? (This question would often be to address a new knowledge gap that had opened in a previous meeting).
  • Do you belong to any groups or forums and do you attend any events?
  • What’s the best way to get into the business?
  • What sort of things do you think a newbie needs to focus on?
  • What kind of things do you think it would be good to know for interviews et
  • Could I shadow you sometime?
  • Is there anyone who you could introduce ment to who could help me?
  • If you could offer me three tips on how to become a Scrum Master/Delivery Manager what would they be?
  • Can I mention to others that we met? Can I take a selfie for my LinkedIn profile?
  • What can I do to support you or reciprocate your generosity today?
  • Do you want me to keep in touch and let you know how I get on?

These meetings/interviews created the ongoing foundation to my journey to being a Delivery Manager.

After each meeting I would review the information that had been imparted upon me and then think on how I should act on it…

Knowledge… What book/blog(s) would I read? In what order? And when?

Warm Leads… The people who I had been referred to or introduced to following a cold lead meeting. Who should I contact/visit first? Why? Who might hold the next key to unlock something?

Practice… Of the tips offered to me, which ones could I implement right now? How could they serve other people? How could they be used as examples of Delivery in the future?

Networking… Which events were worth attending? What might I learn? Who might I meet there?

Iterate & repeat… Iterate & repeat… Iterate & repeat.

I followed this cycle for a few months, paying particular attention to the answer about whether they thought it was worth me making an application for a job. 

Once that particular answer was yes relatively consistently, I began applying to companies that were advertising (and sending my covering letter to companies that weren’t). 

I also asked (usually via email) for feedback from anyone prepared to offer it, about the quality of my CV, application and covering letter. I sought this both from the people and companies offering jobs and also from the people who had said that they would be interested in following my progress.

A further crude statistic was that of applications and contacts I made, about 10% responded, each enabling me to iterate and improve further.

If you’ve ever explored sales, you’ll know that often, sealing the deal is ultimately a numbers game. It was very much the same with this process. 

In my case, the numbers looked something like this:

  • 200 personal messages on LinkedIn
  • 20 1:1 personal learning meetings
  • 10 meetups & events
  • 10 books and blogs
  • 100 applications
  • 10 iterations of my CV& covering letter 

Being it was an iterative process, it was also a cumulative process. So by the time I reached my second interview:

  • I actually recognised one of the people on the interview panel, having met them and spoken with them at length over coffee.
  • I had heard, iterated and practiced responding to almost all of the questions that came up.
  • I knew exactly the types of behaviours and mindset qualities that were equal to or more desirable than qualifications and experience.
  • I was able to talk about Agile Project Management really easily and cite lots of materials and sources that I had consumed recently to show I was current and relevant.
  • I was able to give tangible examples of Agile methods and activities I had tested, implemented and iterated in my existing job and personal life. 
  • I was able to articulate why I thought I was a better choice than candidates who might have more experience than me.


All of this meant that I could demonstrate that I was already a Delivery Manager ahead of having the job title to reflect it.

I was offered a position at that second interview.

Take Your Time

All in all the above journey from the moment that I asked “How do I get to work for you?” took just over a year of pretty consistent, relentless and active effort.

That might seem like a long time, but actually, the time passed super quickly from the moment that I made the definite conscious intention and first acted on it, through to the point of being offered paid employment as a Delivery Manager.

The weeks and months flew by because they were so action packed. There really wasn’t a dull moment. Every week was full with a plethora of tasks and engagements and the odd one that wasn’t, was mostly spent getting some much needed rest and relaxation.

Follow The Advice Of Working Delivery Managers

They want you to win and they want you to join the community.

Lots of them are current, well read and well connected and if you ask good questions, they can give you some great answers.

Chatting with working Delivery Managers was absolutely the most valuable activity of the process.

In Summary

Albeit a long and winding trail, I really enjoyed it. 

I also haven’t really stopped all of the activity that I embarked upon.

  • I still meet Delivery Managers and ask them lots of questions
  • I still read materials
  • I still learn, try and iterate new techniques
  • I still read stuff (books, blogs, posts) all of the time on Agile
  • I still go to events in the evenings and at the weekends to learn and explore more.

This continues to feed the narrative that we tend to ‘be’ Delivery Managers as opposed to ‘do’ Delivery Management.

As discussed earlier in this article, I doubt very much that there is an exact or specifically defined way in which to secure paid employment as a Delivery Manager. But I think there are a lot of themes that could be explored, iterated and formed in to a not too dissimilar journey to the one I have outlined in this piece. Beyond the ‘journey’ however, almost anyone can ‘be’ a Delivery Manager wherever they are right now and that is the true golden ticket.

Of course, should you choose to ‘be’ a Delivery Manager regardless of your official job title and remuneration package, there’s certainly a reasonable chance that material side of the role might follow in the not especially distant future. 

How to become a Delivery Manager? 

Become a Delivery Manager.

ADVENTURES OF A DELIVERY MANAGER (Alpha) – New Year 2020

Confessions, Weaknesses & Resolutions.

New year, new me… I’m going to get better at documenting my projects this year.

It seems that New Year’s resolutions are almost passé these days. Everyone I’ve asked since coming back to work either isn’t doing one or refuses to do one because it’s probable that they won’t keep it for the whole year anyway. 

In some ways I get it… in some ways I don’t. 

It’s fair because it seems daft to embark on a journey that we have no confidence in completing at the point of setting out. On the other, it seems defeatist to deny ourselves an opportunity to set out on a path of self-improvement, as there must be at least a part of us that wants to improve to have entertained the thought in the first place.

That said, there is a trend that I have seen emerging, which is about setting intentions around improvement – some professional, some personal.

These intentions have been kinder (to self and others) and also less extreme, less definite and much more open to the realities of how life and work tend to flow. One example was the decision by one of my colleagues to simply eat meat less often.

No massive declaration.

No ego-led grandiose commitment.

No self-created pressure to deliver on an almost impossible overnight habit change.

This reminds me quite a lot about both Agile and my journey via “Adventures of a Delivery Manager”.

More conventional forms of Project Management have often jarred me through their rigidness and absolute declarations of the right way and the wrong way of doing things. As have static programmes of learning where there is the right way and the wrong way to learn.

If I look back on my journey over the past 18 weeks (yes, EIGHTEEN weeks), it has taken turns and twists that I could never have seen coming and I have learned my craft (so far), often in quite a topsy turvey nature – largely based on the needs at the time.

It’s also the challenges that have grown me the most. The things that, (had I meticulously planned my adventures), I would have written out of the plan and hoped dearly for them not to appear. But, having undertaken the journey with a set of themes and intentions as opposed to a rigid pathway, I have been able to make these challenges my friends and embraced them for the rich learning experiences that they have been.

So what about my ‘resolution’ for 2020?

I really like the idea of setting intentions. Albeit I don’t think we should wait for new years or even decades to make commitments for self improvement (although I do think the G+ community would probably grow tired quite quickly of ‘new day new me’ posts)… The break between Christmas and New Year does allow for a period of reflection. The down time also allows me to return refreshed and with my brain waves being in a more receptive state.

My general intention and principle has always been that I want to be a brilliant Delivery Manager, but it always serves to be specific and I was shown a weakness of mine early upon returning to work – so this seems like a good place to create a new, specific intention.

Upon returning to HackIT, we had a session where we talked about the concept of “Minimum Viable Documentation” for our projects.

I was excited for this session, because I had struggled to fully understand how and where we consistently document our projects and had experienced some challenges when inheriting a project from a departed colleague to understand properly what had happened before me. 


During the session however, as my colleagues were sharing their various methods for project documentation – it dawned on me that I really wasn’t doing such a good job on my own projects. Cate, our Head of Delivery, delicately suggested that there was a spectrum of strong to weak project documentation activity across the team and I knew that I was on the weak end of that spectrum. I was disappointed with myself, because I knew that if someone were to take over my project, they would be faced with largely the same problem that I had experienced.

Acknowledging weakness can be hard, especially when that weakness affects (or potentially affects) others. But equally, by acknowledging weakness it can be turned into a strength.

This is one of the things that I especially like about the safe space environment here at Hackney Council. Following that meeting, I felt both safe and empowered to approach Cate and ‘confess’ my shortcomings around product documentation.

Doing that wasn’t, however, an indulgence guilt admission. It was in fact an opportunity. It stands to reason that if Cate presented the concept of such a spectrum, then regardless of whether I was or wasn’t at the lower or bottom end of it, Cate would know who was at the top end of it. That was the purpose of the conversation. By openly sharing my weakness, I was able to seek help from a place of strength and Cate recommended that I speak with my fellow Delivery Manager Soraya, who (I can safely say), IS really rather good with project documentation. And who was also very willing to help!

The conversations, both with Cate and Soraya, enabled me to see that this is a need and a weakness that will require consistent work, to form a new habit. Documentation has always been hard for me – it’s one of the reasons that I was attracted to Agile in the first place, but that’s no excuse to pretend it isn’t important. However, they have kindly set me up on a path of self improvement in this area and I feel confident that the shortcoming is surmountable and that I am supported in my efforts to turn it around.

So my ‘intention’ for 2020, is to consistently put effort into project documentation, to get regular feedback and help and to get better at it across the year.

Here’s to 2020!

Ian

Joining Up Staff Data: Week Note w/e 06/12/19 – Alpha (Experiment).

It’s good to be back!

A week on “hiatus” with Lisa (our Product Owner) being away for Thanks Giving and the rest of the team tinkering away on some ‘side hustle’ projects. But now we’re back – it felt like a bizarrely long time, which is an indication of how we’ve become accustomed to working together.

This week we reviewed the feedback that we received at our show and tell and took some time out to think on what iterative stretch goals we might aim for in this project, as we had already delivered an MVP for Joining Up Staff Data using Qlick.

Firstly we had a bit of a sesh to simply reacquaint ourselves with where we reached so far in sprints one and two and considered what we might want to try to achieve in sprint 3. We’ve taken an ambitious stance, but we’re open to getting as far as we get.

We took all of the suggestions made at the Show and Tell, along with those that had surfaced during the user research for the higher level Digital Support Services programme of works.

We created a neat Venn Diagram that helped guide us around what to prioritise which brought together:

  • What the organisation wants
  • What we have the skills to do
  • What we have the time to do
  • Value to the Organisation

Using this as the foundation to our decision making, we decided to create one inward (IT) insight and one outward (Organisational) insight.

On this basis, we will be attempting to create a user friendly reporting tool that could provide us with new insights about headcount in the Organisation and also some insights on Microsoft Licensing requirements (as this will solve a whole problem in helping to understand how many Microsoft Licences we can reduce our count by).

The team have largely thrown themselves in to the back end of Qlick at this point to start the process of pulling that data together and creating the raw numbers, before we tackle the front end of the pilot to see how we can make it more intuitive.

Beyond this, thinking about how we might test it and how we might give Qlick a bit of a celebrity makeover so that it’s more of a go-to tool for people looking for organisational data insights – as well as making our recommendations for what happens next when we’ve wrapped up our last sprint.

We’ve got a lot to do – but we’re sure giving it our best shot!

Adventures Of A Delivery Manager – Week Ending 29.11.19

I really should decide whether I write these week commencing or week ending… that said, given that is the critical thing running through my mind at this point on a Friday evening, it suggests I am feeling fairly relaxed and calm this week.

TIDYING UP THE PROJECT

This week, I’ve made good use of some space to tidy up “Adventures Of A Delivery Manager” following my last week note and I feel a lot more settled about it. I have a nice four weekly rhythm in the diary with all of the relevant events now lined up for the coming few months – I guess I’ve properly committed to this for the long term!

I’m also really pleased to have the support of David Durant who is taking up the mantle of being my go-to in place of Nic with regard to this project. We’ve got a session in next Friday to talk about the Sprint Goals for sprint 3. In all honesty, it’ll be more of a review and discussion about what could have been – but regardless, it serves to just get in to that mindset about it.

NETWORKING

This week has been really cool for some organic networking.

Following delivering “Adventures” as a talk at the CrossGov meetup on Monday, I was contacted for a shadowing opportunity from .Gov, so we’re going to put that together shortly.

Then on Thursday we delivered our “Delivering An Excellent Delivery Team” show and tell, where we offered the opportunity for shadowing. I’m delighted that someone reached out there too.

Beyond shadowing, I also met our Hackney 100 student who I am going to work with over the coming months.

All of this really helps me to expand. I really subscribe to the concept of “see one, do one, teach one”, so the opportunity to teach and tell is really beneficial – shadowing is SUCH a win/win activity.

TECH & CHALLENGE

David is teaching me some tech (coding).

I find this REALLY hard.

I’ve always found languages hard, but code is especially hard, because they are words and abbreviations that I understand in a different way, so they feel really hard to convert in to a new way to do new things.

One of the reasons it’s really frustrating for me is that I place a really high value on the art of communication… a single word can make all the difference. Often I wish I could learn multiple languages, but for whatever reason, mastering other languages just doesn’t come naturally to me. Coding is no different… one space or letter in the wrong place can have quite the unintended effect!

That said, there are other skills I have learned in my life that were hard, but worthwhile and so I will pursue this, especially if it helps me to do a better job and serve my colleagues and team mates more effectively.

I do have to do a couple of things however to stay healthy in this space however.

Firstly, I have to always give my teacher and fellow learners warning – that when learning something really hard, I get unintentionally grumpy. No matter how hard I try to hide it or suppress it, it happens anyway – so best to acknowledge it and manage it. Secondly, I have to choose very carefully when I do this kind of training, because it really challenges me and takes me a while to recover from it. This means I need to be sure that I’m not going to come out of the training and in to a critical workshop or detail/concentration based task… I need to decompress first.

TO DO

Next week I need to promote the Barter Wall… it’s not gaining traction and in danger of becoming wallpaper, which would be a shame.

That’s it from me this week!

Joining Up Staff Data: Week Note w/c 18/11/19 – Alpha (Experiment).

This week we started the work to “piggy back” on the work already undertaken by Daro in the Data and Insight Team with regard to joining up staff data. In theory it was going to be quite straight forward. In practice (as is often the case), it was a little less so – but not insurmountable.

We started the week with what we called our “quick & dirty” data analysis. As we got in to the exercise, we discovered that it was going to be somewhat less quick, but a whole load more dirty!

In everyday language, what I mean by this was that the data was more inconsistent and unreliable than we had first anticipated. The goal of the exercise was to think about what new insights we might want to try and glean using Qlick, the existing tool for analysis previously configured by Daro. (Both the insights we could get now and the insights we might be able to get by building on the work already done).

The new challenges and questions that started to pose themselves however, were along the lines of how useful these new insights might be and what we might actually need to do to create something meaningful.

It started to create a bit of a chicken and egg question for us… What comes first… cleaning up the data or creating a mechanism to join data up.

There are pro’s and con’s to each position… joining up data gives a more overall coherent picture of what’s there. But equally, if joining up one poor data source to another poor data source, we are left with a set of doubly poor data that is potentially produces an insight that is twice as unreliable as the first.

Ultimately, we took this as far as we could on our own and decided to pose some questions to our wider audience of stakeholders at our show and tell. We specifically asked what insights might be most useful.

This information is most useful to us, because by understanding this, we can get an idea of the level of accuracy that we might be able to achieve based on the correctness of the data sets that such insights belong to and then make a call on whether we think that by joining them up we might get be able to get data that would answer such questions to a level of reliability that will actually help anyone.

If we can’t do that, then the question is answered for us by default.

Talking of the show and tell, we felt much better about this one.

We worked harder at preparing it, assigning responsibility for articulating a ‘section’ rather than a slide and rehearsing a couple of times to make sure that we were all settled and ready for the review.

Collectively we all felt that it went better than the first and we treated ourselves to a box of Quality Street to celebrate!

In terms of how we are working, I’m pleased that at our retro (where above mentioned Quality Street were devoured), the issues that we collectively discussed were all different to those that we had worked on at our previous retro, which suggests that the iterations that we made around trying to balance work had been a success.

In terms of going forward, we are going to try making ourselves more visible to our regular teams of practice and also we are going to have a look at further flattening the team structure by finding ways to more evenly distribute work between us. This means that some of us may try taking on the generic admin tasks of team members who are peaking on technical aspects of the projects.

We’ve also decided to take a weeks hiatus this coming week, as Lisa headed off to another continent to celebrate Thanksgiving and Ian took out some training time to get Scrum Master Certified and Tim is carrying out a swift piece of discovery on another arm of the Managing People Data suite of works. (Tom I am sure is being kept very busy on the Data and Insight Team in Lisa’s absence!)

We’ll be back next week to explore how we might build on the work undertaken by Qlik so far and to think about how we might make Qlik more widely accessible. We’ll also be thinking about what recommendations we’ll be making at the end of the alpha phase on this project.

As always, thanks for taking an interest in this project and if anyone has questions – feel free to reach out and ask any of the team!