We need to be both specialist and generalist

Dynamic is one of the nature of Agile - priority varies as needed, team member can take up different kind of tasks as the project sees fit. And to achieve this, everyone should possess a wide range of skills so that they are able to cover up one another.

For instance, during the initial stage where most of the time are spent on design, env setup, etc. This demand the team to functions like an architectural and engineering team.

When the foundation is up, dev begins and the team is becoming a development factory. Coding becomes the number one thing.

When it is approaching launch date, everyone is focusing more on polishing the deliverable - intense testing, user training are the job of focus.

I agree that in each sprint, these tasks should all be covered. We need to design stuff before we can code and test but what I am trying to say is. The proportion of such work shall never be constant. It's natural to spend more time on design initially instead of towards the launch day.

And by doing so, this brings benefits to the next activities - debug and support.

In the old days, when team are focused in a single area and communicate with others through API. When things went wrong, the issue will need to pass from one team to the other. What makes it worst is, each team member will focus on a particular part of the system and not knowing the rest. Identifying the right person to ask and awaiting the reply becomes a challenge. It us not surprising when this has to be repeated for a number of times before the cause is found.

But in the agile team, if everyone is able to do go through the system and perform initial inspection. This enable a much better response time.

Also, by knowing how the system works, this enable the team to think through while they code. They can identify what is possible to happen more easily.

Sounds too good to be true. The drawback of this is the difficulty in finding the right person and the cost of hiring them. But if u have a team like that, you can move on and endeavor much flexibly.

Cultural Differences

Agile, scrum, are all principle to get the teams proceed in a steady pace, with great visibility. We plan on what to do in a fixed period of time and re-prioritize things as needed.

But have been running like 6 sprints and yet, we don't see the steadiness expected. Team is working long hours, feeling stressful, cannot deliver quality deliverable.

Come to think of it, I have noticed the following.

1. We keep adding things to the originally planned task lists.

2. We take dead line as DEADLINE

3. Admitting mistake is shameful

Being a Chinese, we are not good at saying 'No' and especially when the request is coming from the boss. It is not a common thing in telling the boss that something cannot be done.

And we are reluctant to change, and enduring an ever changing requirement is something not in our culture. Personally, I disagree to reject things just because we don't want to take changes. Pushing back should only because what's working on is of higher importance.

Also, asking for help is like raising excuses, we don't see it proper to postpone when a mutual consent has been established.

Lastly, admitting mistake is shameful. Cover up, denial or finding excuses is more common. But then, this results in inaccurate judgement, especially on determining task completion.

There are also some simple thing which differs between Chinese and westerner. We take lunch quite seriously, we rarely skip lunch, or do a quick one. Eating an apple as lunch is not our style.

Getting scrum or agile to work for Chinese might need to tweak a few things but the most important thing of all, is to make people understand the principle and follow it religiously.

Code change shouldn't be horrible

Was having a discussion with a developer and came across a topic about code change. Since he is very new in developing java stuff, now after getting thru the jungle for half a year. He looks back and realize many stupid implementation.

He then told me something he learnt from another developer, who has been writing code for some years that if code works, don't fix it.

I am quite surprised when he mention the rationale. It is the risk that the changes might break what works is inhibiting him from doing changes.

I can't help but "educating" this budding developer at the spot. With unit testing framework so widely available, there is no other reason but laziness or unrealistic timeline that no unit test is written.

Automated build and unit tests are so crucial that it should be conducted across the team as early as possible. Once it is in place, all code changes will need to endure through the bunch of test cases, before it is allowed to get into trunk. It is all the little test case that aggregates help us to build the confidence of code change.

Stress

Stress - the urge or tension that we felt. We usually feel the stress when we have deadline to meet, or task that has zero tolerance of getting wrong.

Working under these constrain firstly results in a highly focused and very efficient work mode. But when the period of tense is prolonged, it's not only efficiency drops, but also the motivation gets diminished.

That's why setting realistic schedule and priority is so important. But they are usually skipped or poorly done. Lack of time and over ambitious are usually the cause. Ambitious, desire to be a hero or simply don't want to be looked down as obstacle are what leads to un-realistic schedule.

Be honest to oneself, and also to the decision are keys to reduce the un-necessary stress. Get the whole team involved instead of taking it all over by oneself, there's nothing must be done by YOU.

Riccardo Chailly and Leipzig

I am attending the concert by Chailly and Leipzig, playing Bruckner #8.

Last time I heard of Chailly's recording is almost 10 years ago, which didn't leave me with any good impression.

Tonight, I am totally drawn by him and the orchestra. To describe what I have heard, I made the following analogy.

The sound is,

As thick as syrup.
As elastic as rubber.
As clear as water.
As crisp as chips.
As light as feather.
As powerful as a bull.

I envy him so much, that he can enjoy music from such a decent orchestra at will. What's more, it is apparent that, no matter how much you invest into your audio setup, it won't come close to attending a live concert.

His interpretation of this piece is so intense, with tones of layering and superb clarity. All the transition are so smooth that you didn't realize the joint. All phrases are built up like tidal - come and go naturally. The orchestra can whisper so lightly but you won't feel blur while in forte, the can play like no limit.

Apart from the concert by Celibidache and Rattle, this one has already taken a place in my memorial hall.