We have the exact same issue, QA has sign off and we have less QA than devs and a ton of manual tests they must run, add that into “agile” with releases only every two weeks and then the process of putting things in a backlog getting it in front a PM groomed and then added to a sprint. If you throw a hotfix in to the mix that makes things a little more interesting.

How big is your product team? Do you plan testing upfront or chat to QA once the dev work is done? And do you take the QA work into consideration when planning what to bring into a sprint?

We run a couple of product teams, the one I am on is total of 12, 7 are developers.

We recently just switched to story points vs points = days of time. Our new process is to point a ticket to “done” state which would cover everything, dev + QA and anything else needed. We are moving to working on sprints based on velocity, which is something new, but before we used to do sprint planning based on QA captivity, which at one point we did a couple of sprints that had no dev work on, that was very odd, and didn’t help for a while as devs were still working from the backlog- we took on some non QA projects “technical debt” to avoid us being stuck in that cycle.

Have you found it all gets done or do you often rollover to next sprint?

It’s a new process and it’s talking a little adjustment. We're still seeing quite a bit of rollover. After the pointing exercise management level folk decided we should be doing 30 points- first sprint we did 9, we just completed our third sprint and that we did 27. But those 27 were not all stories we committed too, we still had people working from the backlog, and those stories QA haven’t seen on an environment yet.. it’s a pretty odd setup at the moment

To add, our product team is “replatforming” and existing system, we are only doing the API layer and updating UI to talk to new API contract of API is staying - to try and get out the new system ASAP.

Sounds like a plan doing it by the layer like that. What was the difference between the 9 and 27 points? Estimates? Or just far less brought in to begin with?

Do you have stand ups? Any sub teams or all as one?

First sprint there were a lot of dependencies and decisions didn’t get made or took too long. We do daily stand ups, not much if any developer interaction between teams. There are three teams in all, there’s not much dev overlap in terms of product work quite strict boundaries even within the application.

So there are three separate teams working on the same product? That's interesting, has it always been that way or was there a reason for splitting it up?

Sorry, I should of been clearer - In the Technology department there are three tech teams. Two work on the web application (core product) and then we have a Mobile team, primary looking after mobile products and a different web application this team does consume APIs from the core, the mobile team is the most off to the side team. The other two teams contribute and work within a lot of the same repos. Which is changing over time as we move to a more micro service architecture.

It hasn't always been this way, we moved to product teams about 9 months, ago. The mobile and core team has always been separate but we split the core team again, there are some parts of the core application that was split anyway so was quite easy to be done.

We also have a 4th team, called RDD (Research, Design and Development) that sort of do their own thing and help out between teams.

I see, so of the two teams working on the same part of the product, how do you go about making sure you're all going the same direction. For example with the architecture or something do you meet up and agree the direction or does one team decide something without telling the other?

So the architecture is driven by RDD. In terms of teams working on the same part of the product, the overlap isn't that much. For example we have a planning part to our application one of the development team owns this and the CMS part. Then the other team pretty much own the rest.

Nice, so you would say the splitting of the teams was a move that worked well? Were people against it at the time?

When RDD decided architecture the communication between teams happen with RDD rather than team to team communication - but I see an issue when the second team are doing their replatform there will be some communication needed - we've yet to cross that bridge.

What would you say is the most annoying thing you find with the way the team works? And opposite, what does your team do really well that others might not?

I wouldn't say splitting teams went smoothly - the first part of splitting teams was one team did maintenance and the other did new development, that was a little rocky. Devs were not really consulted on the teams they would be in, you sort of had to raise your concerns and they would be taken into consideration.. Then we teams were given a set of "products" (we have one product, but we split that into smaller products) it was a little easier, each team has a PM leading the roadmap, so devs could see the light at the end of the tunnel for example. But even then what team 1 (the calendar team) got the green light to replatform some devs on team 2 got a little grumpy as they wanted (had been told) they would get to work on new tech.

I think we've all been in that position, it is so easy to feel jealousy when other people are working on the more interesting stuff.

Most annoying things I've found with the split is you loose sight of everything go on, but as the product grows understanding all the pieces becomes harder, and not all developers need to know everything

