Wednesday, September 05, 2007

SCRUM

We are applying SCRUM in our software projects and I wanted to write about it summarizing its advantages, disadvantages and how to make good use of this approach in software projects.

During the middle of a project, requirements may change or the users may not like the application after it is delivered. Although lots of the requirements can be specified at the beginning of a project, we should be flexible enough depending on the conditions.

Scrum might be ideal if your project’s requirements are changing rapidly.

Scrum starts with the product backlog. In scrum, product backlog includes the tasks, stories which are prioritized by the product owner. Product owner should not be involved with technical details but should be focused on business goals. I would even describe the product owner as a business analyst. All team members contribute to find the estimates for the tasks. A task or a story is not about coding all time. It can also be documentation, testing and deployment, anything that needs to be done to deliver the application to the end users. Each task should be split into subtasks and they should be included in the product backlog. All the team members together determine the estimates. Estimates can be changed during the scrum sprint. A sprint can be defined as a bunch of tasks selected from the product backlog to finish in a given time and it should not be changed once it is agreed. No one from outside the team should change the sprint or interfere with it. Sprints can be 2-3 or 4 weeks. The meetings are managed by the scrum master. Scrum master’s role is basically like a project manager or a team leader. He helps team to achieve the tasks in the sprint. Sometimes the team members are unaware of the status for a sprint. It requires feedback from the scrum master.

Every day, the scrum team makes a meeting. These meetings should not be very long. In these meeting, the team members tell about the work they have done since the last meeting and what they intend to do until the next one. If there are any impediments, they should be discussed as well.

Scrum or RUP or XP?
Scrum does not have a defined software process. It concentrates on how team members are doing on the project with every day sprints. However RUP defines a process. With the given estimates, it requires good quality software to be delivered based on the requirements. For each activity, a template can be found in RUP. It can be a guideline, a template, defined sets of rules etc. Scrum is mainly about the management, while XP is about programming practises. They can be used together to come up with management and programming practices. They may overlay sometimes.

RUP, XP, Agile, SCRUM,…. Is it enough to rely on applying these methods and expect to succeed? Whichever of them you use, followings are very important.

- Good team: If the developers are good enough whichever method is being applied does not matter. It will bring the success. SCRUM tries to increase the communication between team members. So it gives management a bit more control. It is also good for developers since the estimates are discussed in sprint meetings and everyone gets aware of the difficulties. Every team member knows what the other colleagues are doing and how difficult task each team member has. Developers have their chance to express why a task takes long or short agreeing with all the team. Estimating tasks will be fair for all developers. Business owners will be aware of all this as well.

- Make sure you have the requirements: Having sprint tasks may not be enough. It is good to have the requirements. You do not have to update the requirement documents for the life time of the project. It does not have to be a heavy document but developers need the requirements. Product owner’s role is very important in SCRUM. If he changes his opinion about a task too frequently then there is something wrong. Trying to finish a project and then change it may cause bad coding practises in the project. It is difficult to have the good quality back.

- Make sure you have unit tests: It is always good to have unit test codes. If your requirements are changing rapidly, it is a must! There is no other way. It really helps you in the long term. It may not mean anything to product or business owners at first and they may not give any priority for writing test methods. But it is very essential. Applying test driven development might be a good choice in SCRUM since it also helps you to analyse what you are developing. In SCRUM we split tasks to the smallest tasks and assume that we do not need any more analysis. Test driven development fills the gaps missing from this task oriented development.

- Code reviews: If you have a new team member, it is wise to review the codes until he becomes more confident. It is not to track him but just to point in the right direction if anything goes wrong.

- Error handling: Is error handling a must or something good to have? For me, it is essential, especially in SCRUM. We have to capture the errors so that we can fix them. Without knowing what is causing the problems our products will be with the errors. From the beginning we should implement error handling and log the errors. It should not be waited until the end of the project. It should also be included in the way the coding is done.

No comments: