This is a loose follow up to my post on cyberculture and levels of success, but talks more about becoming successful at your craft. Whatever that is: writing, knitting, designing, photography, developing software, and so forth.
I’ve learned about agile/iterative development from software developers and hackers, from working with them, and watching them work, and while there are some who are much more religious about agile than I am, (certainly) I think there’s a lot of useful though here, and as someone interested in process/workflows and collaboration, I find it interesting.
Here are the most salient tenets.
Agile suggests that all processes are iterative, that you build something, submit it for review, gather feedback and then build another version of it, responding to feedback, implementing the next thing that needs to be implemented, fixing problems with the previous implementations until the next review. This is opposed to other methodologies where design precedes and guides implementation.
Agile values working prototypes, which can be reviewed. Having something as a prototype that can then be iterated is a prerequisite for Agile. Holding half finished works under your hat makes it really hard to get feedback, and therefore improve the work and respond to customer/audience needs
Iterative processes are understood to be ongoing and always in progress.
(Some strands of) agile eschew “premature optimization,” and suggests that the quickest, dirtiest solution to a problem is often “better” than the really clever, involved solutions that attempt to foresee future challenges particularly when the argument for the clever solutions is speed and performance related. The theory is that it’s hard to plan for the future case because it hasn’t happened yet, and it might change when and if it does happen. Furthermore, given the iterative process and emphasis on refactoring (editing and tightening the product), optimization and clever designs don’t make much sense.
So what does this mean for success? For people who aren’t programmers? When design is about designing a sweater rather than designing an algorithm? When refactoring and optimization are about writing clear, coherent, and polished prose, rather than efficient code?
One of the arguments, I think, for agile is that it’s “lean,” there isn’t a lot of overhead, and it works really well for small teams. Well, content producers, knitters, podcasters, bloggers, writers, and so forth generally work independently or in small teams. Lean methods and approaches are needed. Another leading argument for agile is that it’s more nimble with regards to how producers (developers) interact and shape their work in relation to the needs and tastes of the consumers (clients). On the internet, feedback and pleasing the crowd is really the key to success.
So what are the specific lessons to be learned:
Pay attention to feedback, and incorporate these suggestion into your work. Both as you edit work, but also as you work on “next itteration,” (design, essay, program, version, edition)
Iterate. Make something, and see how it works, collect feedback, and incorporate feedback into subsequent editions and projects
Create working prototypes, and fill in the blanks later. It’s more important that your novel have a beginning, middle, and end, then it is for every word in the first three chapters to be
Don’t polish till you’re ready. Given that “refactoring” and editing isn’t sexy or “fun” (usually, compared to making), it’s easy to talk yourself into writing polished prose/writing a technically perfect patter/etc the first time out of the gate, but you’ll loose time, and it might turn out that you spent a lot of time making something perfect that is destined to be dropped on the floor.
And that’s more or less the process of improvement seems to work. Online and anywhere, I guess. Reaching “the next level of competence” is a result of a sequence of iterations leading to that next level. The instructions on how to get to the next level are always, “keep doing awesome things,” “keep improving,” and “keep experimenting,” mostly because there aren’t any real “levels” when you’re working. There’s improvement, there’s progress, there are even milestones, but those are–almost always–judgments that are external to the “work,” rather than intrinsic in the work.
I have a few more little entries in this series before I wrap things up. I hope you’re finding these posts as useful as I am.
tycho garen 06 August 2009