I wanted to start this thread in hopes to initiate a thoughtful and constructive dicussion about the possibility of revisiting the idea of scrum/feature teams for the Haiku project.
I over the past year had a couple of email exchanges with one of the longtime contributors of the project discussing the above topic and thought I would at least share here what my thoughts were (from that actual email)…
So I have been giving this thing a lot of thought. I think the idea of teams could work if organized well, which would take some work (obviously).
Basic team structure could be the following…
Product Owner/Team Lead
Developer(s)
QA Tester(s)
Technical Writer(s)
…the Product Owner/Team Lead could also play the role of Scrum Master though no one likes that role from my experience and that could be shared amongst the team.
The teams could be feature based allowing them to have free reign on any area of the codebase so that they don’t have dependencies on other teams to complete their work. Obviously, sometimes you’ll have such dependencies when doing heavy integration work and/or may rely on expertise of a given team to help with development. Developers, QA Testers, and Technical Writers, etc… could be members of multiple teams if they so wish.
The idea I had for sprints was to just simply make them month bound. So each month represents a single sprint. Maybe once a quarter you could pre-plan the next 3 sprints and maybe even get some loose commitments that would help in capacity planning for each sprint. I think working in a more kanban way where managing balance of capacity with demand is more fluid and forgiving. Working with the mindset of under-promise/over-deliver is truly key and pushing what didn’t get done to the next sprint is okay. I think the most important thing is to ensure that developers and QA testers are having fun while honing their skills at the same time (helpful in their day jobs perhaps?). I think working with the agile development process is beneficial for the same reasons as these folks who volunteer learn how to work with such a process if that is in-fact what they work with in their day jobs.
I also have struggled for years on how to best incorporate the QA process into the Haiku project knowing that it can’t really get in the way progress but I think I have finally come up with an idea that may work. Basically, QA would focus on testing and reporting and giving those in the project great visibility in the overall quality of Haiku but without having any real authority of when it ships and let those who make the judgment call be better informed. QA would also help manage the backlog of bugs and keeping them up-to-date and close them when they can no longer be replicated, etc…
I was curious if there was any sort of project management type folks that keep the Haiku ship pointing in the right direction? I’m guessing that may be part of your responsibilities to the project?
Anyways, all the above said is not in great detail, but really just me thinking out loud and I wanted to respond to your reply in a somewhat timely manner. I think feature teams and some structure could work if done the right way. You obviously know the Haiku core developers better than anyone and would know if they would be receptive to a more team oriented structure bootstrapped with an agile development process to help guide them toward delivering obtainable goals.
…extending on the above said, I realize that some of the contributors prefer to work alone and also span across multiple things needing their attention in order to get critical things done. My thought there was to establish a sort of tiger team where such folks can work in the way that helps the other teams be successful but remain a lone ranger (of sorts).
I ask that you please keep the discussion constructive and thoughtful. This is meant to share ideas, etc…