Weekend Reading – 2/11/2018

The John Cutler Section

In a shocking turn of events, John had no written articles this week. He did post a video, Tetris, Queues, Dependencies, and Flow of Value on Vimeo. It’s not a “you have this problem and here’s the solution” kind of thing, it’s more of a “I’m going to make you think about what’s going on and only warn you of some potential pitfalls” thing. John wrote about Tetris style planning in Stop Playing Tetris (With Teams, Sprints, Projects, and Individuals). He also make a case for regular refactoring / debt workdown. with a nice graphic posted to Twitter.


I’m not sure if Frank Chimero’s Everything Easy is Hard Again essay is lighting the internet on fire, but it really did resonate with me as a former web developer. Sure, it can read like an Old Man Yells at Cloud rant, but we continually see this pattern in (and outside of) technology. We are still in an era where web development technologies is rapidly innovating. Everything is changing faster than any one person could possibly keep up with. To do anything meaningful you need a team of people that have specialized in a number of areas…that is if you want to roll your own. The number of services that can provide you with really fantastic web sites is mind boggling. But I feel you, Frank, it’s crazy out there but the only constant is change.


Full utilization and whitespace by Manuel Gomes builds on the ask to stop playing Tetris with your planning. Why is planning Tetris an anti-pattern for software? “Software is an uncertain medium.” You don’t remove waste from software development in exactly the same ways when you’re producing physical widgets. We have to keep repeating this to ourselves.

So, if Tetris is an anti-pattern, what’s a good pattern? Everybody reporting success is talking about “small” teams with as few dependencies as possible. Joshua Kerievsky, a leader in the Modern Agile community, wrote on LinkedIn about this in the article Size Teams for Few To No Handoffs. I really like this article because it reminds you not to just copy something from Amazon (the infamous two pizza team thing), but to look at what you have to work with and make the best decisions for your teams. Guidelines, not rules.

Do you want to keep digging into the how and why of these kinds of teams? Great! Your Team is Smarter Than You Are: Why Autonomous Product Teams Work Better from Martin Eriksson is a great read.

Now a lot of people hear autonomy and think of chaos or anarchy. They think that it means everyone can do whatever they want, build whatever they want, and come and go as they please.

But the key to successful autonomous product teams is to do it with accountability.

How do you do accountability? You can use Objectives and Key Results (OKRs), but it turns out that’s hard as well, as Jeff Gothelf writes about in You suck at OKRs.. The good news is that Jeff and friends have some advice for not sucking at OKRs.


Sign up at Tinyletter to get these words delivered to your email address of choice!