2008-Jun-10 - Why attendances are absentminded in the meeting?

In some meetings, I found most of the team members were absentminded. I summarize the common ground of these meetings.

1. The meeting request is not sent in advance.
If meeting request is not sent at least 1 day before the meeting, attendances may have their own schedule for the day, and may not be comfortable to adjust it because of the sudden meeting, nor have time to get prepared for it.

2. The meeting does not begin on time.
If the meeting environment is not well prepared in advance, or the meeting is not started on time, attendances may be discouraged and have impact on focus during meeting.

3. The meeting host is the presenter.
Hence nobody control the presentation time and the content may be unconstrained.

4. The meeting does not end on time.
If the meeting time is out of control, attendances will probably feel loathing and start thinking about their own stuff.

5. The meeting background light is too dim.
If only the screen in front of the meeting room is flashing during the whole meeting, attendances may feel sleepy. So proper background light is very necessary.

2008-Apr-11 - Define Stage Feature List and 1st Iteration Kickoff

We held a workshop to determine the 1st stage feature list (SFL). Since our product manager is not at the same site as the development team, we decided to work out the SFL within the development team first, then send out to product manager for review.

What we did in the SFL workshop is like this:

The attendees of the workshop include developers, QAs, development manager, QA manager, project manager, and UI engineers.

First of all, we filter the categories of features in the full feature list (FFL) that would not be implemented in the 1st stage.

For the remaining categories, all of the attendees have to score each single feature by its implement priority - score 3 for high, 2 for medium, and 1 for low. At the same time anyone can give an explanation for why he scored that point. Each role stands from his point of view to decide the priority. And as a QA, we tried to figure out the simplest story that an end user can try out our service at once.

After going through all the features in FFL, we got a total priority score for each feature. Then we sorted them descendingly, and review the top 20 highest priority features to check whether they make sense.

Then we sent the list of features with priority order decided by development team to our product manager. To our surprise, his feedback was totally different from our feature list. The product manager focused more on the infrastructure and high availability stuff. So we combined his feedback and adjusted our SFL for the 1st stage. We focused on a more scalable structure and high availability, and only kept the simplest feature that user could use.

After decided the SFL, we kicked off the 1st iteration by starting estimating the 1st stage schedule. Here is how we did this:

The attendees are the same as SFL workshop except UI engineers because they were shared resources and would not be in critical path.

First of all, we separated 3 phases for each feature implementation - design / test environment preparation, coding and unit test / automation test coding, bug fixing / testing. You can see that each phase involves task for developer and QA. So we estimated the working hours for each phase of each feature in the SFL respectively by developer and QA. And we found the critical path. The sizing and time estimation was mainly based on experience, kind of intuitive and conservative though.
After that, we also assigned owners to each task, trying to balance all engineers' effort.
Of course, finally we added buffer time (about 20%) and the time for other stuffs such as full cycle test and regression test. 

And that's how we planned our 1st iteration.

2008-Mar-5 - Our 1st draft of Agile working model

Thanks for Michael's comment. And now we've worked out a draft of working model for our agile development. We will try it out, and refine it during practice.

In the graph above, FFL is for Full Feature List, SFL is for Stage Feature List, and TDD is for Test Driven Design.

Two inputs for FFL: new feature requirements from product owner, and user feedbacks.

For each iteration of development select a set of stage feature list.

Each iteration adopts TDD mentality.

After an iteration, it may or may not deliver a beta release. But no matter deliver it or not, the program is shippable after each iteration.

Currently we are entering the first iteration, meaning we will decide a stage feature list for the first stage shortly. We believe the first stage, or say iteration, would cost longer time, because we have to consider the whole architecture and scalability.

I may write another blog about how we prioritize and decide the first stage feature list.

2008-Feb-1 - New Year Resolution

For the job:

1. Learn to analyse the essential of a problem, or the root cause of an issue.

2. Do things with a plan. Evaluate the value of effort before doing it. (eg. automation)

3. Communicate to get clear about counterpart's expectation. Avoid over effort.

4. Work with the team, as a team. Take care about the gray areas where task owner is not clear.

Can I become more senior this year?

2008-Jan-26 - Making it Agile

To avoid becoming more and more conservative in releasing our product, the executives ordered that we introduced Agile mentality, and made our software development AGILE!

Well, before that, we do not have any clue about what Agile is, neither we have a successful agile pilot team. So we, the development group, started whitehanded.

Does it mean shorter schedule, no documentation, less test...?

After a couple of weeks of study and discussion, we found some difficulties in implementing Agile process (maybe it's not called a process for Agile) from our engineers' point of view. And the top 3 are:

1. Instant face to face communication among all stakeholders are not possible.

Because we are a transnational company, and the stakehoders, i.e. marketing team, development team, sales, tech writers, decision making managers, etc. are locating through out the world in different time zones.

2. Lack of senior, experienced engineers.

All developers and QAs in our team have only 2~5 years software development experiences. And nobody have ever involved in an agile team. 

3. Working model is not decided yet a new cycle of product development is on the road.

We have started our new version of product development, but how to work agile is still in discussion.

I will follow up what happen on our agile development in my coming blogs.