Drawback that you might not aware in crashing your schedule

Typical scenario - you have a handful of features but your team can only finish part of them, now you want them to work overtime to do them all.

We all have this desire and probably have experienced this. You should have heard about the different draw back, like decline in quality, and a drop in morale. But there's one thing you might not aware.

Upon finishing your tasks, your team will get through a period of procrastination.

Why? They are paying the debt that have loan, just like the oxygen debt that build up through exercise. Your team will feel they have already done a lot and "deserved" to laid back a bit, to regain the momentum before marching forward for the new tasks. And this is the problem, the laid back usually drags on, and even when they can ramp up to move forward, they need time to get back to the momentum.

Thus, try to avoid the temptation to sprint. Keep the pace that your team that feels comfortable, and you can get a more consistent focus factor for each iteration.

Why you should buffer an additional day in your current project schedule

Someone call it an iteration, someone call it a milestone. Whatever it is named, it means the period of time for a cycle of software development.

The pace of development and the granularity of task in a project affects the duration of each cycle. Thus, the duration of a cycle may varies among different team and different projects. But for easier manipulation, one month or two months is the duration of time that will be adopted mostly.

I am sure you have read a lot of articles on how to structure the work into each cycle. But one thing I want to share with you is, reserve a day for packaging of your deliverable. If you are like me, who demand a release of the development that is capable to execute either a fraction or a complete set of functions at the end of each cycle, it is better to reserve a day for the team to tidy up their work and prepare for the release.

In my team, the deliverable for each release will include all or selection of the followings,

• release notes (text file or an additional entry on the product web page)


• change log


• binary (e.g. compiled java classes, war)


• program source


• user guide (or any sort of document to describe the usage)


• email announcement


• tag a version on SVN

As you can see, the list is quite extensive and thus I feel it's easier for the team to spend a day for preparation. In turns, it helps them to review what they have achieved and give them a sense of satisfaction. With the release properly organized, it helps you (the project leader) to review the development as a whole. You can evaluate if the pace is proper and allow you to send out your product for testing or simply to experience at the earlier stage.

What is the perfect team size?

Say hi to your team

You start working with a team. But have you ever wondered, how the size of your team will affect your work? Have you thought about what is your perfect team size?

Larger team = Shorter project time? Not necessary so.

When you have a lot of work, it's natural to hope there are more people to help out. Sometimes it work but not necessary so during a product development. Or to be precise, the "efficiency" of having more people in your team does not scale linearly with project time. The more people you have, the larger the overhead in managing them - the daily update get prolonged (I will talk about the work around later), more concurrent tasks means more context switching.

What's more, no two individuals are the same. We have different personality, some communicate better than others, some do backend better than UI frontend. So the larger the team size, you have to possess more "set" of communication profile with the team member.

When we work solo, the project schedule is simple, we have a lot of flexibility to shuffle the tasks around. But once we have a team, we need to deal with multiples of working schedule. Tasks dependency among different people shows up and more consideration is needed if we want to execute the project efficiently.

A big team is not necessary evil.

So, should I avoid having a big team?

It depends.

There are tasks that scale well, tasks that are repetitive or demand just manual labor. One of the example is functional testing, although you can automate many of your tests, functional testing (or UI expectation for GUI program). When you have a proper test plan on hand, tester can carry out the test execution by themselves.

If you have a larger team (i.e. larger then my desired perfect team size), I can suggest some twist to ensure an efficient daily update.

Attend multiple of daily update
Instead of getting everyone together, you may split the big team into smaller entity. Group them together by functions and talk to each of them. This prevent the whole team but you to sit together for a lengthy period, yet, knowing what's happening to everyone is your job, isn't it?

Just bring the team lead
Another approach is just grab the team lead together and have them update on behalf of their team mate. The advantage of doing so is, all the team lead know what's the whole project is happening and they can then divert the message to their team mate in their own update session. You may have fewer chance to meet some of the team mate but compensate for it in other occasion, like a tea session or lunch gathering.

Three, the magic number

