Work

I am a principal at Develogical, a software development consultancy based in London, UK. We specialise in agile software development practices, training, education and research.

I also teach at Imperial College and Oxford University, and am involved with the UK agile community.

Contact

robert at chatley dot com

Play

I play the violin and I like cycling.

Recent Articles


Work Experience for Grownups

At some point last year, I had the idea of spending some time with a team that I don’t normally work with, with the aim of gaining ideas and experience. Unfortunately I didn’t get around to putting it into practice, but last week I found I had some free time, and with the help of the good people at 7Digital I was able to do it. I call this Work Experience for Grownups.

7Digital is a smallish but growing company, working in the music industry, with a team of about 20 developers, plus operations, product, sales and business teams making about 50-60 staff in total. The dev team is divided into three sub-teams, focussing either on back or front-end systems, but all work mostly in .NET, and follow agile practices (although practices may vary between teams, depending on what each team feels works best for them). Strangely, 7Digital currently occupy the Shoreditch office space that I worked in about five years ago with Kizoom - so it was a little bit strange being back in the office, but with a different company.

7Digital Office

As you can see in the picture, most of the developers work in pairs. This is a really good thing for an outsider wanting to come and join the team (either temporarily or permanently). A new person can get right into the heart of things and work on something useful, even if they aren’t particularly experienced in the domain, or with the particular technology being used.

It seems more common for companies to take on interns or people doing work experience placements who are relatively inexperienced. One of the differences about doing it as a more seasoned professional is that you are (hopefully) able to contribute something to the team. Although you likely wouldn’t feel comfortable taking on a piece of work on your own (and if you did, then I’d question how useful a learning experience you were having), you can work reasonably effectively as part of a pair, offering a fresh pair of eyes and possibly new insights on problems, as long as your pair can put up with you asking a lot of questions.

I spent the week with the Services team, who work on providing APIs to other teams, and to external customers. We spent a fair bit of time working on tests and features, and also trying to debug various problems with bits of infrastructure. From a technical point of view, this was an immersive approach to learning, and so I didn’t get a full understanding of all, if any, of the individual pieces, but got an idea of how things fit together. Coming out of it, I didn’t feel I’d be confident in starting a new .NET project from the ground up, but coming in to the middle of an existing one, I would at least have an appreciation of the lie of the land.

From a process point of view, I was on firmer ground, and after observing the way the team worked for a few days, felt able to offer a few suggestions, or at least highlight a few things that I’d noticed. Each of the delivery teams uses some form of Kanban board (although each team has designed their board with different columns etc). We talked quite a lot during the week about the flow of features across the board, release processes, what was holding up things from being released. They release approximately once a week, but there isn’t any strict iteration cycle (they had tried that before and decided to abandon it). They are trying to get to a state of continuous flow, releasing every feature when it is finished, perhaps releasing daily or even many times per day, but at the moment they seem quite far from that. We spent some time discussing where they want to be, the challenges, and how they might be able to change their process to get there. One thing that seemed very positive was that everyone seemed to be thinking about ways to evolve the way that the team works, and to improve. One comment that I made in a retrospective, about concentrating on pulling features across the board from the right (into production), rather than pushing them from the backlog on the left to fill up empty slots where the WIP limit had not been reached, was immortalised in a poster by Chris and stuck on the wall. That’ll teach me to be careful what I say

Pull from the right

Thanks to Rob, Hibri, Ben and the team for letting me spend the week with them. It was certainly useful for me, and I hope that it was of some use to them too. Having done this once, it’s something that I’d like to do again, perhaps a couple of times per year, as an ongoing way of learning new things by seeing tools and practices in use at the coal face - quite a different experience from reading about them, or trying them out on small personal projects. I also think that doing your first week with a team, on a project, or in a company, is a skill that we can practise and get better at. Learning how to get up to speed more quickly, or what things a new person most needs to know to start being useful on your team, can only be a good thing. I wasn’t paid for the time I spent with 7Digital, but looked at the week as a pretty cheap form of training. I’d encourage people to try it, and for more teams and companies to think about welcoming people in. Please let me know if you have ideas about this.

Rob pairing Information Radiator