A twofer on software estimation that also tallies with my intuition. People are really great at estimating the median which is impossible to communicate to people without deep intuition for software engineering and statistics.
I enjoy James Stanier’s newsletter on engineering management a lot. This one is about information processing in organizations, something which will make or break you.
Thoroughness unpacked in three dimensions like this by James Stanier is so good and gives a much better way to think and talk about issues of velocity:
As somebody working in platform for the past years, I’ve become very familiar with the different dimensions of this debate around productivity and John here unpacks the topic in a way that’s really useful. I used the nails analogy just yesterday.
It’s understandable that organizations try to make their word legible and simplify things. In fact, it’s one of the reasons for the organizational boundary.
As a company scales, there are phase shifts which feel like they suck all the productivity out of an organization. The way to get through as described here is familiar: categorize and capture everything, reduce WIP and loop through your process.
A lot to like in this article (“They avoid scrum and SAFe like the plague.”) but I’ll settle for adopting the core thrust of it and just retiring the entire concept of a PO and never have to debate “What is the difference between a PM and a PO?” ever again.
The Engineering Enablement podcast has been good to listen to—if a bit anodyne. The recent episode I listened to with Jeremiah Lee about Spotify’s massively popular but failed org structure was really fun and useful.
A relevant and nuanced complication of agile by Dorian Taylor seeing it as a trauma based response where the core practice has gotten stuck and is preventing the industry from solving more fundamental issues.
People see this kind of talk about self-governance and think there is no process or management in such a setup while usually there is more (and higher quality) than in a traditional organization. It’s also some of the best work you will ever do.
Having seen lots of teams stuck in the two week agile rat race, a framework like Shape Up seems like it could offer a lot of benefits. But also just changing things up can’t hurt at that point. What is agility if not also being able to iterate on the way you work?
Lots of teams try to dogmatically implement scrum without looking at their team and goals. There are lots of alternative ways of doing things most of which will be more agile, not less.
Working in the Spotify organizational structure can be a bit tiresome but I’m glad we’re getting the important stuff from their product development culture, listed here by Jason Yip, right as well: aligned autonomy, trust and decoupling. Without those the structure indeed does not matter.
People leaving your team have a cost that is far far larger than what you can directly see (and we know what a challenge directing stuff that you can’t see is). These visualizations
by Benji Weber put forth a strong argument especially against people working as isolated individuals on things.
An entire article about speed vs. velocity vs. tempo that can be summarized as: “Orientation is the Schwerpunkt.” How much does your team invest into orienting themselves before they take on new work?
One of the things I have to fight the most for and that I think is what allows me to work well: “Regularly get in your team’s shoes”. Call it Genba, or Fingerspitzengefühl but the most important thing is to stay in touch with your team’s day to day reality.
I often get surprised reactions when I say that we don’t do Scrum. After reading about how other technology companies run their projects, it seems that Scrum—which is wasteful and does not fit reality—is on the way out.
Agile is setup as a bit of a straw man in this piece about scaling product delivery, but it is true that following the existing methods too rigidly will not get you where you want to be. I’d rephrase it to say that mature teams need to be able to reflect and create their own systems as they go.
A crucial part of effective teams is introducing slack like in this case removing the entire concept of a hand-off (which causes misalignment at best).
Most of my discussions with data scientists have revolved around exactly this point (usually to serious pushback): that they need to be end-to-end to deliver value in an organization.
The JIRA team does not use JIRA and of course why would they if anybody gave them the choice. Also, JIRA is often not used for software engineering anymore but it fits the bill for large scale workflows and compliance trails.
Edge C2 is a nice ideal position to move towards in this article about military agility that contains a bunch of useful elements including an interlinked OODA loop and a visualization of the Trust Equation.
As a bystander you can observe a retrospective and hope to see some of these symptoms listed by Adrian Howard of a good one. But keep in mind that you should be happy to hit some of these and getting all of them right probably means you have reached the summum of team work.
One of the points in this list by Paul Osman that I recently stumbled on is that things like “staging”are indeed mostly useless however much people want to keep using them.
A long treatment of how to scale work as organizations grow with some helpful guidelines: “Keep the work parallel, the groups small, and the resources local.”
Such a well-written and cogent argument by Dave Mangot about how it definitely does matter whether you choose to deploy on Fridays or not and also that that choice is fully your own.
Always nice to read a positive career history from somebody, like this one by Alicia Hickey, but especially nice if you’re in it named as the team lead who made a crucial suggestion.
Marty Cagan’s piece on product vs. feature teams yielded more than enough stuff to reflect on and discuss. I wouldn’t mind having a ‘true‘ product manager. Where do you get one of those?
Reading Shopify’s approach to keeping their merchant’s secure at their humongous scale seems to come down to the radical standardization of everything. People think this is boring (it isn’t) but it has tons of benefits beyond just security.
One good example with an open sourced tool over at Slack of how they’ve implemented their Security Development Lifecycle to enable their developers to move forward confidently.
The manifesto to choose boring technology in order to be able to solve interesting problems is something to (re-)read regularly until you’ve internalized it.