Simplepath Inc.

After a very lovely and fruitful conversation with one of my Collective Leaders (uh, don’t know what else to call them, actually), it dawned on me that maybe, maybe, the way I need to work is not to massively drag myself through the documentation process, and make it all pretty, and readable and such is that I let it trickle out…dribs and drabs at a time, when it’s relevant. Of course, I need to do all the thinking, and planning beforehand, but maybe I don’t need to have it all “finished” when the features get into development. Only the features that the dev team is going to be working on in the next two weeks, maybe that’s enough. Huh - total head shake.

Caveat: only for teams trying to do a weird-ass version of Agile, but trying to have some direction when they plan their sprints, I guess.

Truism (from what I know): developers typically don’t read documentation beforehand (or, um, ever). Why should they? Do I? (um, yes, but I’m weird that way).

Me (with newthinkTM): next week, when we start discussing a pretty big concept, I will stay at the big level, talk about the overall site and user and business goals, and NOT walk through tons of wireframes, which everyone is only half-listening to at any rate. Then prepare the minutiae (sp?) for what I think/hope will be scheduled in the next two weeks, to work on. Like the boring wireframes (don’t get me wrong, I KNOW they’re boring, and I wish to god they came with singing and dancing and a lighting spectacle, but they don’t) and the business rules, and the constraints and all that stuff.

Context is king: if I can provide what the developers need (after all, they are my first users, of the docs), in context, then maybe the docs will be more meaningful.

It’s quite a change for me, going from “here’s everything” to “here’s a digestible piece”, but I am going to do my best to respond.

It might even help our clients, to see the progression from discussion to wireframe to live functionality, quickly.

It’s a bumpy road, but I think that I serve three sets of users: end-users, business owners who want to see project progression, and developer users who need just-in-time docs (and even, not too many of them…just enough).

Wish me luck.