A Detailed Introduction to Agile Management Part 3

Today’s article is the third one in a series of articles A detailed introduction to agile project management. This article will introduce the specific practices and application tools of Agile project management.

Hashtags: #Agile #AgileManagement #AgileManagementProject #ProjectManagement #SoftwareDevelopment #ProductBacklog #SprintBacklog #BurndownChart #SprintPlanning #SprintReview #SprintRetrospective #ManagementProcess

5.Software Development Mode

a. Team role

It includes a scrum master, product owner, development, test, UI, DBA, etc.

·The responsibility of the scrum manager is to control and manage the whole project, coordinate team resources and solve the problem on time;

·The product manager is responsible for the product quality, defines the Backlog, and confirms the allocation in each Sprint. And they also need to formulate the user story and task priority, confirming the release time of the version is also their work;

·Other team members such as developer and tester generally need to cooperate with other members' cross-department, which requires them to organize an activity to ensure the stability of team members in Sprint.

b. Application tools

?Product Backlog

The Product Backlog is used to list product requirements and display them in the form of user stories. Each user story has a corresponding story point, which represents the estimated workload to complete all the work of the story; the product owner needs to produce before the start of each Sprint.

?Sprint Backlog

The Sprint Backlog refers to the task in each iteration cycle. It is generally a subdivision of the user story. The evaluation can be accurate to the working hours, and the priority of each task needs to be arranged. The scrum master needs to evaluate the working hours, and the product owner arranges the corresponding task priority. Sprint Backlog needs to be done before the start of the Sprint.

?Burndown Chart

Burndown Chart is a work chart showing the remaining workload. The project manager is required to make a Burndown Chart before the resumption of the sprint.

The following is a typical Burndown Chart. The horizontal axis represents the time, the vertical axis represents the workload and the blue line shows the ideal state. The yellow line shows the actual state, which can intuitively show the overall completion of the work.

c. Meeting

?Sprint planning meeting

Before the Sprint, the product owner should sort out the Product Backlog, confirm the goals of the Sprint, create the Sprint Backlog. And the product owner should also do priority and task estimation.

Before the start of the Sprint, the product owner organizes a meeting. Before the meeting, the product owner should sort out the Product Backlog, confirm the goal of the Sprint, and create the Sprint Backlog. It is also necessary to list their tasks in priority and estimate tasks.

?Sprint review meeting

In the later period of the Sprint, the product owner should organize the meeting and invite relevant people to participate, and demonstrate the product functions completed in the Sprint through live demonstrations.

?Sprint retrospective meeting

At the end of the Sprint, the project owner organizes team members and related personnel to participate in the retrospective meeting to review and summarize the work of the team in the Sprint. Generally, the Sprint retrospective meeting takes 20 minutes.

?Daily meeting

A regular meeting at a fixed time is organized by the project manager. It is usually 15-20 minutes before work every morning. Team members take turns to explain their completion of yesterday’s tasks, today’s tasks, and current obstacles.

It should be noted that in the daily meeting, only the facts are stated and no discussion is made, so as to avoid wasting time. The project owner can instruct the party to discuss and solve the problems encountered by the members in private but only focus on the arrangement.

d. Management process

6. Misunderstandings in the Application

a. Agile is the best way to manage a project:

Agile is only a method, and it is not omnipotent. It can’t be done completely according to the theory, but it needs to be used flexibly. For example, Agile emphasizes people’s subjective initiative, and each person can choose his own task. But in reality, this method is not advisable. In addition, Agile management is rarely fully practiced by enterprises, mainly due to its high requirements for the environment.

b. Agile does not require planning

Agile only needs to make a plan within the Sprint, and there is no need to make a detailed plan ahead of time because the changeable requirements often deviate from the actual plan, and the plan is meaningless.

c. Agile does not need a document

Agile is just management Agile, not Agile which reduces quality. It needs to create corresponding documents as needed, including user stories, PRDs, acceptance reports, operation manuals, test cases, test reports, deployment manuals, software release notes, etc.

d. Agile must be face to face

It doesn’t have to be face to face in the traditional sense, video and instant messaging are also required. Agile emphasizes the immediacy of communication.

e. Agile’s requirements can be changed at any time

Changes are not allowed within the Sprint, and a corresponding plan can be made for the next Sprint.

f. Agile can complete the project fast and efficiently

Agile management does not necessarily shorten the overall development cycle, let alone save money. There are often repeated development, testing, deployment, and other work.

As the last article in the series, this article introduces the specific practice, meeting, tools, and process of Agile, as well as some common mistakes in practical application.