The split in teams and the new "RDD" really made it confusing for a while, it wasn't well communicated on how much say the RDD team had, it was like lots of developers all trying to show their muscle, made for an odd dynamic for a few months.

It's hard to say what our team do really well that others don't as I've not experienced other teams, if you referring to the team I work on within the org it's the same, as we don't hear much of the other teams, even after retros for example.

Ok maybe not comparing to other teams, but is there anything you're really happy with?

It seems to be less chaotic, smaller team gives a bit more focus and you don’t end up in tons of meetings that are not quite relevant.

I’m currently working on Toucan, which is a money management product built around mental health needs. At the moment, we’re testing if the product proposition has legs as a native app.

What is your role?

I’m Head of Design reporting directly to the CEO, which means my key responsibilities are collaborating with key partners and parsing their research into meaningful features and ideas, that then turn those bits into flows, UI components, etc, and testing them with real users. A lot of this work also forms our product roadmap, so I guess that means I do some type of business strategy, but really we’re just trying to be as user-led as possible.

I also do some broad strokes for user testing strategy + research strategy as I have an academic background, and we’re quite a small team so we all wear lots of hats.

How big is the product team?

Currently we’re 3 full-timers, and have a broader network of freelancers, academics, interns, and mentors we pull in. We probably have 4-5 people revolving in and out of the team at any given point depending on what we’re trying to achieve.

What’s the makeup of your team?

We’re slightly different because a) we’re a fintech, and b) we’re working with vulnerable people, which means we have slightly broader requirements than the norm.

The core team is myself (design), Evelina (CTO), and Bailey (CEO). Bailey is a very active and involved CEO in the best way possible, and provides some much needed regulatory guidance, and access to a wider network and research. I imagine as we grow, we’ll hire in specialist regulatory/compliance/legal people to help with this, and we also have scope for a clinical psychologist to help us in a research capacity.

Outside that, the revolving door of people has predominantly included back-end developers and researchers. We’ve also had a freelance product designer dive on when needed.

I should add researchers includes both university academics and user researchers.

What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?

At a previous company, we used ticketing systems to flag anything and then would follow up in our daily/weekly rituals (stand up, retro, sprint planning).

At Toucan, it’s a bit easier to just harass Evelina until she does it but as a product focused on mental health we’ve been pretty regimented on maintaining a similar system to above with Jira + weekly/daily rituals. Better for everyone’s sanity.

In previous workplaces, the way we triaged tasks and assigned them priority was very much out of our hands and came from anxious demand elsewhere in the team (frustratingly, as design is often on the front lines testing with users). At Toucan, we prioritise ideas going into the app based on user need + regulatory need which seems to be working so far.

In previous workplaces, we had a pre-prod environment where we could sandbox ideas relatively quickly which was nice. Things going properly live (even tiny things) sometimes would take forever because of overly cautious departments not trusting in their product teams. At Toucan, being so new, we’re intensely fast-moving and streamlined for small changes.

Tell me about your process for planning work for a sprint? Does it work well for your team?

Currently we’re running Thurs to Thurs. Jury is out on whether it works well for the team, we’re still learning and adapting, and have left room for us to review this process regularly. Personally, it’s working well for me.

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?

I’m typing this out as I sit in a testing session right now. We are structuring our sprints to include regular testing of any of the business/product elements (brand, flows, proposition), and are currently running a live pilot of our MVP. Testing is a critical part of our product proposition, because we need to be able to reassure partners that we’re doing our due diligence with vulnerable people (and it’s just the right thing to do).

We currently have a few branches of testing being developed as well, including a co-creation team. The closest thing I’ve seen to this is probably Monzo, though we have to reframe ours slightly seeing as there’s such a stigma around talking about mental health and money problems. The other branch will include continuous testing, which will take place either 1-2 days weekly/fortnightly, and we’re either hiring for or outsourcing to a trusted agency

What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?

For me in previous roles it’s been 100% about winning trust, and convincing stakeholders not in my everyday work that I can do great things in an autonomous capacity. It’s probably been more of a misalignment of ambitions than me being in terrible companies, or a personal failing.

