Earlier we mentioned Kanban building and value flow analysis. This article talks about the Scrum framework practice of agile transformation.
From our agile transformation journey, our pilot team started to practice the Scrum framework after engaging in the Kanban method and daily stand-up meetings for a while. The reasons are mainly in two aspects: first, our team’s previous development model was a typical waterfall model, with a very superficial understanding and understanding of agile; second, our practical methods for user stories and Scrum frameworks take time Digestion requires a certain buffer period. So we chose to start with building a Kanban board and daily stand-up.
When it comes to Scrum, first of all, it is the old tune to talk about concepts, methodology, etc.
Conceptually, Scrum is a development framework for cross-functional teams to develop products or projects in an iterative and incremental manner. It organizes development into a work cycle called Sprint. Each of these iterations does not exceed 4 weeks (the most common is two weeks), and they are carried out successively without interruption. Sprints are limited by the time box. They will end on a specific date regardless of whether the work is completed or not, and they will never be extended.
The benefits of implementing the Scrum framework are also obvious: (1) reduce the risk of changes to the system; (2) increase ROI (input-output ratio); (3) help us continue to improve; (4) continue to quickly release available software Products; (5) Everyone has a clear understanding of the real usable software products and keeps improving in the iterative process.
At present, Scrum is the most widely used agile method and practice in the world.
When it comes to Scrum, you must know "3355", that is, 3 roles, 3 artifacts, 5 events, and 5 values.
The three roles include product owner (PO), ScrumMaster, and development team:
The three artifacts include: product to-do list, iteration to-do list, and product increment.
Product Backlog (product to-do list) is a list of requirements from a product perspective. Product Backlog is a carrier for dynamic demand management. The product backlog is composed of all functional features, including business functions, non-business functions (related to technology, architecture, and engineering practices), improvement points, and defect repairs, which are also the main content of future product releases.
When making the product to-do list, one is to clearly state the value of each demand task in the list to users, as an important reference for prioritization; the other is to dynamically manage the demand, and the product owner must continuously manage and Refresh the list of requirements, especially before the start of each iteration, re-screen high-priority requirements to enter the current iteration; third, the demand analysis process should be based on the idea of iterative analysis, and under the overall demand framework, only recent A detailed analysis of the needs to be done.
Sprint Backlog (iteration to-do list) is the content planned to be completed in this sprint cycle. After being approved by the PO and the team, the Product Backlog will be delivered to the team for development. It becomes the sprint backlog. The process of converting to the sprint backlog generally also includes task decomposition and duration estimation.
Increment (deliverable product increment) is the sum of all product to-do list items completed in a Sprint and the sum of the value of the increments produced by all previous Sprints.
The 5 events include: Sprint, Sprint planning meeting, daily stand-up meeting, Sprint review meeting, Sprint retrospective meeting.
In the actual practice process, we mainly practice several ceremonies for each complete Sprint, and according to the practical experience of the project team, we mainly use 2 weeks as an iterative cycle. Generally, the PO, SM and Team will be held on Monday. Participate in the Srpint planning meeting to discuss the product to-do list, evaluate the story points and estimated time, refine the development plan, perform task decomposition, and output the Sprint Backlog. All team members are required to fully participate and discuss, determine corresponding internal tasks, and make corresponding commitments.
After that, the daily stand-up meeting will be held from the second day. The daily stand-up meeting is generally held 5-10 minutes after work, and the duration is generally about 15 minutes, and different project groups vary.
After the iteration is completed, a Sprint review meeting will be held. In addition to the participation of PO, SM and Team, if conditions permit, customers will also be invited to review and accept the deliverables, which further increases communication and mutual trust. For example, PP Project invites customers to review the online functions of the current iteration before each iteration goes live, reducing problems and business changes after going online; PPAPP 2.1 Project invites customers to review the results of iterative development together, which changes the customer’s continuous The concept of expanding the scope of demand development without paying attention to the core elements of product user experience, and working with customers to polish it together, although the delivery function of the first version is not much, but the user experience and other aspects have been improved a lot, the overall effect is better than PPAPP The 2.0 Project has made great progress.
Before the start of the next iteration, a Sprint retrospective meeting will be held, and all team members will speak separately, share good experiences and discover improvements, so as to promote the continuous progress of the team. At the iteration review meeting, all members reviewed the iteration process together, summarized what was well done, what was not well done, and what needs to be improved, and clarified the improvement items for the next iteration, which is conducive to building the team's continuous improvement circle, and In each iteration, by considering the issue of capacity allocation, dynamic allocation adjustments were made to user stories, technical debt and routine maintenance, and overall quality control was strengthened.
The five values include: commitment, focus, openness, respect, and courage.
When doing Scrum practice, you need to fully integrate the actual situation of your team, and appropriately reserve 20%-30% of the ability to deal with emergency handling, technical problem research, and so on.
Therefore, for Scrum to really work, the team must understand collective commitment and self-organization. In actual practice, this requires the joint efforts of the team: first, the team must always maintain the pace of completing the delivery within a fixed time; second, the team must have a common and clear goal to drive the team forward; third, Continue to practice the Scrum framework, summarize each iteration, and continue to improve in the next iteration.