Gardening Your Product Process

I'm pondering some thoughts around gardening an Agile Product Development process, inspired by

• some conversations with startups where I found myself saying that lots of process varieties are possible/reasonable, that you iterate your way there via outcome metrics and retrospective;
• John Cutler's Messifesto ((2022-01-02) Cutler The Messifesto), and some tweets I spewed at him in previous days/weeks
• started this at (2022-01-04) Gardening Your Product Process

Some thoughts to integrate:

The idea of One Methodology Per Project is not new (context-driven)

There may be a range of reasonable values (deploy 2/day vs every-2-days), but there's a point where you've gone un-reasonable (2wks for most companies is a smell).

There are some bad ideas (anti-patterns) for most software-product orgs: roadmap, matrix management, waterfall, command-and-control

• see (2015-06-05) Cagan Product Fail
• I personally experienced (2021-11-28) A Diagram of Effects of the AntiPatterns in a Product/Dev Team
• hmm has anyone written a Waterfall Pattern Language? I don't see one.
• how about for Dark Agile? :)

You should understand the JTBD for every practice/framework you adopt.

Practices should probably be clustered into a Pattern Language (cf OrgPatterns)

• so there should be a different language for each context-type
• and then you don't have to use every practice within that language.... but you should use more than 1... and if you're using practices from a different language, that might be an issue...

All change has risk: Intervention Roulette.

You should add/drop practices via retrospective. Every change is an experiment - while you might not rely on quantitative outcomes, you should document what you expect to improve, and what you expect might get worse, before you start, to drive your post-change review.

The current practices should be documented. As should reasons/history of changes.

If you have multiple teams working on the same product-line, how much do you want their practices to vary?

• Maybe the Community of Practice of PMs/TeamLeads should discuss this.
• Non Product/dev executives should not be driving this, though the CPO should be prepared to "sell" this model all the time.
• related/update: found this thread about (macro) process Change Agent pitching, including
  • idea of diagnosis, intervention-attempt, re-evaluation....
  • rating based on Agility, Context, and Team Agency
  • or, for bottom-up approach, a Diagram of Effects for a team with issues