Thread by @johncutlefish

"(0/8) Q: "My team needs help. Where do we start?"

Make sure you are doing regular retrospectives, and make sure you are committing to run a limited number of time-bound experiments to make things better. Reflect. Strengthen that muscle. #lean #proddev"

(1/8) Realize you may have blindspots. So occasionally invite outsiders (from inside and outside the org) to your retros and invite them to pattern match with you. Invite them to offer potential experiments. #lean #proddev

(2/8) Related...start a learning-focused series of book clubs, outside speakers, paper clubs, and company visits. Basically...stay as exposed as possible to outside ideas. #lean #proddev

(3/8) If necessary, bring in outside help to coach/train/explain/or observe. There is no shame in this. If this intimidates your manager...well, that's a problem. Do your best to finesse the conversation. Make it their idea :) #lean #proddev

(4/8) Limit change in progress (or in this case experiments in progress). That'll make it easier to sense what is going on. So will limiting work-in-progress, so I suggest that as a potential early experiment. #lean #proddev

(5/8) Create the safety to run experiments like "let's track time spent on unplanned bugs" etc. IOW, really explore all available options to inform your experiments. And treat measurement itself as an experiment. #lean #proddev

(6/8) For external impediments where you have limited autonomy to resolve the issue, be sure to capture those and decide as a team how you'd like to approach advocacy. #lean #proddev

(7/8) Now...this should be 100% doable in your org. If not, there's a problem: trust, safety, miscalibrated manager roles, etc. Often someone sees it as their job to control this type of work and let the "team focus". You'll have to work through this. #lean #proddev

(8/8) One potential pitfall is that you've picked a system boundary that you don't really control. So that is something to watch out for. If necessary, start "smaller" and more localized. #lean #proddev