Outside of that, at a team level, remote is always the biggest grievance. Tech issues when team members dial in, different time zones, meeting room availability, wifi issues… you name it. A product I previously worked on had a remote dev team and would constantly fly over to work with them. Culturally it was such a devastating thing — the remote team felt like they were being kept separate and weren’t welcome in the London offices.

Ultimately it’s mostly interpersonal, human issues that tend to get in the way of making great things, which are things that in a senior capacity I have to be really aware of and manage so everyone’s doing their best work and feels unblocked. Some examples include people not feeling they can speak up or be honest, that they’re not being heard, that they can’t say no, that the expectation is they need to be a bum on a seat 8 hours a day to be seen as productive, etc.

Tech issues just come with the territory lol. I've worked in once place where IT consistently crushed it, and it was all down to one damn good hire we all enjoyed working with. Valuable life lesson – *always* make friends with the infrastructure folks.

Also, as a designer, I need to make sure I don’t write shit tickets and label things properly 😂

Which (if any) tools do you help to keep track of work?

Currently, we’re loving Zeplin, Figma, and Jira. I also personally use Toggl to track my time, and Things 3/a notebook to do task lists, but it’s not a requirement. Just a way for me to understand where the hell the time goes and what I’m doing (working around my intensely bad short-term memory).

You mention Jira but I know that was a recent change from Trello, could you explain why the team chose to move over to Jira?

Jira just has better tools for Evelina to estimate tech. Burndown charts and difficulty estimations make it easier for her to understand her velocity. And I personally like the swim lanes which means we can move design tasks alongside tech tasks in a sprint, and have better visibility of what’s getting done as a team.

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.

Currently a tool for people to analyse customer data extracted from ticketing and survey data, very squarely aimed at people with little time or limited training with data analysis.

What is your role?

Customer Experience/Design lead

How big is the product team?

Tiny, there's 3 of us at the moment and we're without a dev at the moment.

What’s the makeup of your team?

Product owner, Project manager, Designer, Two or three devs (coming soon)

What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?

Not currently relevant as we are aiming at a ground-up redesign and rebuild.

Tell me about your process for planning work in, do you use sprints?

We're working towards a world where sprints are used to plan but at the moment we're in a phase where we are gathering an initial backlog, prototype and design system to give to the dev team.

Does it work well for your team?

Gathering of user stories is certainly a lot easier than trying to create some mega spec doc so the idea of working Agile and in sprints makes a lot of sense. Does it work? TBC!

Do you plan testing upfront or chat to testers about it once the dev work is done?

Sounds more like a QA question. We're in regular touch with our users from a validation point of view. Biggest concern for us right now is ensuring what we're going to build is the right thing.

And do you take the testing work into consideration when planning what to bring in?

As above, we're scheduling with users regularly for feedback.

What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?

People's time, 100%, such a small team with other things to do and an existing product to maintain makes finding enough time together very challenging indeed.

Which (if any) tools do you help to keep track of work?

Aha! but also at this stage we're using Teams (for daily stand-up) and MS Planner (for to-do lists).

Given you’ve not started development yet, how will you know when to start it? Will it just be when you find a developer, or at a specific time, or is there a goal in mind first?

There are a couple of triggers. We have deadlines we are committed to due to funding obligations and stakeholder expectations. Before development begins though, we are creating an initial backlog of user stories with definitions of done (we will involve a developer during this process) and a comprehensive 'clickable' prototype and accompanying design system.

Also you mentioned how everyone is so busy and that you need to ensure you're going to build the right thing, how do you go about figuring out what to focus on?

This project is based of some research already done which has helped enormously but we are in regular contact with users to ensure we're building something that they believe will be valuable. Additionally we have certain obligations due to being a funded project. On a more practical level we will have a user story mapping session at some point very soon to ensure we've got everything covered. We've also got some Top Tasks research underway.

The short answer to this is almost constant validation with the organisation and its user-base.

I work on the mobile app portion of an online radio network and its sister-networks. Networks here just meaning a different brand with a different content offering, but the same underlying system.

It's probably worth pointing out early in that we're a fully remote team, spread around the globe. I'm in the UK, several of us are in Ukraine, some in Israel, Poland, Canada, Japan, and more.

