Companies spend a great deal of time and energy seeking to get their teams synchronized. Several forces motivate these efforts. It’s worth taking a second to look at these.
- One force: the belief that synchronization provides steering points. The notion here is that since we’ve just synchronized, now is a good time to react to the market and adjust the direction in which the project is headed.
- Second: the belief that no given team is able to do all the “vertical” work needed to accomplish some business goal, to go from silicon to screen and back again, with reasonable optimality, e.g. Turnaround time, excellence, safety, and so on. (This belief is often buttressed by actual organizational barriers. Most notably the horizontal layering of teams to resemble whatever horizontal layers exist in the app or its technologies.)
- Third: synchronization points give us an evaluation opportunity for the market, but they also give us one for the teams. It’s a convenient time for us to reward, spank, and re-org our team layouts.
- Fourth: sync points let us view longer term plans as composed of little segments that we morph into “work buckets”, which we can then “fill” and produce some sane estimate of when a large-scale deliverable might ship.
these beliefs, and some related others, seem to lend tremendous support to the idea of building software development teams around the central idea of synchronization mechanisms. The synchronization schemes form a widespread mainstream in the trade. They’re especially prevalent in vbca’s. There, they tend to go hand in hand with a variety of “standardization” efforts.
I contend that these synchronization ideas — writ especially large in the vbca world — create a tremendous net-negative impact on software development all over the world. They are not just not needed, but are actively counter-productive. I think they are wrong or wrong-headed.
I spend large amounts of time embedded in various “agile” organizations. Most of these are “scrum”. These orgs almost uniformly introduce sync points at 1) 1-2 weeks, 2) 12-16 weeks, and 3) 52 weeks.
– (note: those quotes are expressly an anti-invitation to discuss the myriad ways those orgs are not actually doing “real X” for any value of X in vicinity of the movement we share. I am bored of that conversation, and will require free scotch to bother to pretend otherwise.)
Let me offer a few points about this synchronization concept & its implementation in these orgs. Before I do, tho, I will make a statement that may trouble some listeners. That’s okay, it troubles me a little, too. But i’ll tell you now and u can decide whether storm off early. (1/2): i’ve spent 40 years in professional s/d, and 20 years embedded in the agile movement as a leader. I’ve worked in dozens of orgs, from ma & pa to fortune 10 companies, on every kind of s/w there is. I am coming from actual practice & experience. (2/2): and maybe that’s all there is to say. I cop to my well-known arrogance. Please don’t come at me with a textbook or a well-designed slide, your week-long class or your scant years doing the same thing in the same org. I just don’t have it in me today.
Okay, some points, for those of you tolerant enough to hang in this long.
**Point**: synchronization mechanisms are never free. By its nature — by its very definition — synchronization breaks flow. It introduces wait states and restart costs. Wait states are periods where we stop working because there’s not enough time left before synchronization for us to squeeze anything else in. Restarts are periods right after synchronization where we re-gather our focus and seek to re-find flow. If the syncing mechanism itself is expensive: I routinely see 1.5 days given over to syncing at 2 week intervals, one is easily giving 20, sometimes 25 percent of one’s productivity over to the mechanism. This is a staggering cost. We should make sure the benefit is worth it.
**Point**: the ideal site for steering a small team is any time they’ve finished one small piece of work, before they start another. One does this in a hierarchy by giving your direct reports larger-scale direction and leaving them to decide how/when to intervene inside their teams. This is not easy, which is why you are well-paid to do it. It requires trust in your directs, and patience in achieving whole-hierarchy change. But the thing is: steering isn’t *actually* achieved any other way. A syncing mechanism provides an “as if” model of steering, and if it were free and equally effective, that’d be fine. See the first point: it’s not just not free it’s quite expensive. You are paying a very great deal for the illusion of control. Is it worth it?
**Point**: verticality in team range, their free ability to operate in different technologies all up and down your code base, is wildly risky & inefficient only because we set things up that way.
- First, the geeks on your teams already wrestle with at least a dozen advanced technologies every day. They are hardly incapable of navigating across these. It is in fact their whole job.
- Second, there are far cheaper ways to protect yourself against a noob breaking what has gone before than banning them from changing it. What if u had very high certainty that this could almost never happen? You can. It’s called TDD. And in no way coincidentally, in addition to the defensive benefit of TDD, there are *huge* advantages provided by it to your more experienced geeks AND to your noobs, entirely aside from risk-mitigation.
**Point**: the whole reward/punish justification for sync points is foolish on a number of counts.
- First: reward/punish? You are ignoring the last 100 years of research into human motivation, likely quite disastrously so.
- Second: if u seek to reward/punish team on grounds other than their productive health, you can do that any time you like anyway.
- Third: there is no reason whatsoever to believe that measuring sync-to-sync productivity can be in any standardized or made viable for cross-team comparison. We have a ton of info that suggests otherwise, and almost none that backs this notion.
- Fourth, same-team different sync-period comparisons by numbers are almost as bad. Different teams wrestle with widely different degrees of difficulty from one sync period to the next. Dead-ends abound in our trade, as do false starts, as do even key individuals’ lives.
- Fifth: interrupting flow is itself usually a punishment, as is evaluation from people who are so far above you they have to evaluate you based on numbers that don’t capture your state.
I’ll say this again, please memorize it now: there are only two ways to assess the health of a software team just two: live with the team. Trust someone who lives with the team. That’s it. That’s all you got. If you can’t do one of those two things, you can’t assess their health.
**Point**: your longer term plans don’t work very well at all now, with all those sync points. How much worse could they actually be? Remember, you are *paying* for that sync, heavily.
**Further point**: using sync-periods as buckets is a whole category of foolishness separate from all the rest. It ignores every single thing we’ve learned about the real world of software development for fifty years. It is just a staggeringly costly and hurtful practical joke.
So? Lose it. Forget about sync points. They cost a fortune, they help little, they often hurt a lot. Focus on building unsynced systems that free intelligent trustworthy motivated people to do their best work. Oddly enough, they will.