At large scale, many of our finest arguments fade into noise.
Much of the Lean Agile community is riven by argument, either with each other, or with traditional management. Yet it turns out that when you view the delivery organisation with enough distance — say from the leadership of a 500+ person group — many of those arguments fade away; they become not much more than noise, and it becomes surprisingly easy to take the hard core answer, as it becomes hardly worth arguing the point.
Let’s take two examples.
Story Point Estimates
The best way to get into an argument on Twitter in the Agile community is to express an opinion on whether teams should estimate stories in Story Points, or indeed at all. Now, leaving aside the evidence that teams that do estimate bottom up tend to be more effective, and that that itself is likely a point in a maturity journey that subsequently leads away from estimating, when you’re looking from the perspective of half a dozen or more Agile Release Trains, each with around 100 people, it turns out: it doesn’t matter.
In particular, what doesn’t matter is the management/team standard argument of
How many story points can we expect to get done in the next Program Increment or Sprint time box, and what are you doing to increase this?. At that scale — assuming that we’re working towards a vision that a story is a handful or less days’ effort for the team (and ideally, a standard of one story: one acceptance test) — just counting stories is predictable enough.
In most large scale organisations, the economics of labour arbitrage and availability of skilled people form an inevitability. When you need 500+ engineers, you just can’t get enough skilled people at a competitive cost in most European and North American cities, so low cost locations in Eastern Europe, India, Costa Rica, China and other populous developing economies become hot spots for development centres.
Naive outsourcing and recruitment tends to optimise for apparent efficiency — building centres of excellence in each skill in one location and/or with one vendor.
As we develop our understanding that working in teams that have high levels of communication is far more effective, we build teams from those specialists, with the result that each team has devs in one timezone, testers in another, and Scrum Master & Product owner in a third.
However, viewed from the management of our larger deliver organisation, which still has all the same cost & people availability constraints, it’s far easier to move from the individual as the atomic unit of location (each person has of course to be based in one place) to the team, with some extension to the Release Train.
It becomes far easier, in fact, to work to a design principle of
Distributed Organisation; Co-located Team, and far, far easier if you need to move capacity between domains to move a whole team, stable working relationships intact, than try and pull together a new team based on individuals’ existing skills from across the organisation around the globe.
Viewed from that scale, mixing teams from across locations becomes incoherent noise. Aligning teams, locations and what they work on becomes Conway’s Law Coherent alignment.Recommend this post
Latest posts by Martin Burns (see all)
- Colocated Teams, Distributed Organisations - January 20, 2018
- Christmas Reading: 6 Books That Will Change Your Thinking - December 22, 2017
- Now Is Not The Time for #NoProjects - December 14, 2017