What project do you work on? What is your role?
We're working on the CMS and frontend of a large media company. I'm hired as an application developer which covers the whole stack (frontend, backend, sysops, db, you name it), but mainly work on the frontend side because that's what I'm passionate about.
How big is the product team?
We're 2 scrum teams of ~10 people including a test person and PO. There's a dedicated design team that also works on other products.
What’s the makeup of your team?
~8 devs (some work part-time)
1 tester
1 PO
What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?
Thankfully we have CI so we're not bound to release cycles.
I can choose to go the official route and create a ticket in Jira. If it's small-ish and fits into the next sprint (3 weeks), it's usually planned for the next sprint. During the PBR/grooming we estimate the complexity of the story in unitless points and discuss the contents of the story until we're happy with the "how to demo" points.
Tell me about your process for planning work in, do you use sprints?
Yes, we use SCRUM and work agile. We used to do sprints of 2 weeks but now switched to 3 weeks, because it gives us 2 weeks without a sprint change. A week with a sprint change is usually full of meetings and we're not terribly productive then.
Only a small part of the whole company works with sprints. Often, this makes sense because e.g. there's no MVP for a show - once it's out, it's out. That makes working with other teams a bit difficult sometimes.
Does it work well for your team?
I'd say it's better than what I've experienced in other companies :)
It works reasonably well. We do a retrospective after every sprint and can bring up things that bothered us or that are not going well more or less freely. Some issues are of course baked into the company structure.
Do you plan testing upfront or chat to testers about it once the dev work is done?
The test person participates in the backlog grooming and estimates the complexity of testing a ticket. This is usually not questioned by the team.
Each ticket has to fulfil some formal criteria and must include a list of what defines the story. These points can usually be directly used for testing. If necessary, developers add specific instructions for the testing process or highlight some edge cases or things they're not sure about (e.g. "maybe check if it still works on IE11 on that breakpoint").
And do you take the testing work into consideration when planning what to bring in?
For some larger tickets that change systems fundamentally, we sometimes plan a full day of testing where also non-testers help testing, e.g. to make sure something works and looks right in all our test devices and browsers.
What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?
Our (agile) unit is embedded in a traditional company structure with lots of hierarchies and bosses that need to prove themselves. This and the lack of a clear strategy makes it difficult to plan ahead. I have no idea what I'll be working on in half a year.
We only have a small testing budget, only 1 test person per team. That often leads to bottlenecks and insufficient attention to details, which then leads to more bugs.
But the biggest problem in my opinion is the lack of a sense of responsibility. If there's an urgent problem with a system, often nobody feels like it's their problem. Then the first dev that feels stressed enough about the problem tries to solve it; without knowing a lot about the system. This leads to more delays and sometimes just restarting servers, creating further issues.
Which (if any) tools do you help to keep track of work?
Definitely JIRA where we manage all our tickets/stories and plan our sprints. We also have a physical whiteboard that contains the same information as the digital board, but it's easier to see who's working on what when passing by. It's also easier to move between the lanes (In progress, testing, etc.) during the daily stand-up and to visualise dependencies between stories.
Otherwise we use github for pull-requests and code feedback.
Slack is used for everything else in-between, but outside of our unit of ~50 people Microsoft 365 is king, so there are plans to move to Microsoft Teams soon.