
-

-
Crawl, Walk, Run
I’ve come to feel it’s imperative to define a “vertical slice” for the project. By which I mean a nearly-shippable self-contained piece of content. Without that scope creeps up on you. Polish gets deferred. Suddenly a deadline is on the horizon and there’s not sufficient time to stabilize let alone polish. Furthermore, this will require cross-team integration which is always challenging.
You have to build the small, polished slice “right” once. It will take a great deal of effort. Many problems will be uncovered. Assumptions challenged. Then you do it a couple more times. Only at that point will you know enough about the problem space and have tooling & processes in place well enough to “go wide” on content.
-
Nothing beats that feeling when the code you’ve been puzzling over finally comes together.
-

-
On Tech Docs
When working in teams, tech docs are essential. Their goal is to uncover missed specs, invalid assumptions, broad architectural errors, if we’re actually prepared to build (i.e. can we speak credibly to what/how), and finally to reduce miscommunication between various teams/disciplines. In addition, they reduce miscommunication & misunderstanding between stakeholders.
I’ll add I think tech doc review is just as important as writing stuff down. In my experience it’s often done poorly. The doc should be ready ahead of time, sent to relevant people, read ahead of time, and a list of open questions and comments seeded before the meeting. The meeting should have a notetaker. The meeting should be shorter rather than longer. Have fewer people rather than more. The meeting should not be about reading the document top-to-bottom, but about answering open questions and confirming everyone is on the same page. The meeting should result in consensus that the team is ready to code and a list of tasks with estimates and owners.
You must be logged in to post a comment.