5 comments

[ 2.3 ms ] story [ 12.7 ms ] thread
I think the author mixes up a few "start-up" concepts (MVP, failing fast, etc.) with "agile" concepts (people over process, early delivery, etc.) and therefore is kind of shooting all over the place. I'm not going to argue that scrum is somehow not "true agile" (by definition, agile-or-not is entirely driven by the context of the team), but there's definitely a few points of warning in the Studio model proposed:

* a single architect / visionary to provide the "creative direction" within a project is a huge bottleneck. It's possible for showrunners to get down into the weeds of the scars on Orc's faces on a fantasy show; for a large software architect to get into the mechanics of on-disk data format is obviously failure. Filming is short sprints of hard deadlines in a way software development simply isn't.

* "magic happens about 85% or more": eek. Have we not learned that long periods of development with nothing visible are dangerous?

There's lots in here that I agree with; some of it seems a bit self-contradictory (i.e. "we need redundancy / understudies at all levels" versus "hire and level up creative people"), but overall this just reads like another list of "here's a lot of stuff that often goes wrong. My manifesto is to not do that". It's not amazingly actionable.

I didn’t entirely agree with the original author either; the comments on MVP also jarred a little with me. That said, the two points you mentioned in your bullet points both resonated with me.

I do agree with the original author that software development needs a clear vision of what you’re trying to achieve. Without someone to articulate that vision and then everyone working to realise it, it is easy to fall into a trap where lots is going on and yet there is little useful progress being made. What you characterise here as a bottleneck, I might characterise as having focus. This is very much about the big picture and co-ordinating different contributions, though, not about micro-management.

I also have a lot of sympathy with the argument that software projects don’t necessarily add value incrementally just because the code is being developed incrementally. To borrow the traditional bad car analogy, you can have the most ergonomic steering wheel ever designed and you can put the best performing tyres on your rims, but until you’ve connected them, the value of the overall product is still negligible.

Of course software is different in nature to a physical product, but I still think the critical point in the development process — where you have not just evidence of product-market fit and potential market but a sustainable offering that you can actually sell in large enough volumes or at a high enough price to justify the development — is often only reached towards the end of a major round of development work. Visibility of incremental progress towards that point might be reassuring and motivating, but neither of those is the same as having value as a deliverable product. So while I’m all for manageable, incremental, sustainably paced development, I do think there is a real world danger of emphasising that too much and consequently taking an unnecessarily circuitous route to the critical point, making the development slower and more expensive than it could have been.

All the points he made about design up-front I'm entirely on board with: obviously it's difficult to say how much is necessary / right / overkill, but you definitely want to think about what you're building.

TV/film/studios as a model don't offer a particularly compelling vision (to me, anyway). Games work a lot like that, and I think they're probably some of the worst development jobs you can have (as a rule).

Yes, the “studio” terminology also seems a slightly awkward fit here. There were some good points made, but I’m not sure it’s the best analogy.