Work Time in Extreme Programming

InfoQ posted the news about Sustainable Pace in XP on May 2, 2008 which title is Does Sustainable pace mean a 40 hour week? That’s an interesting topic about agile development. The article focuse on the correlation between the number of work hours weekly and sustainable pace.

As Henrik said, every programmer has a “Maximum Productivity” which depends on his talents. It called “Current Capacity” which is the highest amout of work which can be done whithout lowerring the quality. So he suggest we shoud make sure the every developers’ current capacity at the beginning of the project development, otherwise keeping the work week at 40 hours sounds like waste. He said:
If we can hold sustainable pace of say 45 hours per week, as opposed to 40, we gain more than one month of extra development time during a year! Especially in start-ups, such as where I work, 40 hours a week is a luxury one can’t afford.

But other guys disagree with Henrik’s opinion. They suggested that increasing the number of work hours does not linearly increase the productivity. If we work overtime, teams tend to more destructive than productive. When working long time, the productivity begins to decline.

So the key point is how to value the degree between the number of work hours and productivity. We cannot increase the number of work hours to improve our business value. We must consider about the ability of undertaking the pressure.

The summary of this article is that the important factor to sustain pace is not number of hours worked, but to think creatively and accomplish more in less time. The sustainable pace revolves around a lot of factors like work culture, technical debt, motivation etc. It might have a small influence from number of hours worked, but that is not the best metric to start with.

Advertisements

What Makes a Good Stand Up Meeting?

standupIn Scrum, Stand up meeting is called daily scrum. It’s very important to prompt the team members’ communication, and helps Scrum Master know about the process of development. As its name implies, the meeting should be hold daily and ask everybody to stand.

In normal, during the daily scrum, each team member should provide the answers to the following three questions:
1. What did you do yesterday?
2. What will you do today?
3. Are there any impediments in your way?

The daily scrum meeting is a statue check where the team meets and updates each other about what’s going on. It provides the daily focus on the work being done:
1. Same time and place
2. Avoids overhead of finding a place daily
3. Avoids overhead of team trying to figure out where and when is today’s meeting
4. Let’s chicken’s know where and when
5. No more than 30 minutes
6. Scrum Master asks pigs three questions
7. Scrum Master is responsible for making the decisions
8. Scrum Master is responsible for noting and solving work impediments
9. All discussion other than replies to 3 questions deferred to later meeting

Though it is very short, but very important. So scrum master should try one’s best making the team’s daily scrum good. Marcie Jones give some tips about Daily Scrum Meeting:
1. Don’t be late yourself.
2. The meeting needs to start on time.
3. If #1 and #2 really can’t happen, experiment with different meeting times.
4. Cut off inappropriate discussions.
5. If the updates are too vague, ask question.
6. Ask your team permission to keep trying it daily for say, one more iteration while you try to fix these problems.

Do you agree with these opinions? Do these ways really help scrum master improve the quality of daily scrum meeting? Please try it!

Agile is Not Easy

On Apr 30, InfoQ China posted an article “实践敏捷很容易:为期两天的“迷你”敏捷项目“. It introduced the Code Jam that was hold by ThoughtWorks. Absolutely, this form of Code Jam was very useful and interesting. It would help the developers to master the agile methodology, idea and principles. But I don’t be agree with the author’s opinion partly. I think whether agile is easy should depend on the specific situation.

In Thoughtworks, most of the developers are familiar with Agile Methodology. They are all agree with the idea and principle of Agile. So we don’t need persuade them to accept this methodology. They know about the process of agile development. They are used to using TDD and Pair Programming to develop the software. They enjoy the communication. They appreciate for the efficiency of Standup Meeting. They are fond of Retrospection to summarize the good experience and shortage to help improving the development process. In a whole, they are excellent team members and the team is more professional. This team is a real agile team. In this team, maybe everyting is going on well.

But the thing is not alway nice. If your team members all are fresh guy with Agile Methodology, what should you want to do? More serious if most of team members have not master the basic skill for developing project, what should you want to do again? Can you say: Agile is easy?

In this situation, How to implement agile and what to practice agile are the first task you should complete if you are an agile coach or ScrumMaster in Scrum. You should introduce some issues related Agile Methodology to everybody. You should let them master the agile knowledge, and think everything during developing project in agile thinking. You should be careful everytime and pay attention to every cicle of software development. If some mistakes happen, you must correct them in time. You should negotiate with your leader and customer, and try your best to prevent your members from interfering by others. It’s your responsibility as “Collie”. At the same time, you are a guide to lead them walking on the right way to destination. Besides, you should build the harmonious environment to prompt the communication between the members.

There are many problems you should solve as well. Anyway you can’t escape. Unfortunately, my project is in this situation now.