2009-Feb-28 - New start in a big pond

 It's been 3 months now since I joined a new company. I’m still getting used to it. I mean, there are so many differences between working as a QA in an SMB like my previous company, and a huge enterprise like my current employer.

1. New hire guidance

In my previous company, which is much smaller, they are able to provide a clear list of “What to do” for new hire, like whom you should contact if you are in some situation, or where you can seek help when you are in some another situation.

My current employer provided a first day orientation, which propagandized company culture, and gave us a website, which surely contains all the information we need yet it’s too huge. My direct manager did most of the other orientation job afterwards, but some information he provided was either outdated or conflicted with what HR said later. I was confused sometimes, trying hard to figure them out myself.

2. Organization

My previous company is simpler, from director, to XXX managers, to developers and QA engineers, straightforward, and people know each other. One RD team works on one project, developers program and QAs test.

My current employer is much more complicated. Different kinds of teams, different kinds of roles, even QA has several categories, focusing on different kinds of testing on the same project. I always wonder if we will miss anything in the cracks between these QA teams. 

3. Process

The previous company has an SQA team that supervises the product development cycle to make sure it adheres to process. They involve in requirement review, design review, plan review, and then after release, they analyze the testing data and do postmortem.

Now we do not have this kind of force in my company. We are working on many small releases of old products, and have short time span and not very strict process. No hard test coverage requirement, how many tests to do depend on QA’s experience and developer’s suggestion. Bug priority at 3 or lower are sometimes ignored, and product goes on releasing. Usability, UI, comprehensive messages are not a bit in consideration. Nobody cares about that because there are so many projects on one’s hand at the same time.

4. Culture

In my previous small company, employees’ race, age, experience, and even character are close. We worked together, played games together, and even rent an apartment and lived together. It’s pretty simple, and people like each other.

In a big old company like the one I’m in today, we have so many colleagues from different countries, in different age, and have different experiences. People do not hang out a lot after work. They don’t see each other even working on the same floor. They prefer conference call than physical show up. In a team meeting, if one’s not aggressive enough, he would have no chance to chip in, because there always are talkative members out there that really show they are involved.

The good thing is, in a big company, you always have something new to learn, either from projects, or from the coworkers.

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?