Gardening Your Product Process

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

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

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?

Edited:    |       |    Search Twitter for discussion