What are you currently working on?
I work on a huge re-platforming project for a large corporation, encompassing eCommerce, apps, marketing, customer services, chatbots, IoT… everything!
That sounds like a massive task, what's your role?
I’m a front-end engineer, specifically as part of the shopping basket feature team.
How big is the product team? Are there multiple teams working on the same product?
Well, if you’d asked me 18 months ago, I would have said ‘around thirty’, of which 7 were full time front-end developers. Over the last year we’ve been on a pretty large recruitment drive, and now as far as the whole platform, we’re probably around 200 strong, probably a 60/40 split of permanent staff/contractors. That’s split into two channel trains for front and back end services, with UX & testers on top. Sometimes I walk around our office and I genuinely couldn’t tell you who someone is, or what they do!
What’s the makeup of your team?
My basket team is made up of a TPO, Scrum Master, a senior front-end dev, two juniors and then four mid-weight devs. Most teams follow a similar make up, although most have a standard PO, rather than a TPO. Also depending on the function of the team, some will have testers embedded into the team.
What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?
We operate in the SAFe methodology, so we work in larger programme increments (PIs) of 5-6 sprints. As part of PI planning, which is a process that takes a few days, we’ll map out the features that we can take in as a team over the following sprints, working out dependencies on other teams and T-shirt sizing features & stories etc. So we tend to have a good idea going into each PI what sort of work we’re going to be taken in. Then it’s up to us as a Scrum team to refine those features into stories, and then plan our work accordingly. So for new features, it can take 10 weeks to get something into production, but obviously if it’s a big company proposition or has some sort of legal connotations, then we’ll bump it up the queue.
Bug-wise, we can get stuff fixed and in front of a customer on the same day, we’re fairly flexible on that front.
Being a big project, does it come with a lot of paperwork/bureaucracy when trying to release updates or fix bugs?
There can be a bit, but it really depends on the severity. If it’s a P1 issue, then sometimes it can involve incident reports, but for the most part, a ticket is raised in VSTS/Azure, we work on it, and then it gets deployed and re-tested through various different environments.
In our team, we’re quite fortunate that the basket is its own application, so we’re sort of de-coupled from the rest of the programme, so we’re able to manage our own releases. Other teams are currently still in a larger release cycle, so getting code out in front of people can take a little bit longer.
Tell me about your process for planning work in, do you use sprints? Does it work well for your team?
We work in two-week sprints, and it works great. Recently we’ve had a lot of work going on, so we’ve been going back to a Kanban style of working, and honestly if I carried that on I would have a nervous breakdown. We’re fairly mature on our agile transformation, so we’re very good at the refinement, planning and retrospective processes. As a team it’s good to just have some down-time and reflect on what you’ve released over the last couple of weeks, demo it to stakeholders etc. Kanban is just relentless, but it was a necessary evil at the time. We’re just getting back into proper agile now, so everyone knows where they are again!
I would say that one area that we do struggle is with vertical dependencies - i.e. when a back end team is working on an API in the same sprint that you need to build the front end, but these issues are thankfully few and far between, but they can put an awful lot of pressure on both teams, particularly when it’s a legal requirement with a very fixed end date!
Do you plan testing upfront or do developers only come to you once the dev work is done? And (similarly) does the team take the testing work into consideration when planning what to bring in?
It really depends on the team, as I said, some teams have one or two testers within the team, so they’ll bake that into their story sizing. In the basket team, we self test everything, and it’s a big part of what we do. We’ve got a pretty robust suite of unit tests, and we’ve got a few automated e2e journeys in place as well. Screenshot testing is the next thing to be built, and that’ll also save us a lot of time as things get better on that front.
What’s the biggest annoyances you’ve had?
I’ll be honest, I’ve got a few! Part of being a massive corporation is that we’ve got a lot of antiquated tech stacks on the go, so our API responses aren’t always the most consistent. So you can put a lot of work into building a new feature, only for the API to fail, or just not be structured in the way you were expecting, which is fairly annoying. As an example, recently I was working on something in the basket, and when you’ve only got one item in your basket, items are sent over as an object. If you have more than one, items are sent over as an array of objects, which completely changed how the thing I was working on functioned!
Similarly, depending on what you’re working on, pull requests & releases can take a long time to get through to prod, as we’ve still got a few bottlenecks around people who can approve certain things. We’re aiming to make the process much faster, and have a specific number of deployments we want to do per day, but we’ve got a fair amount of work to do before we can get anywhere near that number.
Which (if any) tools do you help to keep track of work?
We use VSTS/Azure for absolutely everything. Epics, stories, bugs, features, pull requests, testing, CICD… I normally try to avoid Microsoft software like the plague, but I have to say that VSTS/Azure is really quite excellent.
Is there anything you (yourself or the team in general) do that works really well and/or would recommend to other teams?
Personally, I would just avoid Kanban like the plague. We’ve taken our agile transformation really seriously as a programme and now that we’re really up to speed (we’ve been at it for ~3 years) and everyone’s comfortable with it, it’s fantastic. I’ve become quite the evangelist for it.
Also, personally I have worked in a lot of different scrum teams within the programme, and it’s been fantastic for me to get involved in so many different things. I’ve only really been a JS engineer for 18 months and it’s been quite a learning curve from a more UI/UX background, so it’s been really good to see how different people work in different areas. So my advice would be, if you’re in a similar setup, don’t just sit in one team because you understand the basket, move about, learn about the checkout, learn about the product page… you’ll work with different people and you won’t stagnate on one team.