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.

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.

Scrum Practice in Project Management

Abstract

Scrum is an iterative incremental process of Software development commonly used with Agile Software Development. Especially, Scrum will help us to manage the project more efficiently because it is an adaptive process. However, applying the Scrum Methodology should depend on the different situation during the process of project development. It’s a big issue to solve. This article gives an example to elaborate how to manage the project with Scrum.

IntroductionSoftware development is a complex endeavor. So the most difficult problem is how to handle the complexity through by the science of project management. Many scientists and software engineers raised a great number of methodologies for project management such as Waterfall, UP and Agile. In contrast to the heavy methodologies including Waterfall and UP, Agile is enough flexible to embrace the change, more light to be mastered by project team members, and more focuses on the communication and release of the usable software rapidly. Agile methodologies include eXtreme Programming, Scrum, Feature Driven Development and Crystal etc.

 

Scrum was raised by Hirotaka Takeuchi and Ikujiro Nonaka in 1986. The skeleton is shown in Figure 1.

Figure 1

The lower circle represents an iteration of development activities that occur one after another. In Scrum, it was called Sprint. Each Sprint is an iteration of 30 consecutive calendar days. The output of each sprint is an increment of product. The upper circle represents the daily inspection that occurs during the sprint, in which the individual team members meet to inspect each others’ activities and make appropriate adaptations.

There are three roles in Scrum including ScrumMaster, Product Owner and Team. The ScrumMaster is responsible for the Scrum process, for teaching Scrum to everyone involved in the project, for implementing Scrum and ensuring that everyone follows Scrum rules and practices. The Product Owner is responsible for representing the interest of stakeholders and creating the project’s initial overall requirement which was called the Product Backlog, for using the Product Backlog to ensure that the most valuable functionality is produces first and built upon. The team is responsible for developing functionality. Teams are self-managing, self-organizing, and cross-functional, and they are responsible for figuring out how to return Product Backlog into an increment of functionality within an iteration and managing their own work to do so.

Problem Statement

Without doubt, Scrum is one of most popular agile methodologies now. It, however, is not easy to apply it to project management. Considering about the following situations please:
1. If the culture of your organization is contradictious with Scrum, and your leader always interrupts you during the process of project development, what should you do?
2. If your team members are not familiar with Scrum, and they don’t understand the heart and rules of Scrum, what should you do?
3. Furthermore if your team members didn’t master the basic skills of Agile developing such as pair programming, Test Driven Development etc, what should you do?
4. If your customers always change their requirement, they are not clear what they want even, what should you do?

Our Solution

In fact, we can’t find out the “Silver Bullet” to solve these problems. We know Scrum is an adaptive process. Scrum makes many rules which should be followed, but not hidebound. It’s agile and flexible. It allows us to adjust the way to achieve the goal of project.

The answer to the first question is operating within the culture of the organization. Don’t fight against the culture of your company. If you are ScrumMaster, you’d better walk a fine line between the organization’s need to make changes as quickly as possible and its limited tolerance for change. You can adopt Scrum by starting small. At the same time, you should try your best to persuade your leader to support you. Sometimes your leader will build the bridge between the agile world and non-agile for you. Of course, it needs change, but these changes must be culturally acceptable. If not, you must acquiesce. The ScrumMaster is a sheepdog of the team, and his job is to protect the team from impediments during the Sprint. Remember that the precondition of which everything is going on well is that the sheepdog cannot be dead. After all, Scrum is the art of the possible.

Right, we hope our team members are all software craftsman so that everything is Ok. Unfortunately, the real world is not as good as that we expect. In fact, the situation in which most of team members are all apprentices is more common. It is true that it is difficult to hire the experienced software engineer in this industry. So the problem we must solve is how to train them. We should draw up a training plan. Before it, we must understand the skill set of everybody. We need to assign the mentors to the fresh guys. Of course, the best way of training is practice. We should assign the task to them according to their ability. At the same time, we have to add the task duration because they are not familiar with the related skills. Besides, Pair programming is a good way to handle it.

The great character of Scrum is enough flexible to embrace the change. Scrum is an iterative and incremental process. The iteration is very short (30 days) so that we can change our plan in time. The incremental development will provide the good policy to submit the release rapidly. The increment product can give our customers confidence. And the customers can understand the difference between what they want and what we provide though by the running software. Scrum emphasis on the communication between the team and customers. Product Owner of Scrum is responsible for communicating with the customers and creating the product backlog. In case the customers changed their requirements, the Product Owner will discuss with ScrumMaster and Team. If the change is acceptable, it is added into the product backlog. If the change is within the sprint which the team is developing, the sprint has to halt, and re-open the new sprint. Beside, the daily scrum will help each team member understand the current statue of the project, and the sprint review meeting will show the result of the sprint to the customers in order to get the feedback from the customers, the sprint retrospection meeting will prompt the Scrum process framework and practices.

Evidence that the Solution Works

Now we complete the first sprint of the project on time. In a month, we went through the whole lifecycle of the software development from the requirement analysis to designing, coding and testing. Each member is familiar with the Scrum gradually. Everything is going on well such as Daily Scrum, Team Work and Sprint Development. In the end of this sprint, we submit the increment product to our customers and get the feedback from the customers. The most important achievement is that our customers approve our approach to develop the product.

Competitive Approaches

We don’t follow the rule of Agile Methodology strictly. For instance, most of team members are accustomed to the TDD (Test Driven Development), so we adopt the traditional way to design and develop the software such as Use Case Driven Development instead of TDD. But we require everybody must write the test case for classes and components. We organize the pair programming group to prompt each other.

Because our customers are off-site, so we require our Product Owner must be in-site and cooperate with them in full time. We create the communication schedule for the customers to understand the customers’ requirement. The Product Owner is empowered to handle everything with requirement.

Especially, the ScrumMaster of our project protects the team from the rest of the non-agile world. We get the enough resources and backup. For example, we have our own agile coach to direct how to apply the Scrum to our project. He can help us to solve the key problem when we are confused of Scrum Methodology.

Current Status

The project is going on well. The first sprint is very successful. Team members are all confidence. They regard the Scrum as the effective and enjoyable process. The customers are satisfied with our process. Most of risks had already solved because we emphasis on them and add them as the tasks into the sprint backlog.

Next Steps

Next month, we are going to hold the Sprint retrospective meeting to find out the existed problems in the first sprint. Then we will create the backlog for next sprint. In this sprint, we will develop the most important domain module and let it workable.

Conclusions
Scrum is an excellent agile methodology to release the software product rapidly and correctly. It gives all team members the new management responsibilities. The process of the project management is visible and controllable. The ScrumMaster and Product Owner don’t need to write the redundant documents and draw up the unrealistic project plan. The team members become more active due to self-organizing and self-managing.

References
1. Agile Project Management with Scrum, Ken Schwaber
2. Software Craftsmanship, Pete McBreen
3. Applying UML And Patterns, Craig Larman