,
6 tweets,
2 min read
Read on Twitter
I’ve been thinking more and more that this piece by @rezendi is one of the better pieces written on software development management in the past year. /1
google.com/amp/s/techcrun…
google.com/amp/s/techcrun…
However, I needed to hear / think about the thesis slightly differently for it to really click with me, and so I thought it might be helpful for me to write down the slightly-different conceptualization here. 2/
In short; I think the most efficient transfer of specifications for software development (and here I am thinking only about front end, since that’s the majority of what we do) is to provide interactive mock-ups (e.g., Invision) and a clear high-level business narrative. 3/
In general, those are sufficient for acceptance. Breaking down the work into specific tickets that are of a certain size and each with specific acceptance criteria is unnecessary and inefficient. 4/
The only defense of such practice would have to be based in either necessary deadlines for coordination across teams (so we really need to know down to the day or four when something is ready), or if there is distrust that developers are actually doing their jobs. 5/
I increasingly see Amazon’s “two-pizza teams” as the best defense against either of those problems. And, combined with relentlessly downscoping project size, you have essentially the solution to JIRA. 6/
