rfc: organizing work #11
Conversation
alanshaw
requested review from
travis,
Gozala,
gobengo,
joaosa,
heyjay44,
vasco-santos and
reidlw
|
|
||
| In the case where a stack item is bigger in size than a phase period, members MAY select a set of sub-tasks that can be completed in time. | ||
|
|
||
| Items MUST be assigned a DRI (Directly Responsible Individual) _and_ a support member. The support member is primarily responsible for reviewing PRs, but MAY assist/pair in other ways. Support members may the DRI for other tasks and vice versa. Larger items MAY involve more than two group members. |
There was a problem hiding this comment.
Missing word, "be":
Support members may the DRI for ...
|
|
||
| Generally a work item would move from inception to completion through a pipeline in the following order: | ||
|
|
||
| 1. **Heap** - anyone can pile stuff onto the heap. It's just a place to track things that we may want to work on in the future. It can be of arbitrary size and detail. |
|
|
||
| All members SHOULD read RFC documents and provide feedback to allow the author to determine validity of the work item and adjust or clean up if necessary. | ||
|
|
||
| 2. **Stack** - prioritized work items. _Unlike_ a conventional stack, items are added at a position that denotes their relative priority, however, as per a conventional stack, items are usually "popped" from the top. |
There was a problem hiding this comment.
There was a problem hiding this comment.
this might be out of scope here, but it feels like it might be worth acknowledging that we will sometimes pull from further down the stack if, eg, the person pulling doesn't want to/isn't able to work on the thing on top of the stack - I'd love to encourage a culture of people picking up things outside their comfort zone, but sometimes that's just not the right move.
this may be obvious enough that it doesn't need to be memorialized here, just running my brain around it a bit!
There was a problem hiding this comment.
Agree @travis, and none of this should be considered super rigid. Guidelines, not laws.
There was a problem hiding this comment.
If we just call it a backlog, we can treat it like a backlog, rather than try to figure out the right data structure that isn't actually an exact match for thing thing we want :P
|
|
||
| Phases SHOULD NOT last for more than one month. It is RECOMMENDED for phases to be _two weeks_ long. | ||
|
|
||
| Every phase SHOULD have a name, e.g. Crusty Koala. |
|
|
||
| 3. **Phase** - a short period of time where items on the stack are worked on. It focuses group effort on a particular theme and is analogous to a "sprint" in Scrum. | ||
|
|
||
| A phase MUST be created by group members who will be working on the items. Members decide on a theme and select a set of items from the top of the stack to work on. At this time a size estimate SHOULD be calculated per item to determine whether enough time exists to achieve the task within the phase period. |
There was a problem hiding this comment.
Do you imagine multiple Phases in progress at the same time across the organization? It feels like that will inevitably be needed as the team grows and work streams diverge more, but maybe we're not there yet? Do you have any thoughts on how many people would be involved in a single phase or is that out of scope for this doc?
There was a problem hiding this comment.
This is also the part that I wanted to push on a little. I don't think we're realistically going to have thematic phases. I love the idea in principle. I think we should try to minimize the number of different things being done at once where we can.
There was a problem hiding this comment.
I would also prefer to work in thematic way as much as possible. I think it can be mostly achieved if we have smaller phases, at least for a team of our size.
However, at the bare minimal to accomodate team growth, I think we should commit to:
- have non silos where one single member takes a thematic phase
- not have members spread into more than one thematic phase (unless of course it finishes half way through phase)
There was a problem hiding this comment.
If we going to stick to terminology borrowed from computer science, this should be called threads 😅
Jokes aside I do agree with @vasco-santos single person per theme / thread creates silos echo chambers and demotivation. I would also argue that goal should be more about a checkpoint and reevaluation than it is to drain an allocated stack. In our prior retrospectives we keep pushing timelines to drain the stack, it would be more rewarding to just call it re-evaluate and start another phase / thread.
There was a problem hiding this comment.
Stepping back: we have an incredible mountain to climb in a short time ahead of us. Looking at what we have to build, the size of our team, and the timeframe involved, this is easily among the most daunting engineering project I've been a part of.
I just want to paint what I think is the likely reality ahead of us: I don't know if we're going to have the luxury of truly adhering to the ideals that we probably all generally share. Stuff's just gonna need to get done, it's going to be rocky and even thrashy at moments (we of course try to reduce this), and we're all going to be doing our best to do this audacious thing on a very short timeframe. I feel it's important that we have this expectation in mind when having a discussion like this, so we don't go too far into splitting hairs on the finer points.
All this said, we need heuristics that we (strongly) consider in how we dynamically balance work across the team, and these SHOULD include:
- Swarming based on expertise/skills
- Biasing for latency (building something fast) vs. bandwidth (building lots of things at once)
- Spreading knowledge
- Preventing silos
- Skill development / personal interests
- ? others we'll come up with
I do see it likely we evolve small sub-groups of people who are focused on certain types of problems that might last for months/quarters, and have had several discussions with people in the last couple weeks around what those focus areas would be. Let's keep those conversations going. But even here, things will surely need to be fluid.
|
|
||
| 2. **Stack** - prioritized work items. _Unlike_ a conventional stack, items are added at a position that denotes their relative priority, however, as per a conventional stack, items are usually "popped" from the top. | ||
|
|
||
| Items SHOULD be moved from the heap to the stack as part of a regular lightweight planning exercise that SHOULD include members of the group that will be working on the items. At this point a short description that details the _product benefits_ and _desired end state/outcome(s)_ of the system MUST be added if not already present. |
There was a problem hiding this comment.
I would love to work in a more metrics driven approach when possible. May be included in product benefits, but I would explicitly include metrics to take into account for the prioritization, like number of customers interested, their volume, etc
There was a problem hiding this comment.
Can I just x100 this? :) Yes - couldn't agree more @vasco-santos. As we start populating the backlog with stuff, I'd like to push for a simple template that calls for articulating both the projected impact of the work, and the cost of doing it.
|
|
||
| 3. **Phase** - a short period of time where items on the stack are worked on. It focuses group effort on a particular theme and is analogous to a "sprint" in Scrum. | ||
|
|
||
| A phase MUST be created by group members who will be working on the items. Members decide on a theme and select a set of items from the top of the stack to work on. At this time a size estimate SHOULD be calculated per item to determine whether enough time exists to achieve the task within the phase period. |
There was a problem hiding this comment.
I would also prefer to work in thematic way as much as possible. I think it can be mostly achieved if we have smaller phases, at least for a team of our size.
However, at the bare minimal to accomodate team growth, I think we should commit to:
- have non silos where one single member takes a thematic phase
- not have members spread into more than one thematic phase (unless of course it finishes half way through phase)
|
|
||
| Every phase SHOULD have a name, e.g. Crusty Koala. | ||
|
|
||
| It is not always possible for _all_ desired items in a phase to fit under the same umbrella/theme. It is RECOMMENDED in this case for one member of the team to be assigned to these tasks and for that member be immune from this assignment in the subsequent phase. |
There was a problem hiding this comment.
See my comment above, I think we should avoid at all cost single man show for a set of tasks. If it is not enough work for a phase, we should just have 2 people that would both join the remaining team once done
There was a problem hiding this comment.
I agree with @vasco-santos on this as well. If things don't fit the phase lets either cut it or give prioritize such that there is a group working on it.
It's not just that solo endeavors are unpleasant, it also creates knowledge gaps where whole teams end up depending on a single person with know how.
|
|
||
| Generally a work item would move from inception to completion through a pipeline in the following order: | ||
|
|
||
| 1. **Heap** - anyone can pile stuff onto the heap. It's just a place to track things that we may want to work on in the future. It can be of arbitrary size and detail. |
There was a problem hiding this comment.
Honestly, can we just use the regular names:
Heap -> Inbox
Stack -> Backlog
Prefer terms that a new dev coming in may already know
There was a problem hiding this comment.
+1. The renaming doesn't appear to add anything, and so by default is probably to be avoided.
|
|
||
| All members SHOULD read RFC documents and provide feedback to allow the author to determine validity of the work item and adjust or clean up if necessary. | ||
|
|
||
| 2. **Stack** - prioritized work items. _Unlike_ a conventional stack, items are added at a position that denotes their relative priority, however, as per a conventional stack, items are usually "popped" from the top. |
There was a problem hiding this comment.
If we just call it a backlog, we can treat it like a backlog, rather than try to figure out the right data structure that isn't actually an exact match for thing thing we want :P
|
|
||
| 2. **Stack** - prioritized work items. _Unlike_ a conventional stack, items are added at a position that denotes their relative priority, however, as per a conventional stack, items are usually "popped" from the top. | ||
|
|
||
| Items SHOULD be moved from the heap to the stack as part of a regular lightweight planning exercise that SHOULD include members of the group that will be working on the items. At this point a short description that details the _product benefits_ and _desired end state/outcome(s)_ of the system MUST be added if not already present. |
There was a problem hiding this comment.
"Desired state / outcomes" - I like "Acceptance criteria" -- it's an easy way to define ahead of time how we measure whether the thing that got built does what we said it would.
|
|
||
| Multiple items in the heap MAY result in a _single_ item on the stack. | ||
|
|
||
| Larger items whose outputs are an implementation of some kind MUST also result in a PR to the [specs](https://github.com/web3-storage/specs/) repo. |
There was a problem hiding this comment.
I find this "implementation of some kind" a bit ambiguous. Do you mean a protocol we haven't implemented yet? Every ticket is an implementation of SOME kind right?
|
|
||
| Larger items whose outputs are an implementation of some kind MUST also result in a PR to the [specs](https://github.com/web3-storage/specs/) repo. | ||
|
|
||
| 3. **Phase** - a short period of time where items on the stack are worked on. It focuses group effort on a particular theme and is analogous to a "sprint" in Scrum. |
There was a problem hiding this comment.
This is the one I have the most trouble with. I think we're trying to combine two seperate ideas into a single one.
The first is just a cycle for getting stuff done -- i.e. a sprint, though really I just mean the combination of backlog grooming, sprint planning, and reflection. A "rhythm" to work if you will. I think at least till we are larger, there should just be one of these.
The second is grouping work -- how we insure people can take on big themes together and not get silo'd alone or stuck doing a single thing. I really like the idea of temporary sub team. Essentially, we're all on web3.storage but we can form groupings that work closely for a period of time on a big deliverable -- that can span a month, or even, in some cases longer.
My anxiety about trying to combine both is that we end up making "what's happening" extremely difficult, and impose artificial time contraints on work that may take much longer than a sprint to do.
Am I missing something here in the explanation? Am I not getting what a phase is supposed to do?
There was a problem hiding this comment.
I think this is a really important thing to tease apart.
Co-authored-by: Vasco Santos <[email protected]>
Preview