I've not done this collaboratively with others, but do something like this myself with org-mode (for just this one thing adopting emacs and org-mode may be overkill, but it supports this well at least for individual work). org-mode lets you setup your tasks and use nested tasks with multiple states that you can cycle through. Default is just no state, TODO, or DONE.
* Projects
** TODO Integration [2/3]
*** DONE Task 1 :bob:
Write out some details and notes
*** DONE Task 2 :alice:
More details and notes
*** TODO Task 3 [2/3] :bob:alice:
- [x] AWS
- [x] GCP
- [ ] Azure
You can add tags (may be how you indicate someone is assigned), priorities, and other metadata to contents in org-mode which can help. If it's a small team, you can have ownership of a task be claimed by using NAME as one of the states where NAME would be ALICE or BOB, and other people on the team. That doesn't help if a task is shared though, so tags may be better for that.
The main thing missing from this, though the hierarchical structure somewhat helps, is with dependencies. org-mode can enforce linearity, that is that tasks 1 through 3 above are done in that specific order. It can also ensure that a parent task isn't marked done until all its children are done. But tasks across dependencies or more complex dependencies are not baked-in. [0] is something I've found, but not used, that would address this.
org-mode also has the agenda, so if you add dates (like deadlines or scheduled starts) it can help you keep specific activities on track. Say you need that Azure support finished by a particular date, you can add that information to this document. The deadline will appear in the agenda and help people prioritize the work.
And it has some pretty rich filtering available so you can see only what you care about at the moment, and of course it's plain text so grep works along with the regular search features in emacs.
In my experience, a small, well-balanced, well-functioning team needs almost zero formal process. Even regular meetings aren't necessary because the devs are always talking with each other anyway. Coordination happens naturally.
It's one of the main reasons why I strongly prefer working on such teams.
Yep - if you're working with reasonable and experienced people, they'll do reasonable things to get stuff done. Forcing processes onto these people actually make them less effective.
Extreme Programming is about the lightest "methodology". I've seen it used on a team of 30 (20 devs, 10 QA). It scaled that far, but we had a couple of exceptional "XP masters" on our team (just as devs, but they kind of owned the methodology as well).
That eventually fell apart, because upper management couldn't understand agile development, and so they killed it. Never mind that it delivered on time.
But on a small team (4-5 people), I have seen even less process. There was a manager who coded half-time. There was an overall direction, and discussions as needed. Each person had their area of specialty within the code. There were code reviews before checkin, but the code reviews were over-the-shoulder in someone's cube. There was a bug database, but there was no JIRA or other "ticket" system. (There eventually was, after the team grew. And there eventually was a quarterly planning meeting.)
There was a weekly standup for the larger team (20 people). But within the smaller team, each person kept their own to-do list. When your code needed to interface with someone else's, the two of you would hammer out what the interface was.
That won't scale too far. And it risks the mismatch with upper management that the XP team ran into. But for a small team, it can work.
I am happy to read this here. I manage a team of 3 and code half-time. We are heavy on XP, because I introduced it. At the beginning it felt strange for the team but in between the enjoy the empowerment it comes with.
I've not done this collaboratively with others, but do something like this myself with org-mode (for just this one thing adopting emacs and org-mode may be overkill, but it supports this well at least for individual work). org-mode lets you setup your tasks and use nested tasks with multiple states that you can cycle through. Default is just no state, TODO, or DONE.
You can add tags (may be how you indicate someone is assigned), priorities, and other metadata to contents in org-mode which can help. If it's a small team, you can have ownership of a task be claimed by using NAME as one of the states where NAME would be ALICE or BOB, and other people on the team. That doesn't help if a task is shared though, so tags may be better for that.The main thing missing from this, though the hierarchical structure somewhat helps, is with dependencies. org-mode can enforce linearity, that is that tasks 1 through 3 above are done in that specific order. It can also ensure that a parent task isn't marked done until all its children are done. But tasks across dependencies or more complex dependencies are not baked-in. [0] is something I've found, but not used, that would address this.
org-mode also has the agenda, so if you add dates (like deadlines or scheduled starts) it can help you keep specific activities on track. Say you need that Azure support finished by a particular date, you can add that information to this document. The deadline will appear in the agenda and help people prioritize the work.
And it has some pretty rich filtering available so you can see only what you care about at the moment, and of course it's plain text so grep works along with the regular search features in emacs.
[0] https://orgmode.org/worg/org-contrib/org-depend.html
In my experience, a small, well-balanced, well-functioning team needs almost zero formal process. Even regular meetings aren't necessary because the devs are always talking with each other anyway. Coordination happens naturally.
It's one of the main reasons why I strongly prefer working on such teams.
Yep - if you're working with reasonable and experienced people, they'll do reasonable things to get stuff done. Forcing processes onto these people actually make them less effective.
interesting take, many A-list devs I have observed like some structure, it just has to be the right structure.
I guess the guardrails of process are to help focus the more inexperienced. the less you know the more framework you need.
Extreme Programming is about the lightest "methodology". I've seen it used on a team of 30 (20 devs, 10 QA). It scaled that far, but we had a couple of exceptional "XP masters" on our team (just as devs, but they kind of owned the methodology as well).
That eventually fell apart, because upper management couldn't understand agile development, and so they killed it. Never mind that it delivered on time.
But on a small team (4-5 people), I have seen even less process. There was a manager who coded half-time. There was an overall direction, and discussions as needed. Each person had their area of specialty within the code. There were code reviews before checkin, but the code reviews were over-the-shoulder in someone's cube. There was a bug database, but there was no JIRA or other "ticket" system. (There eventually was, after the team grew. And there eventually was a quarterly planning meeting.)
There was a weekly standup for the larger team (20 people). But within the smaller team, each person kept their own to-do list. When your code needed to interface with someone else's, the two of you would hammer out what the interface was.
That won't scale too far. And it risks the mismatch with upper management that the XP team ran into. But for a small team, it can work.
I am happy to read this here. I manage a team of 3 and code half-time. We are heavy on XP, because I introduced it. At the beginning it felt strange for the team but in between the enjoy the empowerment it comes with.
yeh, the illusion of management control is a tricky beast to defeat.