What is your role?

My job title is "Senior Mobile developer"; my focus is working on the Android applications, but I touch the iOS portion which some regularity too.

How big is the product team; What's the makeup of your team?

Some 17 strong:

1 Chief product officer, 1 director of engineering, 3 back-end devs (hiring for 1 more), 2 front-end devs (websites), 5 mobile devs (2 iOS, 2 Android, 1 team lead who does both), 2.5 quality assurance engineers (1 of them also has responsibilities in advertising operations) + hiring for a new QA team lead, 1 UI/UX Architect, 1 UX/UI Designer

What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?

For bugs coming in, usually they are reported from the customer support team. Customer support brings it up to the QA team through Slack; QA team creates a Trello card and attempts to reproduce the issue. If they can't reproduce it, generally the customer is asked for more details, given instructions to capture logs where applicable. New incoming issues are brought up during a daily meeting, and if necessary, a developer will subsequently take a look at it - not to start fixing it yet, but to help investigate. After QA determines severity of the bug (which determines fix priority), the Trello card is fleshed out further and queued up for development. If it's very urgent, a developer will drop what they're working on and fix it, otherwise it'll be queued for after higher priority work.

For minor other improvements, like something someone in management, or a member of the product team would bring up, it is pointed out in an appropriate slack channel, and stakeholders will give their input. If it's decided to make the change, either the person who initially brought it up, or the relevant dev team lead will put together a trello card and show it to the stakeholder for their thumbs-up. Then it enters the development process depending on priority. If it's some refinement that goes well with on-going work, it's likely to be slipped in with it.

At this point, the process becomes mostly the same: A developer picks up the task, writes the code and tests locally. Once they're satisfied, they open a new pull request against the main branch (using git/github), and notify relevant other devs on the trello card (and recently, using "request review" on github) that it's ready for code review. Other dev reviews the code, makes any suggestions / change requests. Implementing dev revises changeset / discusses with reviewer until they're both happy. Around this time, a testing checklist is also made up by the implementing developer, which can include any specific cases that aren't immediately obvious by the description; particularly things the developer knows where touched by the code changes.

