SCRUM part 2
Agile is a “teamwork oriented” software development process designed for small project where requirements are not stable and continue to change. In order to make agile works, customer participation is required and the team would focus on the activities rather than the results because quality activities would produce quality results. Tradition computer science program emphasizes the outputs or results (product) but not much on the activities (process) that created the results. In class, students are focusing mostly on the correct outputs but not taught on the process of develop software. This is one of the problems of programming language training where students can do whatever they want as long as they come up with the correct answers. In contrast, software engineering training is focusing more on the disciplines to build software according to a defined process. One of the methods that are being taught is agile.
There are several methods in agile but the most popular is “Scrum” a defined process to monitors and controls software development activities. The key aspect of Scrum is the defined roles, responsibilities and accountabilities of people in the team as follows:
The Product Owner is responsible for the following:
Define the features of the product;
Decide on release date and content;
Prioritize features according to customers needs;
Adjust features and priority every 30 days, as needed; and
Accept or reject work results.
The Scrum Master is a team leader working closing with the Product Owner. The Scrum Master:
Ensures that the team is fully functional and productive;
Enables close cooperation across all roles and functions;
Shields the team from external interferences; and
Ensures that the process is followed,
Is cross-functional, with experienced members;
Selects the Sprint goal and specifies work results;
Has the right to self-organized within the boundaries of the guidelines to reach the Sprint goal;
Demos work results to the Product Owner.
A Scrum software project is managed by maintains a Product backlog (Requirements list) and risks. Product Backlog is statement of works that the project must implement. Risks are things identify in product backlog that the team must mitigate.
Scrum allows project team to determine when the system is “good enough” to be released to customer. With Scrum, every project progresses through a series of iterations, usually four weeks in length, called “Sprints” (Short duration). At the start of each Sprint, a Sprint Planning Meeting is held during which the Product Owner prioritizes the Backlog and the team selects the tasks they can complete within that Sprint. These tasks are then moved from the Product Backlog to the Sprint Backlog. Each day a daily meeting called the Daily Scrum is held, to identify which activity has been completed and which is not and must be implemented on that day. This kind of meeting creates a visibility of each person's work to facilitate knowledge sharing, reduce overlapping tasks, and ensure that their work is fully integrated. At the end of each Sprint, the team demonstrates the completed functionality at a Sprint Review Meeting. By having several sprints, the project team can build the software in several short durations incrementally with flexibility and fast (Agile).
The Scrum process consists of four activities: Sprint Planning, Daily Scrum, Sprint Review, and the Sprint Retrospective.
1) Sprint Planning
Preparation for a sprint begins when the Product Owner develops a plan for a product. The Product Owner must have a vision for the product and be able to breakdown the products into small pieces according to a plan with several releases, each focusing on certain features. The Product Owner prepares a Product Backlog, a list of features prioritized by customer.
The Scrum begins with the Product Owner reviewing the vision, the plan, the release schedule, and the Product Backlog with the team. The team reviews the estimates for features on the Product Backlog and decides how much work it can take into the sprint based on team size, available hours, and level of team expertise. The team pulls items from the Product Backlog that they can do within a thirty-day sprint into sprint backlog then the Scrum Master leads the team in a planning session to break down these features into sprint tasks. These are the specific development activities required to implement a feature for the sprint.
2) Daily Scrum
Once planning is complete, the Sprint begins its iteration cycle. Each day the Scrum Master leads the team in the Daily Scrum Meeting. The Daily Scrum is a short meeting designed to clarify the state of the Scrum. Each team member responds to three questions: 1).What has you done since the last Scrum meeting? 2) What are you planning to do today? 3) Are there any obstacles preventing you from performing work you are planning to do today? The goal is to get an status of the project, discover any new issues, address any personal needs of team members, and adjust the plan in real time to the needs of the day.
3) Sprint Retrospective
The meeting is attended by the team with the Scrum Master, and Product Owner. The meeting starts with all team members answering two questions: 1) What went well during the last sprint? 2) What could be improved in the last sprint? The Scrum Master documents the team answers in summary form, and the team prioritizes the order it wants to talk about the potential improvements. The Scrum Master facilitates the team's search for improvement opportunities to the Scrum process, identified actions that can be added to the next sprint for improvement.
4) Sprint Review Meeting
Sprint Review Meeting is held at the end of a sprint. The first part is to demonstrate to the Product Owner the code that has been developed during the sprint. The Product Owner also invites customers to attend to review and to determine which features on the Product Backlog have been completed in this Sprint. The customers, product owner, Scrum master also discuss how to reprioritize the Product Backlog for the next sprint. Then the goal for the next sprint is defined and discussed on how the team will worked together in the next sprint. After the Review Meeting, the process begins again with another sprint until all features have been done to complete a product.
- Blogs of Prof. John Vu, Carnegie Mellon University