April 15, 2008

Doing Breadth-First

The_Big_Picture_2If you are starting on some new project, and your role needs you to define and prioritize requirements for a product, taking the "Breadth-First Approach" makes a lot of sense.

Getting to know the overall scope of your system should be the first target. Formulating accurate scope could get tricky at times. However, the first few questions that you should ask (to anyone else who knows even a bit more) must include:

1. Who are we doing this for? Look for proper nouns.
2. Which two main problems will our system solve?
3. Who is paying for this?
4. What is the release schedule?
5. What are the risks (as of now) and external dependencies?
6. Is someone else also doing similar work? (inside or outside your organization)

If the project is already underway, you may want to look at some inception stage sketches. If the project however is relatively young, you should draw those yourself. At some point, this effort must incorporate some kind of a conceptual domain model.
The next thing that you must think about is how would agile methodology scale to adjust with your team and the size of your product. And no one at any stage shall forget that along with the promise of delivering value pretty early, agile processes are also designed for the team to learn how to deliver value more effectively and efficiently.

Lastly, if you are much involved in capturing requirements or selling the product, you should always start to prepare (and even rehearse) your elevator pitch. You must have crystal clear, and unambiguous answers for: who you are, what you do, and why you do it better.

And finally today, I leave you with a quote that quite well summarizes the entire agile philosophy:
It’s never the size of the step that a person takes that counts, but its direction.
--Narrative Means to Therapeutic Ends, Michael White & David Epston

April 1, 2008

Of Screencasts

If you have to show-off a new cool feature to customers without having them to download or install stuff, do a screencast.

If you need to popularize a new tool that you are using and find useful, do a screencast.

If you just prepared a new mock-up and wish to communicate it and it's purpose to your team, without collecting all of them in a room, do a screencast.

If you have a new slide-set that you'd want the readers to 'understand' and not just 'read', do a screencast.

If you wish to teach others on how to install, configure and use your product, without asking them to read through the lengthy manual, do a screencast.

In any successful project, intra-team communication is of utmost importance. And when you have globally distributed teams with time differences, it is more suitable at times to do a screencast and convey your point rather than wait for mutual free slots and discuss over telecon.
Often, putting across tutorials or new ideas in video attracts more and wider attention. And yes, voice narration is a certain cure for ambiguity.

One of the best tools in the market for producing screencasts is Camtasia Studio. A complete list of tools is here.

And here are some examples of good screencasting.