Add initiatives and delivery board description

[choldgraf]

I think that we roughly converged in our conversations on initiatives and operations boards, so I thought it would be helpful to bring the two conversations together into a single proposal that folks can look at.

This PR tries to take the language that we had roughly converged on and writes it up for the team compass. It tries to describe the boards and their purposes, as well as their relationships between one another and how it fits into the flow of work.

I'll tag the initiatives team for feedback, though I don't think it's critical to get reviews from everybody because we've already discussed a lot in the issues. Let's leave this open until Friday or so, iterate a bit, and merge if there are no objections.

Questions to ask

• Does this accurately capture the conversations we had in the issues?
• Is there anything critical missing or wrong? (I tried to cut down on wording so might have missed something)
• Does it feel safe to try?

References

• part of Define the Initiatives board and the Delivery boards (operations + engineering) purpose, structure, and process #816
• closes Feedback on draft proposal for "Operations" board #819
• doesn't yet address Feedback on draft proposal for "Upstream" work #820

[jmunroe]

Thanks for the write up @choldgraf ! I've made some comments but nothing is a show stopper from my point of view. I'd be happy to have this merged once you've received and integrated feedback from others.

[jmunroe]

I think this should be a list of 'tasks' or 'epics' as appropriate to the initiatives. Operations board should be able to track multi-iteration work ("epics"). I don't think it should be required for the initiative to directly list ALL tasks that flow from it.

I think epics and tasks (the things tracked on delivery board) should exist as part of one or more initiatives. But I don't think initiatives need have an explicit list of all of the work that will flow from them. My opinion is there may be automated ways of generating such 'list of tasks' but that should be something we managed by hand in a tasklist.

[choldgraf]

I'll update to make it Tasks and Epics and update the following text accordingly.

To me the most important question is: does the content of the initiative align our team around what we need to do to complete it, or trigger the conversation to refine / add tasks / etc as necessary when we walk the board? My feeling is that we don't know exactly what policy to follow that leads to this, so we should just give it a shot and iterate through retrospectives

[jmunroe]

"Level 3: Strategy"

[colliand]

The nomenclature of drivers as I understand from the text here: Goals --> Initiatives --> [task list]; Is the expectation that the tasks in the task list are refined enough to be actionable and placed on the Delivery board for prioritization. Or are tasks in the [task list] on the Initiatives Board "epic like" and chunked out into sub-tasks on the delivery boards.

Implicitly, I know 2i2c's goals. However, everything in the delivery system described here is driven by Goals. What are the goal statements? I imagine that our soon-to-be-completed Value Proposition feeds into a process where we will define our goals. We also have this issue that has some overlap: https://github.com/2i2c-org/meta/issues/891

[choldgraf]

I'll go with the nomenclature change that @jmunroe suggests. For @colliand's question about tasks vs. epics etc.....I'm not sure, I suggest we give it a shot and see how these tasklists evolve once we get used to using them to drive our work. Does that make sense?

[jmunroe]

Combining 'refinement' and 'planning' into a single ceremony might be a challenging in practice. If I had to choose one, I'd suggest that the planning (prioritization) conversation is the more important part to do synchronously in a bi-weekly meeting.

Initiatives of course need refinement but I don't think it makes sense to have all team members participate in a refinement of all initiatives. Even coordination may not be appropriate in time-bounded meeting. I understand it is useful to have a time to figure out coordination issues or evaluate next steps but I think we should flip the sequence around: start by zooming out at having the prioritization/planning discussion and then, if there is time, discuss individual initiatives that need attention. In particular, I don't think we want to 'walk the board' and discuss every initiative that is work-in-process.

[choldgraf]

I don't feel like I have enough experience or information to have strong opinions here. I'd suggest that we see how the first few meetings go, and decide if / how we want them to be useful (e.g. as a high level prioritization effort, or a more tactical coordination effort). My feeling is that we want to use these meetings to trigger cross-team conversations to ensure that we are splitting work across our teams effectively and providing clarity about what comes next in our sprint planning.

[choldgraf]

I believe that I've addressed all the comments above, and tried to describe where I was unsure of the right move. My feeling is that, at this point, we want to decide if this is "safe to try", and if so, just merge this, make the changes to our boards to start following this process, and then give it a shot and iterate. I think we'll learn quickly what we got right / wrong / etc and we can tweak things from there.

To that point:

I plan to merge this, and then start implementing the various structures described here, on Thursday the 21st unless somebody asks me to slow down or objects.

[damianavila]

Includes all organizational tasks/actions except for Engineering.

So, we are expecting Product to use this board as well, am I correct?
I am "worried" that a definition of "everything except Eng" is actually hidding the complexities for each area inside that "bucket".

I just want to make sure people realize we are purposelly "hidding" complexity (which might the the right path!)

Btw, this is not a blocker IMHO, just some thoughts I had when I reviewed this PR.

[choldgraf]

Yes, the idea is that we all use it to track issues that are focused on delivery and tactical-level things.

I am "worried" that a definition of "everything except Eng" is actually hidding the complexities for each area inside that "bucket".

Could you go into more detail on this? What kind of hidden complexity are you talking about?

[damianavila]

As things specializes (ie. in different areas), it is easier to find differences in definitions, policies, etc.
Even cadences could be different.
With this proposal we are symplifiying pieces, assuming those differences do not exist or are just minimal ones.
We know in advance this is not true, but we can choose to model it like that if we abstract pieces enough high (the current approach). This is what I describe as "hidding"complexity, the fact we know things might be quite different but we are trying to model them with the same common abtraction. And that's a decision we are making and it is totally OK as long as we realize we are taking that decision (and understand their limitations).

Btw, re-reading this above paragraph I notice I am going maybe too meta 😉

[choldgraf]

Gotcha - thanks for this nuance. I think you have a valid concern, and it's something that we should keep in mind once we start following the retrospective process for these boards. That way we can learn and iterate

[haroldcampbell]

I'm in agreement with the changes. I also like the "light" introduction of the flight levels. My current understanding of this process is that we are modelling ONLY the first two levels (FL1 & Fl2) classes of boards.

[choldgraf]

OK, I think that we've got enough information to suggest that this process is safe to try! I'm going to merge this in, and we can turn out attention to operationalizing this process. Assume that anything in this PR is fair game for anybody to implement, please don't feel the need to ask for permission etc :-) . I've also got a few tasks to track taking steps forward in the initiative for this here:

• Define the Initiatives board and the Delivery boards (operations + engineering) purpose, structure, and process #816