Oct 31, 2005 / Optimal Team Size

0 comments

Not a fresh article, but prove that performance in small teams better than in large teams. According this article, optimal team size is 3-7 people, which is very close to reality on my opinion. I personally prefer teams of 3-5 people, since communication is very good and it is very easy to keep things on track, so everyone can focus on real tasks and add real value to product.

And if you ask me would I add a developer in a team to meet a deadline that will be within 2 months, I will say no. Being on status meetings, I so often seen how PM asked resource manager about one more man to complete project on time, and then they failed anyway (usually in quality).

So keep teams small and constant. It is hard, but it is one of the best thing you could do for project success.

posted by Michael Dubakov @ 5:24 AM

Oct 18, 2005 / User Interface Tips

0 comments

We are thinking about TargetProcess v2.0 UI and digging the web to get new ideas and build something incredibly simple. So some relevant links that will be helpful for anyone who build user interface:

Natural Selections: Colors Found in Nature and Interface Design
Why colors from nature better than standard safe web palette. "“Nature’s colors are familiar and have a widely accepted harmony."

The Pursuit of Interface Design Simplicity
How to focus on simple interface. "“It is simplicity that is difficult to make."

The Yellow Fade Technique
How to show user what changed on the page. Useful for Ajax-based pages.

Web Application Form Design Form Help Without Popups How to design usable forms.

posted by Michael Dubakov @ 6:18 AM

Oct 17, 2005 / Agile Features Prioritization

2 comments

It is not easy to set business value for features in product development. There is no single customer, but many customers. And there are several people in the team who play "product manager" role (in TargetProcess all of us play this role in fact).

We are starting development of next generation TargetProcess software and have about 60 high-level features/ideas. Does not matter how we got them. Well, this is maybe interesting, but this post is about prioritization. So it is required to find a good and simple way to manage priorities.

We wrote down all features on index cards. I should say that "feature" is not a "user story". For example, we have features like "Bug Tracking Practice Support", "Acceptance Testing Integration", "Agile Project Planning" and so on. In fact "Bug Tracking Practice Support" should be splitted on 10-20 user stories in our case. Feature is something high level.

Then we sat together, make some coffee and started Agile Features Prioritization Session. I put card, read feature and we discussed it a little if some thought or questions appeared. If not, we vote for it. Voting system is very simple. There are three choices: Critical, Important, Useful.

• Critical means that TargetProcess should not be released without this feature. Nobody will buy it or this feature affects almost all customers.
• Important means that feature is requested by some customers or it will be useful for quite many customers, but software can live without it sometime.
• Useful means that feature is just nice to have, no more.

Also we have threw away some index cards with features that nobody wants to include into the product. For example, nobody wanted to have "What-If Analysis" for project planning and nobody wanted to deal with "AJAX-based Instant Messaging".

I wrote all votes on index card, took another one and so on. In two hours we have all our features voted. It was time to count votes. And it is the most interesting part. If you treat votes in natural way: 1 point (useful), 2 points (important) and 3 points (critical), you will have a problem: some really good features may appear near the end of the list. Why? Our team consists of four people, they have different thoughts and some clever ideas will be just buried. For example, let's take three fairly interesting features: "HelpDesk integration", "Acceptance Tests" and "Bug Tracking". Votes we had:

1. HelpDesk integration - Us, Us, Us, Cr = 6
2. Acceptance Tests - Us, Us, Im, Im = 6
3. Bug Tracking - Im, Cr, Cr, Cr = 11

First, absolutely required feature does not differ from least required (from the list above), and there may be a feeling that prioritization is not very reliable. Second, which one of the first two features should we choose? HelpDesk or Acceptance Testing? They looks like equal, but this is not true. One guy thinks that HelpDesk in critical for TargetProcess and he has a point. We are all smart, but have different opinions on some areas. And this is great, but each persons ideas should be taken seriously if he thinks that his idea is really great. If we average all we will release average product without killer features that solve some really great problems. But we have to have one list of features. And this list should be prioritized.

Solution is simple. We've multiplied critical vote on 9, important on 3 and useful on 1. Result:

1. HelpDesk integration - 12
2. Acceptance Tests - 8
3. Bug Tracking - 30

Now it is obvious that Bug Tracking is essential, Help Desk is worth to implement somewhere in the middle and Acceptance Tests will be added later if time. Each critical vote is very important. This is individual opinion that should not be lost under average mass.

In the end we have all high level features prioritized within 3 hours. Then we sorted them on three groups. First group is a Core - all features with 24 more points. Only 15 index cards honored with this group. The second group is a Features Mass, it contains about 18 very useful but not mandatory features with points between 10-24. And the third group is a Heap with 20 nice to have features (many of them will never be implemented).

After the session we knew pretty good on what we should work first. Core features has been assigned on different team members and each team member should think about them in-depth. It is a real kick start, without prioritization you are on the crossroad, but after it you know your way.

posted by Michael Dubakov @ 5:21 AM

Oct 5, 2005 / What Is Web 2.0: Summary

1 comments

In his great article Tim O'Reilly summarizes information and thoughts about Web 2.0. How it differ from Web 1.0, what is the basis of Web 2.0, what the technologies and main characteristics. Worth to read.

posted by Michael Dubakov @ 6:08 AM