Scrum/feature teams for the Haiku project?

Feedback Ideas
1

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…

1 Like
2

Hi,
I would definitely welcome a QA team with a more formalized workflow (including more systematic code reviews, etc). However I am not convinced the scrum model would be fit. I’ll try to break this down to various reasons.

  • deadlines. There is no scrum without sprints. However, all Haiku devs work on their spare time which is highly unpredictable. Some months I spend a lot of time on Haiku, some others I have fun with friends every week end or I’m busy with another project and I get no work done. So if I have to go the underpromise way, my plan will be the same every month: “I plan to do nothing”. Which is mostly the case anyways: a lot of my contributions to Haiku come from trying to do something else (let’s say porting some piece of software) and I end up finding bugs in lower layers and digging deeper and deeper. Or someone on IRC raises my attention to some problem they face with some website.
    Working this way allows me to have no stress at all when working on Haiku. There are no expectations and no deadline. I can schedule my own work and change my plans as often as I want.

  • on feature teams: as you probably know this was the case in the early days of Haiku. The idea was dropped because everyone was involved in everything. Small teams are important for scrum (otherwise your meetings and daily stand ups become unmanageable), but with Haiku using asynchronous communication a lot this is not really a problem (one can quickly go through the few e-mails and ticket updates for the whole project faster than your typical scrum team can gather for a stand up meeting). Also, try to identify who would be in each team, you will see that most people are active in multiple places.

  • on “no one wants to be the scrum master”. In my paid work I’m lucky to work in a company where people were hired specifically for this. Having someone who is not a developer in that position works great for us. I like working with people in Haiku a lot, but I think it would be hard to manage the team in any organized and predictable way for a variety of reasons, ranging from the character ofthe devs (but this is maybe a consequence of the current organization where only people with independance and self discipline can survive), to the fact that they do this on their free time and probably don’t want it to be like a second job. So yes, I certainly don’t want to be a scrum master in these conditions.

So, let’s see if we can get to something with no teams, no scrum master, and no sprints. Clearly this will not be scrum, but there is still a lot we can (or did already) formalize.

  • a code review process. Until recently this was done only after the fact with people pushing changes to the master branch directly (a legacy of our early days using svn). We are now using Gerrit which allows to review changes before they get merged. We are still in early experiments with this and have not set firm rules on who does reviews, when can a change bypass the process, etc. This is where having someone nominated responsible for each software component may be useful.

  • goals and roadmap. We took a route quite opposite to agile until now, with just a long term goal (known as “R1”) and not much management of the details. We can reconsider this for R2, because we have no reference of where we want to do. So a more agile flow with features qetting integrated according to a roadmap which is periodically revised souds good. The main difference with what you suggest would be that there is no timeframe, we just pick what looks like a reasonable set of features to implement for the next release and work on them until they are ready.

  • more qa. This is the core of the whole thing. As you mentioned there is a lot that can be done (and has been done informally) in that area with the existing tools. Managing the ticket database, identifying when regressions happened, tracking obsolete tickets, etc. There is also a lotof work to be done on making our existing unit tests work, and more importantly push an unit test culture on the developer team (pushing a fix without a matching unit test should not be an acceptable way to work)

Finally, I think we should also better document and use the existing tools. There is a lot that can be done with Gerrit and Trac, but we can’t really identify problems and missing steps in the current workflow when the workflow is not documented. Usually this would be the job of the quality (not qa) team: documenting the process and making sure either people stick with it, or the docs are updated when the process changes. We could start with a “life of a bugreport” article on the website, maybe?

2 Likes
3

I agree with Adrien here.
Agile process work on a team-agreed shared effort short cycles - called Sprints - driven by TPO needs.
With a volunteers-based team, each with their own free time schedule and will, I fear that finding a synchronized cycles will be very hard.

My feeling is that Haiku project needs:

  • more QA. We lack strong unit tests base, and we don’t run them automatically, which lead to regression being detected by users, not the team itself at first. Coverage tests too, maybe SonarQube, whatever is good.
  • smaller goals, in order to have shorter roadmaps too, not only a long term roadmap.
    Package system was one.
    The current package-based build infrastructure stage is a good exemple, but it was not advertize earlier to the public, missing an occasion to show that 1) the project is still moving forward and 2 it’s moving forward a more robust and seamless build process, letting people hope to more automated release process, so more often releases, something the the project is not known to be good at (even if we’re producing nightling build since years, it’s not what people can call a “release”).
    I also think that some of these shorter goals would be good release milestones, leaving the alpha/beta/final release semantic for a more feature-based release of a beta-software, which is what everybody does in fact for software for end users these days. (Server is another story, but Haiku is not targetting 24/24 strong server OS marketshare anyway).