Then, as the task is declared ready for testing, a QA engineer picks it up, and installs the build linked on the card (or uses a specific staging environment that's been set up for the changeset, if for web). They verify everything works as expected, and try to break it. ;) If issues are found, they are documented, logs/screenshots provided, and the card gets put into a "needs changes" state, where the developer can pick it back up to address things. If no issues are found, it is marked "good to go", and the developer is free to merge to git branch to the main branch, at which point the Trello card is added to a "pending release" list, where we regularly push out new releases to production.

How much (if any) paperwork/bureaucracy is there involved with releasing a new feature/bug?

I like to think, not much. Generally it's just Slack conversations that turn into Trello cards if it's a small thing. For larger features, the product manager, designers and team leads work together to document and specify all the requirements for the feature, using Confluence. On here, other members of the team also have opportunity early in to make suggestions and ask questions about specifics. Once this document is stabilised, Trello cards are derived from it and queued up, and the usual process kicks off. For larger features, individual parts may be completed and merged to a main feature branch, before making it to release.

Tell me about your process for planning work in, do you use sprints? Does it work well for your team?

We've somewhat recently started using 2-week sprints, and it works better for some part of the team than others at the moment. We've always had a kanban-ish style approach though. We currently have long-ongoing feature project, for which the 2-week sprints don't really work well, in my opinion. There's too much still going on to box parts of it into 2-week sections. I do think after it is out of the way it will start working better.

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?

As mentioned a bit earlier, often our testing checklists are initially writing by the implementing developer. During QA there regularly is conversation between the tester and the developer, to clarify. The QA engineers have some regular things they also add to the testing, particularly the "unhappy" paths. For "Release candidate" builds they've got a well-documented series of tests that are performed to ensure all the critical parts of the application work as expected.

Amount of testing work isn't usually taken into account when planning what to bring in, except if it's a very minor looking thing that would have a disproportionate risk of new bugs attached to it.

What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?

We've built some infrastructure into the app for serving adverts. Working out the exact business logic for the conditions under which they should be served, rate limiting etc was a huge hassle. Complicated flow charts were drawn up, adjusted until stakeholder approval, and eventually implemented, with unit tests to verify everything. Later, already in production, it was revealed that still some assumptions were made; needless to say, they were wrong assumptions, and more adjustments had to be made.

Another thing is that we've had some developer unhappiness about parts of the stack we're using it. Budget restrictions meant that there are only limited options available for a process to swap that part of the stack out - we have no resources available to drop product development and do a rewrite, so some less than ideal middle group solution is being worked on.

Which (if any) tools do you help to keep track of work?

Our main work tool is Trello, where all the work is organised into cards, across several boards. These are mainly "development" (for back-end, web, and mobile teams) boards, defect triage boards, and planning boards.

Other than that, Slack, Github, Confluence, Circle CI and TeamCity for continuous integration.

You mentioned that you have cards across several boards on Trello, how do you manage this? Does it become an issue to find a card or does it work well for you?

It can be a bit tricky to find cards sometimes, particularly in cases of "I wonder if there already is a card for this issue" cases. However, for related cards around boards, we often add a "Related cards" checklist where we link to them. Manual, but it does the trick to keep things connected where relevant.

I work with a group grocery buying business based in London.

What's your role?

I’m the software developer that develops literally anything they need doing, mainly JavaScript but also the DevOps for the product.

What’s the makeup of your team?

It’s 3 developers, 3 testers and one copywriter.

So if say something tiny needed improving, low impact, how easy would it be to get into production?

That’s funny, I’ve done exactly that this morning. Well it started off the other day, but to be honest the founder just said developers need an easy way to stage their work, so I said I can build an automated staging environment that setup environments based on their GitHub profiles for this product. He asked what the benefit was, so I told him what it was. He did yeah, do it today.

Is it always that way if you say there was a bug would you fix it that day and it be out that day?

No, the way we report bugs is we have us sprints so anything that's reported goes into the new column.

On Trello?

Yeah on Trello, but we are looking to move them to Github.

We add it to the new column and then they triage it and then during their pre-sprint planning meeting they add it to either the sprint column or the pre-sprint column depending on the severity. So if it’s urgent it goes into this sprint, depending on the priority.

So is that how you plan all work in for sprints?

That's just the bugs. There is a long backlog of features and other bugs that aren't mission-critical like layout problems or we want to change how this thing looks or change what the button says.

They, both the founders, settle on a topic and decide in pre-sprint planning what should be in the sprint. As the developers we say this is going to take this long and we tend to work each to 18 to 21 points for the 2 weeks.

Then once we get to 21/22 points we stop adding stuff to the sprint. The points are based around this premise that 8 points is about 3 days. I know you’re not supposed to add time to the points, but it needs quantifying.

Does it work well for the team?

We are constantly refining it. At the beginning of the project we said about having all this process in place straight away, like sprint planning, but it just didn’t happen. It was impossible because we were building a brand new thing and nobody had sat down to break it up into into tasks that weren’t "build the entire admin" but over the last four or five months I’ve really pushed on getting sprints in with the founder and sorting it out and (it’s such a silly thing to say as it means nothing to anybody) but as a scrum master, I've been guiding the founder through how to be a scrum master.

So did you have training to become a scrum master?

I did, I spent a few years in London being trained.

Was that worth it?

Um... no. It is valuable to teach to clients because it's an easy way for them to manage my relatively unmanageable time. It's difficult to manage a developers time. Because a bug happens so they stop doing what they were doing and they do the bug. It becomes very easy and transparent for the founder or a client to see what's happening in why and when with sprints.

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.

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.

I’m working as a part of DeviantArt. After Wix acquired it back in 2017, we started working on a huge redesign. When I saw this position, I didn’t even know DeviantArt still existed. I was a user of the website back in mid 2000s and this was the website I found my first Photoshop lessons on.

I have a small Design System team which is working on building a ton of infrastructure along with our redesign process. I think it’s the right time to do so since we had a lot of performance, consistency, infrastructure and team communication issues...

I think this is a perfect job for me and my team since all of us are a very organized people who are very detail-oriented, great at communicating and spotting issues in the processes. Our team is the best!

What's your role on the team?

I joined the team for a role of a Product Designer, but now I mix this role with managing Design System and a Design System team. The opportunity for this transition came from me suggesting some improvements to the way we design, doing some small internal workshops and handle our communications. Basically, It all came from my natural frustrations about issues we had and working my way to improve it for myself and everyone around.

For example, here’s a list of things I’m handling at this very moment:

1) Design of our first Mobile Web version and after I finish this simple build, we will pass this to our smaller teams handling different parts of DeviantArt

