Imagine two teams: The first (“Team Monica”) begins a project with a kickoff meeting, followed by meetings with stakeholders and subject-matter experts, and a recurring weekly meeting to discuss progress. The team creates various artifacts along the way: a project plan, process and procedure documents, wireframes and prototypes. Finally, after months of discussion and dozens (or hundreds) of pages of documentation, the team delivers its final product. Hopefully, it accomplishes its goals and satisfies stakeholders.
The other team (“Team Phoebe”) has an initial meeting to assign deliverables to each individual, then gets to work. With fewer meetings and less process, they are able to deliver much more quickly (weeks instead of months); with less up-front planning, however, there is some duplication of effort and inconsistency among deliverables.
Which team would you say is more effective?
If the teams are building something ephemeral (software, documentation, training content, etc.), as opposed to, say, a skyscraper, then count me squarely on Team Phoebe. Though its output may be less consistent, the team produces results much more quickly. Team Phoebe can produce a second iteration that incorporates feedback from actual users in less than time than it takes Team Monica to release version 1.0 (which will itself likely require revision; to paraphrase Helmuth von Moltke, “No plan survives contact with the enemy.”)
None of this is new, of course: In software development circles, there is decades-old tension between proponents of Waterfall and Agile methodologies; instructional designers have begun moving away from process-heavy ADDIE toward more iterative, learner-centered techniques. But the debate is far from settled; somehow I keep finding myself the lone Phoebe on a team of Monicas.
I recently came across this presentation by Justin Searls that resonates with me. The whole thing is good, but I especially enjoy the section in praise of small teams beginning around slide 65. Some highlights:
Consensus corrects for the team’s needs; feedback corrects for the users’ needs. Sadly, time spent gaining consensus costs you in feedback, because consensus and feedback compete for the same resources.
“How can we build something this big with a small team?” is exactly the wrong question. [We should be asking,] “How can we build something this small and start failing or succeeding?” If Small Thing™ is wildly successful, then the team can grow organically; if Small Thing™ is a spectacular failure, then at least it was a small thing.
How do you find a Small Thing? Simplify the idea so much that one person can build it.
That’s my dream: to be part of a team that empowers individuals to create Small Things without a lot of up-front process, gets them into the wild as quickly as possible, and incorporates user feedback to improve them over time. Who’s with me?
Leave a comment