Especially in this market, everyone is trying to answer this question. It’s not easy… There’s a lot dragging teams down: trying to recruit, pressure from execs to deliver “more with less,” burnout and employee churn, remote onboarding, reliance on offshore teams, and the increasingly complex tech stack — pressing teams farther and farther from the agile basics.
We’ve seen teams approach the above in two ways.
The majority of teams, especially if they’re scaling rapidly – add more planning, process, and management — which does the opposite of what it’s meant to do (speed things up!), and fuels a culture of distrust and CYA between engineering, product, and “execs.”
As teams scale, we see a lot of this…
- Average velocity is abysmal, but you’re running hackathons 2x/year that build amazing stuff in a week – how does that happen??
- Engineers get quiet and defensive about anything resembling metrics – they fear it will get used against them.
- Management pulls their own reporting, and engineering leaders have to answer to those reports.
- Meanwhile, each “story” gets harder and harder to build, and the codebase becomes so convoluted that only the most senior engineers can meaningfully contribute.
We’re also seeing a lot of good…
On engineering teams who’ve been enabled to do their best work, they’re sticking to the agile basics: not over-prioritizing planning, introspection, retrospection, and collaboration. They’ve likely fostered a culture of trust where teams are free to ask and answer the real questions to understand what’s slowing them down.
Teams that look into their stack from the ground up, where the work is happening — enabling micro feedback loops and system level insights — are empowered to easily run this type of organization – getting back to the agile basics.