2) We prepare for our biannual Design System off-site where we discuss all the big issues we noticed in the past half of a year and we plan action points on solving them in the next period. It usually takes 3-5 days of meetings, white-boarding and planning. We try to gather feedback from Product Managers, Devs, QA etc all the time and put it into a spreadsheet, then we investigate those issues, prioritize them and go to an off-site to discuss.

How big is the product team?

Everyone in DeviantArt is in a product team. We have small teams(we call them Bands) dedicated to some specific parts of the Product tackling their issues, planning their workflow and working in their own sprints. Each team has a Product Manager, some Designers, some Front-End Devs and QA. Everyone in the team has a right to affect the product.

As for our design group, each month we have something called “Creative day” where all of us gather in small groups of 2-3 people and build some concept which can improve DeviantArt in a certain way: whether it’s an infrastructure project, some community improvement or just a feature they wanted to build a while ago. Then those projects are evaluated by the Bands and those Bands consider building them and release to our users.

What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?

Our usual triggers for improvements are either data or user feedback which was reinforced by further research into the issue. We have a ton of data in Tableau and everyone in the team (from devs to support) can access it and raise the flag if they see something unusual. After the issue is raised, it’s been evaluated by the Product Managers and one of the bands take it into their roadmap.

After the time has come, Band’s Product Manager and Designer(s) start doing their research. They investigate the issue, figure out why it’s the issue and what it affects and they start from creating some of the idea concepts on how to solve this issue.

When concepts are done, if the Band has time, they test those concepts on our users. If there’s no time and it’s something very urgent, we release some of them and do split-testing (A/B or other variations of those tests) and continuously watch the data to see how it performs.

The key point here is that we try to spend time understanding the problem rather than just blindly assuming or fixing what user say that need and not really need. Focus is very important for us even in a smaller tasks.

How much (if any) paperwork/bureaucracy is there involved with releasing a new feature/bug? Tell me about your process for planning work in, do you use sprints? Does it work well for your team?

There's not really much bureaucracy. We work in a single workflow in our small Bands. Product Managers, Designers, Devs and QA all user the same board for tickets.

Design documentation is more complex though since we require to cover a ton of system states described for each of the Design System’s components. But at the end of the day, it saves a lot of time when you don’t have to design a ton of screens with a different states of the components inside. Also good for re-usability.

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?

The thing is the majority of the testing is done by either Designers or Product Managers. We usually test our features starting from components used in the feature and all of the states of the component, then the screens. Our QA team usually helps with testing of the back-end and regression since sometimes the release of the new feature breaks current ones.

The testing plan is easy since the list of system states you covered in your component(s) is the list of the states you want to test. Sometimes QA help us find an uncovered things, but this is more of an edge case.

Also, to make it a bit easier for everyone to remember, I created a list of the most common system states we need to cover. Some designers have it printed on their table to make sure they didn’t forget anything.

What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?

To be honest, I couldn't even dream of such a great and professional team and a very supportive management. The biggest problem we have now is lack of time, but it’s ok.

When we were starting with implementing the design system, it was hard to align everyone’s knowledge of the tools and methodologies to make sure we keep everything somewhat consistent. There was some pushback when Designers understood that they need to deliver a much higher-quality designs and documentation which usually takes more time and resulted in Product Managers and Designers being unhappy about it. But in the end, with communicating all the benefits of the Design System to everyone and giving some time to practice and make it their daily routine, we noticed that the quality and the overall mood became way better.

Which (if any) tools do you help to keep track of work?

We use Sketch for Designing and documenting components by our templates.

