Shaping Shape Up

What are some of the biggest changes you made when adapting the process to your team/organization that proved to be effective?

Here are a few of mine:

  • All full stack product teams (empowered cross-functional stream-aligned teams) have their own shaping and betting table workspaces. They align on the pitch before the build cycle and roll that up to management/leadership, not for approval but for visibility and to capture comments/feedback.
  • The whole product team is more involved in the pitch process (demand and supply side); albeit, there is a fine balance so that build cycles are not compromised by out-of-cycle pitch definition work.
  • Team-level OKRs are used to guide empowered product teams around a coherent customer strategy.
  • Our devs across product teams are not using BC to-dos (for tasks), unfortunately. Instead, I have product teams identify the scopes and track only those on Hill Charts (check-in is triggered every Tuesday and Thursday during stand-up), and I have them provide a weekly (every Friday afternoon) check-in asking for a write-up about how the two, four, or six-week build cycle is going. These are answered by the team. I also have a functional check-in asking what will be worked on for the week (every Monday morning).
  • We do mini pitches for cool-down periods and also report on outcomes (we continuously collect user feedback and bugs that inform what should be in cool-down cycles).

Any thoughts on this, @rjs?

I’ll share one thing we’ve tried that is a bit different and I don’t know if other teams do. Our hill charts are verbal. We don’t use graphs.

The problem I had using visual charts was that developers had different ideas of what “uphill/top of hill/downhill” meant. The result was weird stuff like they’d be at the stuck at the bottom of the hill for 3 days and then on day 4 be done. So the graphs weren’t helping making progress visible.

Instead, we’d do occasional check ins where they would verbally describe where they were on the hill. We started using analogies like “Can you see the top of the hill from where you’re at?” or “How foggy is it now where you’re at?” or “How steep is the hill right now for you?”

In most cases, these descriptions only mattered while going up. Once they reached the top of the hill everything else was pretty easy to describe while on the way down.

The main benefit of verbal hill-checks for us was to give the team a shared language of explaining known vs. unknown work, because it was described in a way that was easier to visualize mentally.

Cool use fo automatic check-ins for sure. This makes a lot of sense to me. We tried this, and it worked out well. @rjs, thoughts on any of this?