New Player

Listen to internet radio with Film Festival Radio on BlogTalkRadio

Read More

Testing old player

Listen to internet radio with FreedomizerRadio on Blog Talk Radio

Read More

Balancing act

There is a great paragraph in a novel by John Patterson "Suzanne's diary for Nicholas":

Imagine life is a game where you are juggling five balls. The balls are called work, family, health and integrity. And you are keeping all of them in the air. But one day you finally come to understand that work is a rubber ball. If you drop it, it will bounce back. The other four balls-family, health, friends, integrity-are made of glass. If you drop one of these, it will e irrevocably scuffed, nicked, perhaps even shattered.

Read More

UX Elements

UX Design Elements (Jesse James Garett, 2000).


The UX Deisgn Elements book is a great starting point for everyone who is interested in UX design.
I highly recommend it for developers to read, because it will give them better appreciation of what designers think about before they hand them the requirements.

A good visual design always needs to start with understanding the site objectives and user needs. What do your users need? What is your site trying to achieve?

Then, functional specs need to be written summarizing what features the website should have. I like using MOSCOW approach for functional specifications. M = must, S = should, C = could, W = would. When you prioritize each feature, you can easily iterate and build only the Ms first.

The next layer is the Information Architecture layer where you define your site's goals and collect clients or coworkers' opinion about that.

Next is the design of navigation, wireframing, etc.

Finally, you wrap all of this up and produce a finished visual design.

Read More

3 types of factors which startups seek to learn to establish product-market fit

A good table outlining important factors that evolve through learning for startups as they seek to establish product-market fit.   This is from an article by Mark Leslie and Charles Holloway "The enterprise sales learning curve".

Product Development	Marketing	Sales
Completeness Features and Functions Interface to Existing Ecosystem Ease of Installation Correctness Value to Customers Reliability Serviceability Fit Ease of Use Suitability for Environment	Positioning Competitive Analysis Market Segmentation Marketing Messages Proof of Value Proposition (ROI) Packaging Promotion Collateral Materials Advertising, shows and PR Customer Success Cases Pricing Across Market Segments Across Channels	Channels of Distribution Number and Type Channel Support and Training Sales Force Sales Model Sales Pitch Training and Development Lead Generation Technical Support Sales Stage Learning Development Expansion

Read More

Testing our new Blogtalkradio offsite player

Listen to internet radio with Film Festival Radio on BlogTalkRadio

Read More

Self-organization and 'swarming developers'

At Cinchcast Tech, we spend a lot of time thinking about how to improve our development processes. One adjustment that our Director of PMO extraordinnaire Dan Alcalde have made to our scrum process is to use 'swarming'.

In swarming, a group aggregates together working on a same task,  just like a swarm of birds migrates in a particular direction.   For bigger tasks, instead of assigning the task to an individual developer, we have an entire team work on it. These big tasks can often be broken into smaller pieces. Also, a definition of Done for large tasks can be fairly extensive -- not only does the code need to be written, but documentation needs to be presented, unit tests developed, and demos given to stakeholders. In the past, when a single developer worked on a large feature during a sprint, he'd run out of time and skim on unit tests on documentation. By having an entire team develop a feature, each member of a team can keep the other member in check,  do pair programming, and share the architectural knowledge.

The other technique we use is 'self-organizing teams', where teams form on an ad-hoc basis. Instead of assigning specific tasks to individual developers, we let each developer choose which task he wants to work on.   When a developer finishes his tasks, he is free to select more tasks to work on (although nobody forces him to do so).  Peer pressure enforces people to keep up with their team mates, and everybody knows how much everyone delivers.

To be fair, swarming mostly works for large tasks.
1. There needs to be a clear definition of Done that everyone adheres to
2. The user story needs to be complex enough.

For smaller tasks, we continue assigning them to individual developers and not being overly strict about when a task is considered Done.

Read More

Team Building and a Scavenger Hunt

If you count the number of hours you spend at work, talking about work, thinking about work, and decompressing after work - it probably adds up to 75% of your life.  A key focus for me as a CTO is to make sure that people enjoy the work environment (and hence become more productive). Another key focus is - as the Cinchcast Tech team grows - to improve communication between various groups comprising it (IT, Engineering, QA, Telephony, Design, Product, HelpDesk).

We decided that it would be a good idea to get the Tech team out of the office into a casual environment, where the main focus was to have fun. So earlier today we took to the streets in a photo scavenger hunt (http://cityhunt.org) . The team had to run through the New York city, looking for clues, and following the directions.  It was a friendly competition, where creativity and good team-work mattered. In the end, everyone felt they built better bonds with their coworkers, which will make everyone more efficient.

Pictures (cross-posted from our Tech blog http://tech.cinchcast.com):

Read More