Difficulty applying Scrum
A software developer wrote to me: “We are applying Scrum method to our software project but we are having a lot of problems. Although our project manager has taken an Agile training class but he cannot solve it either. We are thinking about switching back to the old method. Please advise.”
Answer: Scrum is an excellent method for small software project. The key different between Scrum and other approaches is its simplicity approach. Scrum allows the project to be done incrementally, one piece at a time. To make Scrum works, you need to have experienced team members because Scrum requires a self-organizing team, that means there is no project manager or team leader to direct the team but every member of the team must work together to get the work done. Since you have a project manager, it seems that you may not use Scrum correctly. If he is the only one who receives Agile training than it is a mistake. I recommend that the entire team to enroll in a Scrum training so you can do thing correctly.
There are three roles in Scrum project: The Scrum Master, the Product Owner, and the Team Members. The Scrum Master is responsible to make sure that the team is following the Scrum process. The Product owner represents the customers' views and guides the team to do work that meet user's needs. Team Members are responsible for getting the work done. Without one of these key roles, the project may fail. There is no project manager, no team leader, no tester, and no software assurance quality roles in Scrum project. Any of these additional roles will create unnecessary conflict. (That is why the team is called “self-organized.”)
There are different views regarding the size of Scrum project. Some believe Scrum team should be 5 to 10 people; other think it could be up to 20 or even 40 people.
In my experience, 6 to 8 people works best since too many people will make it difficult to share information. People work best in smaller team and that is why agile approach works well for small projects. If your project has 15 or 25 people, you may have problem.
Scrum project is divided into several smaller “unit of work” called “Sprint”. Sprint always has a fixed length of time so the team has exactly the same amount of time to do work. By making every Sprint the same length, the team learns its own capacity for work. If the Sprint length changes, the team will not know its capacity (How long to complete a number of tasks) which make planning more difficult. This is a subtle issue that many people do not pay attention but it is very important that all Sprints have the same length. If your project does not follow this rule, you may also have problem. I often give my team a fixed time of 4 weeks as I think 2 weeks is too short and 5 weeks is too long.
Each Sprint is an opportunity to learn as the team works together and adjusts to each other's capability. Every Sprint starts with a Sprint Planning meeting where the team discusses “WHAT” to build and “HOW” they will build it. The focus of the meeting is on choosing a number of tasks from the Product Backlog Items (Software Requirements) and breaking them into a list of tasks called the Sprint Backlog. The goals of Sprint Planning is to plan the work for that Sprint, and make sure team members understanding its works based on feedback from the previous Sprint. Every team makes mistakes at the first few Sprints, as they work together; they learn together and eventually get better. Things often improve in the third or fourth Sprint. If you are having problems in the first few Sprints, do not worry as you are still learning how to work together when you build the product one Sprint at a time.
Each morning the team gets together at the Daily Scrum meeting to share information and assign task (Who is doing what on that day). The Daily Scrum meeting usually lasts about 10 minutes but the common mistake is members often decide to skip the daily meeting. In my own experience, if a team fails to have daily Scrum meeting, the team will not work well as conflicts will happen. Daily Scrum is the time where the team members discuss their works with each other as well as share experience and learn from one another. The Scrum Master must monitors and measure the progress of the Sprint (i.e., Measurement is made every day on the team progress). If your team does not have the daily scrum meeting, it may be a cause why your project is having problem.
The last parts of the Sprint are the Sprint Retrospective and Sprint Review where the whole team (including the Scrum Master and Product Owner) discuss how they did their work during the past Sprint and come up with ways to improve their work in the next Sprint. The Sprint Retrospective is keeping exclusive within the team only where they discuss “HOW” it was done. This activity is critical for the team as it is a learning process for every member. It is the job of the Scrum Master to make sure team members do attend all these meetings and share experiences.
The Sprint Review is where the team goes over “WHAT” was done with the customers to see if the team does complete what they plan during Sprint Planning. In this review, team members explain and demonstrate the work and customers provide feedback about the product. The exchange of information is documented by the Product Owner into the Product Backlog.
Since you do not explain in detail about the problems with Scrum, I only guess but before you switch back to the old method, you need to review your work and make sure that you do not make mistakes as I mentioned above. Like any new methods, it take times to do it well and the most important is the entire team must receive the proper training to do it well. Scrum works well with small software project and it is getting more popular with Mobile application development and Cloud computing projects. If you are still having problems, you may need someone with experience to help. Maybe you need to bring in an Agile consultant.
Sources
- Blogs of Prof. John Vu, Carnegie Mellon University
