What kind of project do you work on?
The e-commerce website for a national retailer.
What is your role?
Front end developer / tech lead
How big is the product team?
I'm not sure of the exact number but probably getting on for about 200 in total (including not just development but all the ops, infrastructure, strategy, etc etc)...
What's the makeup of your team?
Developers, QA, UX, UI, Product Owner, Delivery Lead
What's your process like for going from the idea for a small improvement (not a large task) to it going live in production?
If it involves interface changes, it would normally be at least a conversation between the PO, design and dev. (Bigger changes would be split into smaller pieces via story mapping). Then the PO would write up a ticket with acceptance criteria and the story would get pulled into a sprint when appropriate. The design would normally be worked on as part of the story elaboration before the dev starts, and QA would help to define test criteria. Then dev, code review, QA, then merging to master and deployed next time a release goes out (usually within a couple of days or so - we're not yet doing Continuous Delivery but aiming to get to that later this year).
How much (if any) paperwork/bureaucracy is there involved with releasing a new feature/bug?
The 'paperwork' for us is usually just the info and comments on the Jira ticket, although updating any relevant documentation is also part of our Definition of Done. Then for actually releasing it... I hear that a while before I joined, the deployment process used to be a lot more complicated, but nowadays thankfully it's just a case of raising a service request (which our Delivery Leads handle), recording the request number and pressing a button in Jenkins (after the build succeeded).
Tell me about your process for planning work in, do you use sprints? Does it work well for your team?
Yes, 2 week sprints. It does work well. The only issue is sometimes when things are in flux, 2 weeks is still quite far ahead to be planning in advance. We tend to adapt then as we need to, e.g. recently we pulled in some tickets mid-sprint as that was the earliest they could be ready to work on, and they were the highest priority and time-sensitive.
Do you plan testing upfront or chat to testers about it once the dev work is done? And do you take the testing work into consideration when planning what to bring in?
Yes we do this upfront - our QA engineers are involved in sprint pre-planning and sprint planning, and they are involved in estimating and judging how much to bring into sprint too.
What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?
One of the most difficult things has been for the delivery leads and leadership team planning further ahead, e.g. to judge if we are likely to make deadlines a few months ahead (e.g. for new regulations coming into effect). Sometimes for these reasons we are asked to estimate a large amount of work up-front, which is very difficult and has not proved to be accurate.
Which (if any) tools do you help to keep track of work?
Mostly Jira. (We also use Confluence, Bitbucket, Slack...)
What would you say are the pros/cons of having a larger team?
Pros are the number of features we can work on in parallel. Although we have had difficulty prioritising "cross-cutting" aspects (one example is web performance). They tend to fall between the cracks of the feature teams. So we're planning to create teams focused on those soon, as we continue to grow.
The back-end developers work on separate repositories for each of their services, but they have had some difficulties around standardisation. Our front-end team works on a single repository, but the downside is it's getting very large, which is bad for developer on-boarding and also for performance.
Are there any specific processes/techniques you have in place to keep it going smoothly or is it just the Jira tickets?
There's a lot of ongoing work to improve the test strategy, build pipeline and release process. We're trying hard to automate everything we can and make it as quick and painless as possible to build and deploy. On top of the unit tests, functional tests and quality gate, we're taking extra care over a small set of business-defined, end-to-end 'golden scenarios' which must pass, whereas other bugs not caught by the lower part of the Testing Pyramid could be fixed forward.
To keep the code as high-quality and consistent as we can, every pull request is peer-reviewed. We try to document important things that aren't clear from the code. We also meet up as a whole front-end team quite often (up to once a week) to discuss anything we need to decide on / align on as a group.
Have you had situations where the testers are extremely busy but the developers are not, or the opposite? How do you deal with the balance of work across the team?
Yes, so we try to do what we've learned from our Agile coach and be fluid with our dev/QA roles as needed, to do our best to get as many stories through to 'done' as we can by the end of the sprint. So if QA are particularly busy (e.g. often right at the end of the sprint), we'll do what we can to help them, even if it means pausing other development tickets until the next sprint. Likewise, when the QA engineers are less busy, they might help us more with writing tests etc.
Do you plan your releases at all?
Yes but I haven't really been involved in any release planning yet - I think this is partly because it's mostly handled by our delivery leads and platform team and partly because everything I've been working on so far is still in 'dark launch' so the releases haven't needed any input from me.
If your team has people working on different things how do you go about testing it altogether?
They get tested individually on their feature branches, then anytime something gets merged to master, all the tests get re-run there. We also do a short 'smoke test' on the live site after each deployment.
Also you mentioned Continuous Delivery, what has made you want to start working that way and what do you hope it will help with?
At the moment, our release process still takes up too much time and involves too much manual effort. We're taking the "automate what we can" approach and hoping that this will help make us more efficient.