I prefer having a team of 3 people or 4 the maximum. If the 3 people are working as individual, there will only be 3 stream of work proceeding at the same time, which I can follow through and understanding the details. When there are more concurrent tasks, I find myself will begin forgetting the detail for each of them. For a more complicated tasks, I have the flexibility to assign 2 of them working together.

Also, preparing work that can "feed" 3 people is much easier than feeding a bigger gang. Since you only need to prepare a handful of tasks, you shall have sufficient time in defining them clearly. When the team are busying working on the tasks assigned, you have the buffer to prepare the next wave and also have time for your own work, too.

Go back and enjoy the team work.

Daily Update

I have a meeting with my team at about 2:30PM every day.

The objective is simple - everyone in the team will tell other what they are doing.

Is it a waste of time?

OK, I hear you are saying. Meetings are toxic.

But first, let me tell you what daily update is meant to me (and my team).

1. It is the time for everyone to get together. I can also notice how they look - are they tired? Are they excited on what they are doing?

2. It allows everyone to know the status of projects. Since we usually have multiple projects executing at the same time, so one may learn about the other projects.

3. It provides a platform for everyone to either raise the issue they are having or simply to show off what they have done.

4. Let them know what I am doing. Don't think about if it's of relevant to them, they have the rights to know. Being transparent helps to build the trust.

Some tips to reduce the "cost"

Asking everyone to drop their work and sit together is costly. But there are some way to reduce the cost.

1. Make it consistent. I used to meet in the morning, before everyone kick start the day, but turns out they come back at different time and thus I moved the meeting to after lunch. With the time fixed, people can allocate their work better to prevent pulling them from the "Zone".

2. Make it short. Usually, 15 min is sufficient and unless there is some complicate issue to discuss. If the issue only of interest to some of the teammate, discuss it after the meeting.

3. Make it causal. You don't want it become a burden for everyone. Apart from the regular update, try to let it be the stage for the team to show off their work! Let them get the satisfaction and applause they deserve.

4. Make your notes! Have a little notebook with you, drop down what the teammate has said, you can mark down the item to follow up on the next day and in the long run, you can review the progress of the project.

Meeting is only a gesture

So, daily update is a mean of communication. You can disagree having a meeting but you are wrong if you are not communicating with the team. You can pick the most comfortable means (IM, email or even lunch gathering) to achieve this. Just don't get the gesture prevent you from knowing your team (and vice versa).

Getting stuck? One of this method can help you.

Problem, like shadow, shall never go away

Let's face it, we can never get away from problems. And we should all have the experience of getting stuck, no matter how hard you try, there doesn't seems to be a progress in finding the resolution.

It's all because of the juice

The "creative juice" is what we need in resolving problem. The juice contains all the "nutrient" we need in solving the problem, these nutrients are what we consume everyday - the things we see, we learn and we listen. These information help us to find the best way to tackle the problem, thus, when we are stuck, it meant the "juices" is unable to circulate.

Cleanse yourself

One of the method which works very well for me is taking a bath, I have "solved" many problems during my bathing time. The sound of the shower, the isolation and the steam, establish a very well environment that I find idea is flowing around me. One of my lately encountering is designing the roadmap for my product. I need to strikes a balance along the product line and to satisfy needs of all kind and some of them is contradictory (e.g. a software solution vs a hardware solution). One night, when I am bathing, I realize that I can simply split the product into two but having one as the subset of the other.

Apart from bathing, dish washing and extensive walking can also help me to better circulate my "creative juices". The repetitive action enables me to get into the state that, idea can again flowing freely.

Zen is null

What I have been sharing is nothing magical, the activities are similar to meditation. Meditate enable us to get into a state that enable our "creative mind" to become dominant. I am no expert in Zen or Buddhism, but to describe this state of mind, I find it is close to the state "null" that we are familiar with. The state of meditation is not either an "empty string" nor "non existent".

It has been realized by a lot of people and nicely explained in various books. One book which I strongly recommend is Pragmatic Thinking and Learning: Refactor Your Wetware. It explains all the above with theoretical information.

To summarize the article, I would like to share a quote from Zen master Daisetz Suzuki

"Great works are done when one is not calculating and thinking."

Happy Meditation.