05-December

Managing teams, process and change

5
December

First, a bit about me

Full disclaimer before we get started: I’ve not worked at loads of the top agencies, or even any of The Times ‘best 100 companies to work for’…. In fact, I’ve only ever worked for one company since graduating (although it does happen to be the most awarded digital agency in Manchester, which isn’t bad going).

In fact, my first role here at Code Computerlove was actually IT Technician. No offence to any current IT technicians – they work hard and do more behind the scenes than people even realise  –but I personally like to try and forget the days of asking people to turn their computers on and off again…

But my past experience has actually come in useful really as it’s set me up to easily understand the effort required to build software, which is always a bonus when you’re having to explain to a client what the team is actually doing. I definitely can’t code, but I can spot and fix the odd obvious issue where others might run a mile!

Why am I telling you all this? Well, although I might not have worked in lots of different places, working at one agency for a long time have given me a unique opportunity to play an active role in the evolution of working process over an extended period of time.

What I’ve learned about teams, processes and change

I’ve worked in a few different teams, and over the years we’ve gone from following a waterfall process, to agile (SCRUM), and most recently to Kanban. We’ve moved from requiring lots of documentation, to none, and most recently just the right amount.

There has been lots to learn, people have come and gone and new ideas and knowledge have been shared along the way. But what have I learned from all of this?

  1. There are always challenges
  2. There are always people
  3. There is always more to learn!

Waterfall

Roughly seven and a half years ago – back when I was still telling people to turn their computers on and off – a waterfall process (PRINCE2) was the framework of choice. So when I moved into a Junior Project Management role a couple of years later, this is the process I had to pick up.

It gave us structure. We had a process, work got delivered – and the clients had a lot of waste paper to go with their shiny new websites.

In these dark days we’d be assigned a developer to do the work; they would have received the brief that day, and the face-to-face briefing was all that was needed to initiate the phase of work. There was no real team work, not as we know it now; for example, if the assigned developer didn’t complete the work for whatever reason, someone else would be assigned to complete it.

It sounds quite bleak and I could easily point out the issues now that we know better, but if I’m really honest, I personally didn’t mind it at the time. We completed work, clients were happy. That’s what you want, right?

It was only as we started evolving and adapting how we work that I could see that the waterfall process wasn’t great for some of the people at the end of the line. My eyes were opened, and as my understanding and knowledge increased throughout this period of change, I could see we didn’t have any real collaboration as all teams were working in silos.

SCRUM

Then, It was like we woke up one day and said we’re going to do the opposite of EVERYTHING we’d normally do!

Chaos ensued, naturally, but after a few ground rules and some great leadership, we were working in our first real SCRUM teams, delivering work together. I also became a fully-fledged Project Manager along the way and then the de facto Scrum Master too!

We built whiteboards, painted walls in blackboard paint, and broke tasks down into smaller easily deliverable chunks. We had retrospectives and daily scrums, where work was shared between members of the team. We had cross-discipline teams, and tried to keep the feedback loop as short as possible. We played with different ways of working: some worked, and others failed.

But did we actually get better at delivering work?! If you were to look purely at the numbers, I imagine it would indicate that we were no better off than before. But if you were to speak to a member of the team in those early days, without a doubt they would have said that it was the best change that could have happened. I wouldn’t be able to put my hand on my heart and say that I/we didn’t get lazy at times, or that we never missed or failed to deliver a sprint, but I can say we had a lot of fun. I think that’s pretty important too.

Moving to SCRUM was good for other reasons too, I think it helped move us more easily into a more agile way of working. There was a focus on delivery (sprint) milestones; there was a planning structure that most of us were used to working in; and it also allowed us to bring our clients closer to the work being done as they were more involved in the process themselves.

Kanban

So fast forward a few years and Code entered a new phase – all change again.

One of the big focuses for this new phase of change has been quality and efficiency. Although I could easily argue we were already delivering both efficiency and quality, I do appreciate the need for consistency too – and now, through using Kanban, we’re getting better at achieving that.

The main distinguishing feature in a Kanban team is also its whiteboard, which should be instantly recognisable along with post it notes, to any project manager au fait with agile frameworks. In the drive for consistency, we also took the opportunity to start using User Stories and Story Point Estimation, and ensure each team had its own Lead Developer to keep a focus on development quality and ensure the process was strictly followed to keep the team efficient.

It’s not been everyone’s cup of tea, and there have been a lot of ups and downs during implementation. Right now, we are definitely on the up: the main changes are in place, and people are more comfortable with the change. However, there is always plenty of room for improvement!

I don’t say that because everything is terrible, but going through a big change, where everyone is on a learning curve, the control shifts – and whilst all this is happening, you still have clients you need to keep happy.

Conclusion

I guess what I’m trying to convey with the potted history above is that a process and framework will only get you so far; it’s persistence, patience, and a willingness to work with people during change that will get you the rest of the way.

I also truly believe that no one really wants to do a bad job. As long as people communicate, are willing to learn, and continue to do the best that they can, the team will get you through anything. If you’re struggling and there are issues, absolutely everything is important. Make a change, and make it fast, but ultimately pick what works for you.

Learn and adapt, adopt or improve. Through this you will find out what works best for your team, and you’ll know it when it happens. You’ll inevitably fail at times along the way, but you’ll win in the end.