To define the boundaries for our agile project, we need to define the scope. To provide a guiding framework for the rest of the work, we need to document the vision. We could create heavy-weight scope documents and vision documents. And we could run them through reviews and get approvals and wordsmith them to death.
But we won’t. Agile processes are about documenting enough, not documenting for the sake of documenting. This is a small project with an even smaller team (one person right now – but that will grow as people start helping out). An informal documentation style will be sufficient. The key element is to have something referenceable and mutable. If we can’t change the scope or the vision based on market feedback, we aren’t being agile.
These two project management artifacts seem logical to combine into a single article
Vision Document
Create a site that allows people in our niche to help each other find great articles, regardless of who wrote them. People will identify and evaluate (rate/review/score) articles on their merits. People will also categorize (taxonomy/folksonomy) the articles to make it easier for others to find documents that they are looking for at that time. When a person is searching in our space for an article, it is either as a beginner or an expert (on that subtopic). This site should help people filter to look for articles appropriate for the type of search they are doing at that time.
[Update 26 Apr 2007: We’ve updated the vision for the project – the update is included below]
Using the language described in Gene Smith’s Social Software Building Blocks (http://nform.ca/publications/social-software-building-block), we want to focus on sharing and reputation, while incorporating elements of identity, conversations, and relationships. We do not want to focus features on groups or presence. The diagram for our site would therefore look like the following:
Scope
In this project, we talk a lot about “our space” and “our niche.” Our niche is intended to be articles about:
- product management
- business analysis
- requirements definition and management
- business rule definition and management
- business process modeling
- agile processes
- interaction design
In terms of functionality, our scope is limited to improving everyone’s ability to find great content in our niche. That might mean making it easy for authors to tell people about articles, but more intentional is the ability for people to highlight great articles for each other. The scope is not intended to provide a mechanism for people to content. People should be able to indicate some assessment of the content – not just an unadorned link to the content. That may mean ratings, reviews, comments, thumbs up/down, etc.
In terms of deployment, this project will be a “self contained website” that is intended to be deployed into a subfolder at Tyner Blain ( http://tynerblain.com/folder/ ). We may elect to deploy it somewhere else (like a subdomain, or a separate TLD).
Hi Scott
Can I suggest a feature that let’s people recommend to a friend/friends via email (and maybe other features)
I agree that combining the scope and vision document helps simplify the process.
Great start!
Craig – Awesome idea. Yes you can. I’ll include it with other feature ideas for prioritization.
Aaron – thanks!
Hi,
may I suggest to add “help the website’s users in organising their own ‘knowledge repository'” to the vision.
I don’t find a better word for this. I don’t think of something non-public. An individual user should not just contribute for the sake of others (like suggesting a great article, which means he has alread read it), but should also be able to use it personally. I have no idea how to do it, but that’s a good thing when talking about visions :-)
I am aware that the community does something for the individual, and that the individual is part of the community. Some parallel could be del.icio.us, were the user benefits from his own favorites, as well as from other people’s favorites.
Another thought to include or explicitly exclude from scope: “Collaborate with other users for achieving an individual goal”, with goal meaning something like an industry project. Maybe this is already excluded by the idea that users do things on the site for all other users, and with the help of all other users.
Rolf – great contributions!
On “knowledge repostitory management” – it is a tough one. Del.icio.us, as you point out, is a pretty great tool for doing that right now. I don’t think we would have a lot of success if we asked people to duplicate what they already do there. That leaves two choices – either try and supplant delicious as the “organizational tool”, or find a way to leverage/augment/mashup with delicious so that people can use delicious as their primary tool, and achieve some benefit here.
Personally, I would want to keep using delicious, because I also organize other stuff as part of my “Sehlhorst Body of Knowledge” [SBoK :)]. And much of that doesn’t apply to our space. It might be CSS styling or Ruby on Rails programming techniques, or road-biking articles, or great recipes.
And with that need happily sated, I wouldn’t want to split it out so that I have separate repositories for my SBoK. What I do want to do is to be able to leverage the SBoK work I do at delicious (when appropriate) to help everyone else on this site.
So I would categorize the approach as “leverage existing BoK tools to make it easy to share relevant content with the community.” I think that falls under the current “broad vision” statement, and would ask you to make sure I don’t forget about this as part of the use cases we define. Then we can prioritize the approach.
Another way someone might do this is to create a personal wiki, and link to the articles that they like and find through the site. We may be able to find a way to make that easier too – but I think of it as a “second order problem” right now. I do want to use the feedback from everyone here to prioritize this approach properly – if it is more important then we will definitely tackle it.
Rolf – on the “collaborate to achieve a goal” idea, I’m not sure I completely understand what you mean. Can you give an example or two?
In my head, and possibly not in the language I used, this site is about collaboration. Maybe a tangible (however hypothetical) example or two would help me understand better what you’re explaining.
“collaborate to achieve a goal” – tough one.
First, I intended to stress “goal”.
I thought of APR as an endeavor to help people in our niche “in general”, i.e. NOT something like ProjectSpace or TeamSpace where people share a space that supports project work. Maybe “non-project” is the right track. Of course people share knowledge for and collaborate in achieving their goals – which includes projects, but they do not connect or collaborate using APR to do a (commercial) project.
IOW, APR should (also) be used like tyner blain is used now, as a set of knowledge units for our niche, not for a specific purpose with one or more goals to achieve by date x. (in my head that is a characteristic of a commercial project: achieve goal x in time y).
To make a long story short I suggest to EXCLUDE approaches like ProjectSpace or TeamSpace from the APR scope.
Got it! Yes, I agree – completely exclude “project goal focused” collaboration approaches, but rather have a “knowledge finding” goal that can be used for projects, exactly as you said.