Maybe we could have a scrum-like grooming stage on a list of shorter goals (from user or dev suggestion), thought
Aka, no strict timing, but an aperiodic cycle of collective team and (user-) feedback driven choice of next short goal(s).
And make this more public than in a dev mailing list.

2 Likes
4

In the Trac workflow, this would be implemented with milestones. There isn’t really a grooming phase (remember, we need to deal with people who cannot be in a meeting room to do this, and may not even be able to gather on an IRC channel). So we could define some milestones with clear goals, and then we can move tickets from one to another.

5

Well, maybe we could find with trac a way to vote for ticket point, no?
What we miss is a way to see which issue/features get more interrested from both users and devs, and how to split them if necessary in order to plan them in a milestone.

Note that in that process, milestones are not long sprints in sequence either, as nothing forbid several milestones to be in progress at the same time.

But, yeah, having long term milestones currently don’t help us to focus first on what people want (to have + to work on).
I dunno how devs vs users will should relatively weight, though.

2 Likes
6

Currently it is up to each developer to decide what they work on. It seems a bit difficult to force them to work on users need (another key difference with scrum: we don’t have a product owner). But I think we can rely on everyone common sense, it seems to have worked quite well so far. There is always someone having fun with an m68k port or the like, but it does not get in the way of anything.

3 Likes
7

Great, exactly, documentation.
As I started to delve into the Haiku code for fixing some ATA bugs with my oooooold PC (still runs BeOS), I tried to understand the code, the meaning of the code, the organization of the files, the thought behind every thing a.k.a architecture or structure model.
I tried to reach out to some (former) devs via email, but even with their help I could not understand the design of the ATA stack.
It starts with the unknown build tool (does anyone else uses jam??), goes over to the complete missing or old documentation about the code organization and ends by finding out that there is not even a standard header used in the code files trying to explain for what purpose blablabla.cpp exactly is.
Also I could not find any clue/references in the code for issues/fixes.

You stated that the dev team is small and fluctuation is an issue. Then a good documentation on every level is a must. But I also know that writing docs is the most boring part of the development :slight_smile:

And by all means please start using modern collaboration tools. I know that the devs are fond of IRC and mailing lists, but young devs are used to the new tools. If I see how development takes place today and compare that to 10 years ago…

2 Likes
8

“modern” is not a reason to use a tool. Irc and mailing lists are open, and easy to use anywhere. Gerrit also works very well and we are happilè using it now. Trac is a bitold fashioned but gets the job done, and migrating our workflow to something else wouldn’tbe easy.
As for documentation, it is indeed lacking. Did you document your findings after digging in the ata stack? Now you may know more about it than I do!

9

Modern may not be a sole reason to use a tool, but most of the time it has other advantages. I, for example do not like IRC, because the system itself does not give you a chat history or some kind of activity trail. You have to find your own way of doing this, organizing your chat dumps. Same goes to mailing lists. Ever searched the archive for topic?
That is where newer collaboration tools shine, tag topics, organize view, find the info. That is why I am pleased that this forum exists and that you visit it so often. But hey, just my 2 cents.

As for Trac, yes it is mighty and good. But it needs some love :wink:. Approx. 3300 issues are listed, containing roughly 1400 bugs. A lot of these older than 2 years, still open, sometimes assigned to inactive developers.
How can you keep focussed :slight_smile:?

As for the docu, yes, I am lazy, too. I have some notes on paper. Maybe I should start with that…

10

Unfortunately they are all still valid. We don’t have a formalized QA team but some people are doing a great job of scanning old tickets from time to time and reporting when things start working. The fact that we have such a big backlog shows how much we need new developers. But on the good side of things: whatever your skills and experience, there HAS to be at least one bug you can solve somewhere in there.

The ticket base is also not that big. Maybe I have a good memory for this (after years of training :wink: ) but when someone asks if an issue is known I do usually manage to locate the ticket. You can ignore the “assigned to” field, it’s just there for convenience of pinging someone about a ticket. What matters is assigning the right component, which provides a quick and reliable way to filter tickets. When you look at a specific component there suddenly is a lot less tickets to navigate. But this is something we should also better document because it’s not obvious to everyone. However, I think this is something that can be done mostly as one learns to use the system (as someone said, “expert at being a beginner”).

2 Likes
11

On this point, note that Haiku has a very good IRC client included, and there’s a link in the channel topic to the IRC log.

Chris