Missing roles on the R&D team
I think it's becoming more apparent with the knowledge base that the R&D team is missing a couple of roles that are quite common on more mature development teams.
Full Time BA/BSA
Right now the planning falls largely on the team and as has come up in the last few retrospectives is not done nearly enough.
@Linc partially fills this role, but also wears many other hats, from heavy interactions with support, handling developer 1:1s, managing releases, deployment.
For the development team to work well, and at a high velocity, we need to be able to start a sprint with:
- Users stories complete.
- Mockups finalized.
- Technical specifications largely completed. This includes API schema, user interaction details, and edge cases thought out.
- Writes acceptance criteria and acceptance tests for major features. Here's a pretty solid example of an acceptance test.
These could be completed by the developers, but would reducing the scope of a sprint, or increasing the duration of it.
Having one person being responsible for gathering these, and compiling them together would likely be far more efficient though.
QA Tester
We currently front-load this entirely onto a pull-request, which slows down pull requests immensely. While dog-fooding a product can partially alleviate the need for this position, it is not a replacement.
I think @AlexanderKim has some stronger opinions than me here. Maybe he can add to this one.
Comments
-
I've had this opinion for a while myself as well. If we really want to push hard to finish the Knoweldge Base as soon as possible, we can't expect everything to go smoothly without having a solid plan. If we want to continue the way we work, that that's fine, but there's going to be a lot of hangups and we'll need to circle back on thing. It'll be slower.
1 -
I completely agree with @Adam Charron .
This picture matches the most with my vision of how ideally development/sprint/story/release should be organized.
What we are doing right now (percentage is just my personal feelings):
- Todd acts as: Customer (100%) and BA (25%).
- Devs acts as: BA (25%), Devs(100%), Testers (25%), Customers (25%)
I don't think that Project Manager is something we don't need. But I would set BA and QA in 1st place, since those roles would have a big impact on R&D team if we can get them in the team. And I think PM should be Lincoln call.
I understand that we have limited resources. And we can not fix it quickly.
But I would be very glad to know that the team and management are on the same page about this subject.
1 -
This is the other side of the same coin I posted about last week:
The question is always: "How do we maximize velocity (per staff) of a team?" There's basically 3 ways to increase velocity:
- Improve process.
- Add developers.
- Add supporting roles (Manager, PM, QA, Product Owner, Scrummaster, etc).
Process we iterate on constantly. We've just identified a bunch of new process improvements we can make relatively painlessly. The big two, today, are leaving adequate time for QA & testing at the end of sprints (very good process forever), and adding a weekly planning meeting for decomposing future sprint tasks (perhaps a bandaid for lacking a PM, we'll see). There's a lot of flux here, and probably always will be.
Adding developers is, to me, the most challenging way to increase velocity, but it feels like it should be the easiest. The time/cost of onboarding & training is always underestimated and the impact of adding person-hours is always overestimated. This mismatch of expectations to reality is a big ongoing challenge for me.
Supporting roles are the ones that have the biggest benefit but are the hardest to justify on paper. How can I estimate the impact of a project manager for the R&D team? I don't know. What percentage of release & support problems would be headed off by a QA position? No idea. But I think there's overwhelming anecdotal evidence out there in books, articles, and talks that adding those positions (carefully) has an outsize impact.
I agree there is a growing need for those roles at Vanilla. Whether we're at those tipping points yet is something to continue discussing, but it's notable that no one has yet said, "What we really need to go faster is more developers."
0 -
I agree there is a growing need for those roles at Vanilla. Whether we're at those tipping points yet is something to continue discussing, but it's notable that no one has yet said, "What we really need to go faster is more developers."
I think the reason for this is that we're still trying to break our current team out of independent silos, and still have a lot of internal training and work to do among ourselves.
It's much harder to bring someone into a role if the number of people that can assist them or review their code for a given task is only 1 person.
1 -
The more I've thought about this the more I agree with it.
1
