One of the reasons for wanting to talk to people like you is to see how other teams handle bottlenecks. For example the development work for a low priority change can be finished long before it can get through the pipeline to be deployed. Is this something you've experienced, are you able to identify any specific bottlenecks?
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.