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.
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.
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.