We use Zeplin for delivering those docs to the dev team.

We use Google Drive + Google Docs and Slides as our storage.

We use Axure for an early-stage prototypes and InVision for testing some flows.

We use Slack as our communication tool and Phabricator as a ticket-management tool(although I and most of the team would rather use Atlassian’s Jira+Confluence but we cannot affect this decision now).

We use WhatsApp and Telegram for our out-of-office discussions, memes posting, business trip chats, etc.

You mentioned about preferring to use Jira+Confluence, could you tell me more about your reasons for that?

Most of us think that Jira is more advanced and goes well with Confluence infrastructure-wise. Also the depth of integration of documentation with tickets is what we need.

Another reason is that all Wix is using Jira as their main tool and we have plenty of people in the office who are truly a professionals and can help us with migration.

As a downsides for using Phrabricator I see:

1) Pain with an onboarding of new devs and designers since no-one uses Phabricator anymore.

2) The search tool in Phabricator is very complex and sorting your notifications out takes a lot of effort.

In the end of the day, it’s up to a small number of execs to make the decision to migrate and it can be hard to ensure the developers are always heard.

If it is “up to a small number of execs to make the decision” with Jira+Confluence, do you have similar issues when you want to spend money on other things? Is it easier to spend a small amount of money than big, or always hard?

Not really. Mostly depends on the areas. For example, we don’t have any problems with spending a big buck for quality when it’s coming to design. In my specific case, I’ve seen my management to be very helpful with organizing big changes and allocating resources for them. I would say it’s mostly related to being open to the change on a personal level. We don’t have any financial issues to think about cutting many corners.

Could you go into more detail about how it went implementing a design system in such a large long-standing project? Was there a lot of pushback? Were some parts of the site harder than others?

So from exec level there was no problem. Some of our design and product execs transitioned from Wix where they already worked with a design system. It saved me a lot of time and brain cells when I didn’t have to do any convincing there.

When I joined the team, we actually had a very primitive level of a design system and I we had a team of 10+ designers designing their parts of the product while still figuring out the visual language for a new version. That was a very messy but necessary part. When I joined the team, I started from bringing more clarity and alignment into the process: like implementing 8px grid, doing some workshops and pushing for design libraries.

With each new Design System iteration, we see some push-back, but it’s mostly based on the fear of the unknown. Sometimes, our incremental change require more of time investment from the team, so teamleads and designers are not always happy about stretching the timeline. Usually, in the end of the day, when you explain the value and give some time for the team to test it out and see the outcomes, there’s no issues left. My team still has to re-evaluate some processes we push, learn from a feedback but it’s a natural thing to do in a product so we’re fine with it. We’re not stubborn for the sake of it.

As for the hardest parts of the project, I see the alignment as our biggest challenge. We have a huge backlog of designs we were delivering for 1.5 years and now we try to bring more consistency in our patterns and overall look and feel. This usually takes multiple teams working on the same part and a decent dev investment into rebuilding an infrastructure. It’s sometimes a pain to negotiate putting this activities into a roadmap, but it’s something we’re successfully managing to do at this moment. This is also very related to my management being open-minded about allocating a resources for my team.

So from exec level there was no problem. Some of our design and product execs transitioned from Wix where they already worked with a design system. It saved me a lot of time and brain cells when I didn’t have to do any convincing there.

When I joined the team, we actually had a very primitive level of a design system and I we had a team of 10+ designers designing their parts of the product while still figuring out the visual language for a new version. That was a very messy but necessary part. When I joined the team, I started from bringing more clarity and alignment into the process: like implementing 8px grid, doing some workshops and pushing for design libraries.

With each new Design System iteration, we see some push-back, but it’s mostly based on the fear of the unknown. Sometimes, our incremental change require more of time investment from the team, so teamleads and designers are not always happy about stretching the timeline. Usually, in the end of the day, when you explain the value and give some time for the team to test it out and see the outcomes, there’s no issues left. My team still has to re-evaluate some processes we push, learn from a feedback but it’s a natural thing to do in a product so we’re fine with it. We’re not stubborn for the sake of it.

