Planning for the DCP

[brianraymor]

In review with Product Owners prior to sharing for broader community review. March 15: Last call for community review March 18: Paused for input from Roadmap process (DCP Project Leads)

Based on the evolution of the roadmap and planning process in coordination with Oversight, I'm withdrawing this RFC. The planning+execution process that the DCP has prototyped in Q2 and Q3 has both clarified and simplified the process. Cara Mason and I will be publishing a Roadmaps+Planning RFC in Q3 for community review.

[diekhans]

The need to think and work outside of the boxes is a serious problem with the DCP. Ownership of boxes (aka charters) is key to maintain the architectural integrity and knowledge base of the components. However, we need to be much better at rapid delivery of cross-component functionality.

An approach of functionality-focused groups (tiger teams), consisting of members of different boxes, working on delivering cross-component features would be very useful in addressing the current slow pace of development.

It some multi-team environments, this would be achieved by creating a feature branch and the tiger team do the development on the branch. Member of one component group could modify code other components, with advice and review at merge by the component owner. The feature is delivered by merging the branch.

This is not necessarily simple, but it is an approach that allows focusing on who-product features, parallelizing development, and balancing developer resources across boxes.

Perhaps because I am not a PM, I am not seeing how this proposal helps to accelerate the delivery of features. It would be good to make this more explicit.

The 4-week sprint cycle seems painful long. My read is that this means if component Foo is implementing a feature and at in its sprint and discovers that it needs something from component Bar. Does this mean that Foo must wait for Bar to complete its current 4-week sprint, then get the requested feature into Bar's next 4-week sprint, at which point Foo can receive the feature and continue development. This seems to be creating a 12-week turn around for Foo to complete a feature.

[mweiden]

I'm approving here too. I imagine we'll have to iterate on this over time, but that seems to be within the spirit of the proposal and the discussion.

[lauraclarke]

I have concerns about this proposal as it seems to add a more heavyweight meeting intensive process when we are already struggling to find time to hold the meetings we need to due to the nature of our cross timezone collaboration.

It is also unclear how this improves alignment without damaging individual component autonomy.

Norman's suggested success metrics seem like a start for measuring the value of the process compared to the overhead of operating it.

I am happy for this to start as a trial and then using these and other metrics to consider the cost vs value of the process.

Improving transparency as well as cross-team communication and collaboration is great but this needs to be balanced against the risk of introducing a high overhead process which damages our ability to be agile.

[brianraymor]

@morrisonnorman - It's difficult to determine metrics to measure the success of a process in the absence of a baseline - are there current baseline metrics to measure the success of our current informal processes? I'd definitely like to improve the acceptance criteria.

@lauraclarke - Regarding heavyweight meeting intensive process and a high overhead process which damages our ability to be agile

My perception is that DCP is not currently agile in the sense that I understand it. This is the most lightweight process that Trevor and I could layer on existing practices. It's vanilla Scrum @ Scale. Would you suggest a more time-efficient process that achieves the same outcomes without requiring conversations between component teams with many dependencies? Agile by its nature is very chatty.

I strongly believe that we could spend less time in meetings across the community with clear roadmap priorities. See my response to Justin. Focus on one or two priorities at at time.

We could also potentially eliminate the need for additional meetings by reusing existing meeting times. For example, every other week, there could be separate meetings for Project Leads and Product Owners during the Thursday PM meeting slot. The Product Owners could use that slot for Refinement. The Project Leads could focus on Roadmaps. Tony and I were musing on this earlier today. Or we could all relocate to Cambridge.

Do you believe that we should eliminate the Review and Retrospectives to save meeting time?

Regarding damaging individual component autonomy, I noted in Drawbacks and Limitations: The adoption of a shared DCP community practice in preference to institutional practice requires compromise and adaptation which can be challenging. We're limiting individual component autonomy to some degree to align on shared DCP priorities.

Based on the reiteration of damage and damaging, I visualized this RFC as:

If you have strong feelings against this proposal, you should feel comfortable rejecting it during Oversight Review. I'm very zen about this proposal. Trevor and I certainly don't want to damage the community. My only request is that you would be prepared to pick up the pen as we say in editing circles and propose better ideas.