As for the hardest parts of the project, I see the alignment as our biggest challenge. We have a huge backlog of designs we were delivering for 1.5 years and now we try to bring more consistency in our patterns and overall look and feel. This usually takes multiple teams working on the same part and a decent dev investment into rebuilding an infrastructure. It’s sometimes a pain to negotiate putting this activities into a roadmap, but it’s something we’re successfully managing to do at this moment. This is also very related to my management being open-minded about allocating a resources for my team.

Could you go into more detail about the acquisition? It’s a process I’ve never been through myself, how did it go bringing the various people together? Do you still have any fallback from it or anything?

So I actually wasn’t a part of the team in the moment of acquisition, but from what I learned, there was a half of a year period before and after acquisition when new and old team just did a bunch of onsite meetings to learn the product.

The main goal of Wix was to keep as many people from the old team as possible and make the transition smooth and seamless. The pre-Wix guys know about DA and the community so much more than us and they bring a lot of value into our daily work. There definitely were some people not happy with the acquisition who had a completely different vision and left the company, but you cannot make everyone happy anyway. We kept most of the team and I’m happy about it.

For the design team, I’m completely happy that we kept 100% of the original staff and the insights they bring are great. We would never figure out the logic and thinking process behind some decisions if not them.

Transitioning is definitely hard, especially when you’re working on a big change to a product. You need to merge 2 teams who are used to different styles of management, workflows, culture, etc. 2 years later, we still have some differences, but we made a huuuuuge progress during this period.

You have three big offices and also have remote workers around the world. How does this work for you? Is your specific band across various places?

It’s kinda hard with devs since we hired a lot of remote devs recently and I’m not familiar with most of them except of discussions in the Phabricator tickets.

My team is mostly in Kyiv and I think this is the best way to work. It’s challenging when you need to discuss some major things with people with an 11h difference in timezones, but mostly we Slack pretty efficiently and have a regular meetings to update on our progress.

How does the design and development teams work together? Do you have developers assigned specifically to your team? Do you “pass over the fence” or work together? How does your “feedback loop” work in that sense?

We have devs assigned specifically. It’s not working perfectly right now since it’s a transition period, but it will soon, Each Band has their own weekly meetings and Devs and QA also take part in them. Usually product discussions, planning, etc is being addressed on those meetings and everyone has a right to say.

As for process, I think it’s depending more on a designer. For example, for me it’s easier to run a couple of small demo meetings with devs to make sure everything works rather than design something awesome and learn that it can be developed in like 6 month which we cannot afford and all of it will result in a chaotic cropping of my feature

That said, I would say about 2/3 of design team talk to devs regularly. Other 1/3 don't and only does kickoff meeting.

I work on our design system and visual design language for product.

What is your role?

I’m a visual designer.

How big is the product team?

Can’t tell how big the product team is. If you include everyone that doesn’t include sales, marketing and IT, then maybe 2000 people?

What’s the makeup of your team?

Back end engineers, UI engineers, program managers, product managers, designers, content developers (really technical writers), some testers.

What’s your process like for going from the idea for a small improvement (not a large task) to it going live in production?

Propose it to design team, create a Jira and assign to the UI dev lead.

How much (if any) paperwork/bureaucracy is there involved with releasing a new feature/bug?

Depends on the size. Little to none for small improvements, quite large for bigger features.

Tell me about your process for planning work in, do you use sprints? Does it work well for your team?

There is no process for planning work on the design team. I don’t think this works well at all as their is a clear disconnect between what we propose in design and what gets released.

We have discussed it recently. We were in production mode for months just cranking things out. Almost like working in the kitchen of a restaurant or something. But we finally got a breather and have started a design ops process. Then we’ll see how it works out with the dev process as a whole.

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?

We rarely test. Even when we do, it doesn’t inform the final product. We have gone with features that tested poorly.

What’s the biggest annoyances you’ve had around getting stuff done, planning, working together as a team, or that kind of thing?

The biggest annoyance is that every small team has the power to derail consistency and a good experience. One team—sometimes even one individual—can decide to do something completely different, go off on their own, and there’s no accountability.

Which (if any) tools do you help to keep track of work?

I use JIRA, Google Task and Google sheets. But there is no standard.