Troubles of agile and invincible growth (15)

Growing troubles (15) This article is from agile and invincible

This evening, after the conference call was completed between Alibaba Cloud and the U.S., Alibaba Cloud was preparing to wash his face and brush his teeth, but unexpectedly found that the agile sages were launched! Ajie.com jumped up!

A Jie: Hello!
Agile sages: Hello!
A: Do you have time now? We are in trouble.
Agile sages: Well, I guessed it! I came here to find you! I think your first run is over, right?
A Jie: Yes! We encountered some problems, and people began to disagree. Some people even thought that Scrum had brought more trouble!
Agile sages: this is not a good sign. Let me talk about your problem. I think most of the methods you use are biased.
A Jie: I also think scrum is a good process.
Agile sages: Yes! After only one sprint, do not draw a conclusion that SCRUM is suitable or not suitable. Scrum allows you to think about how to manage projects from another perspective. It always takes some time to find a tip. I suggest that your team stick to this process and finish at least three sprints before deciding whether to continue. The first run will certainly encounter problems. You can review and summarize them, add some operational feedback to the 2nd sprint, and gradually make improvements. In this way, after three sprints, you will truly understand scrum.
A Jie: Good! I will persuade you to continue running sprint 2 and sprint 3.
Agile sages: Let me know how you did it first?
A Jie: this is probably the case. I took the time to complete the product's backlog, and then we made an execution plan with everyone. After that, the "Standing Meeting" will be held every morning. This is very time-consuming, about 40 ~ 50 minutes. At the end of the sprint, everyone made a few minutes of summary and reviewed the results. At the meeting, everyone had different opinions and thought there were many scrum problems.
Agile sages: Oh, how is your product backlog organized?
A Jie: As a scrum master, I made a list using Excel, put what we need to do in the next few weeks, and sorted by priority.
Agile sages: Wait! You said that you made a product backlog?
A Jie: Yes! Is there any problem?
Agile sages: that is to say, you have not defined a product owner role? Didn't this person complete and maintain the product backlog?
A Jie: Well, we don't have one.
A Jie thought that the face of agile Sages must be ugly. It is estimated that this problem is very serious!
Agile sages: If you really want to implement scrum, you must follow Nokia's agile standards and follow the "scrum rules" developed by NOKIA. It has been a few years since Nokia, after reviewing the hundreds of scrum teams, we can summarize simple suggestions, which can help them determine whether a team is actually implementing scrum.
A Jie: How Does Nokia know whether a team is actually implementing scrum?
Agile sages: First, they need to check whether iterative development is adopted. Over the years, the industry has been using iterative and incremental development, which seems to have become the basic element of all agile processes.
A Jie: this should be a good judgment. So why is "iterative development" so important to the team?
Agile sage: if you do not do this, it cannot even be called an agile software development process. This is because agility allows everyone in the entire software development process to work together. Everyone must be familiar with the product, whether it is the person who builds the product or the person who tests the product, users who will still use the product.
A Jie: Well, everyone should work together.
Agile sages: Yes, if the process is separated into "these people write requirement instructions and specifications here, and then they hand over the documents to the person responsible for building the software, the software builder then transfers the software to the testers and finally the testers provide the software to the customers. "the customer will say that this is not what they really need. Then we have to go back to the beginning and try again. If this is repeated three times, the customer will cancel the project. This is why so many projects have been cut down in the world.
A Jie: Well, in Nokia, what other questions should I ask?
Agile sages: they will ask, "Do you have a fixed iteration cycle? Does your iteration start at a specific time and end at a fixed time ?"
A Jie: Should there be restrictions on iteration cycles?
Agile sages: Yes! In Nokia, the iteration cycle must be less than 6 weeks. Otherwise, there will be no iterative development.
A Jie: What if the answer is yes?
Agile sages: then they will ask "Well, do you have any software to work at the end of each iteration ?" This problem will exclude many people, because if you cannot provide software that can work, it means there is no iterative development.
A Jie: Well, what if the answer is yes?
Agile sages: Next they will say, "Well, if you want to have software that can work at the end, before iteration can begin, do your team have to have a detailed requirement?" If necessary, it is not iterative development.
A Jie: Oh, I understand what you mean. Next?
Agile sages: in the end they will say, "To have software that can work at the end of an iteration, testing is very important as part of iterative incremental development. Are you testing during the development process ?", This problem may exclude about half of the scrum team, and I haven't even talked about the scrum issue yet.
A Jie: Yes! I understand, what are their "scrum rules?
Agile sages: Well, they have four additional rules for using scrum. The first question asked by the team is: "Do you have a product owner? Can someone work with you on behalf of the customer ?"
A Jie secretly thought that his team's scrum was really absent, so he asked: what is the role of the product owner?
Agile sages: It is very simple. When a team decides what kind of product should be built, this person is the target of their inquiry. This person represents the customer's needs and interests.
A Jie: What if I answer "yes" to this question?
Agile sages: Nokia will ask the second question: "If there is a product owner, do they have a product backlog to be developed? Does this backlog prioritize based on business value? Have you estimated how long it will take to develop these features ?".
A Jie: Oh.
Agile sages: This is the basis for a product owner to build a roadmap for a version release. If they get a positive answer, they will continue to ask "does the team use the burndown diagram during the development process to show the changes in the remaining workload during the current iteration over time, to track the progress? Can we estimate the team's speed based on the burndown chart ?"
A Jie: What is the significance of this question?
Agile sages: first, the product owner can build a release plan based on it, and the team can actually improve the process based on it. Only knowing how fast they are can help a team make better estimates and help them speed up their subsequent work.
A Jie: Well, there are already three rules. What is the last one?
Agile sage: The SCRUM team depends on the self-organizing process, which means that the team is responsible for selecting jobs, assigning responsibilities, and finding the fastest way to deliver jobs. Therefore, the final rule of Nokia is: In iteration, the Project Manager cannot interfere with the Team's work, because this will stop the self-organizing process and the process of obtaining a solution will no longer be optimized.
A Jie reminds me of the product owner's question again. He hurriedly asked: Why must a special product owner be required? Can I replace it?
Agile sages: first, the product backlog is the core of scrum. Basically, it is a list of requirements, stories, or features that are sorted by importance, it must be what the customer wants and described in the customer's language. The product's backlog should only be composed of the large tasks related to the product (ticket). It is not suitable for the tasks involved in completing a job in product development.
Agile sages: Second, when maintaining the product backlog, the product owner (that is, the person who can speak for the end customer) must attend and arrange the priority. The product owner must be the person closest to the customer. As a R & D project administrator, you cannot be the person closest to the customer. If you do not have this role, how do you know which one is important or not? Communicate with the product owner so that you can create a list with priority and put the most important functions before the list.
A Jie: I know. It seems that I have to assume this role with product manager. What are the requirements for this backlog entry besides priority?
Agile sages: Well, each entry should have an estimated completion time, which does not need to be accurate. We only need to have a rough estimate to determine how much work can be put into a sprint.
Agile sages: In addition, your product backlog should be in a proper format before you start the sprint planning meeting. You can put them in an Excel file, a Word document, or a scrum tool ...... You can use any form as long as you feel it is convenient.
A Jie: Well, I used excel.
Agile sages: in addition to your team members and product owners, you can also invite more people to the sprint program meeting.
A Jie: I thought I could plan the sprint by myself.
Agile sages: that is the old management model. Under the scrum framework, there is no "individual" concept, and scrum relies on the strength of the team. While the scrum master plays a very important role in this framework, it is not a dictatorship. Make sure that the entire team is involved in the Sprint plan.
A Jie: how to do it? Isn't it messy for everyone to make a plan together?
Agile sages: First, you need to set the sprint goal, that is, what you want to accomplish as a team, and then decide how much you want to accomplish.
A Jie: we currently have no historical reference data. How can we know how much we have done?
Agile sages: Calculate the team's working hours in a sprint in advance. For example, in the next three weeks, if a five-person group works for 40 hours per week, the total working time is 5 × 40 × 3 = 600 hours.
A Jie: the ideal situation is this, but someone will definitely take a vacation.
Agile sages: Yes, so you need to deduct the total working hours from any expected non-working hours. For example, a person needs to take a week's annual leave, and another person needs to take 3 days to check his teeth. In this case, it is 536-x 8-hours.
A Jie: Also, even if each person is working 8 hours a day, he does not really have 8 hours of work on the project. He also needs to participate in various activities such as tea talk, training, and team building.
Agile sages: How many hours do you have to work on projects if you have 8 hours a day?
A Jie: the average is about 6 hours.
Agile sage: You have to spend all your time attending meetings, talking, processing emails, and surfing the Internet.
A Jie: that is estimated to be 5 hours.
Agile sages: we use a percentage representation of 5/8, which is about 60%. Then we use this "load factor" to multiply the total hours of work, you get 536x0.6 = 322 hours.
A Jie: Well, this estimation is very practical.
Agile sages: Then, from the product backlog, select the entries that you think can be completed within 322 hours according to the priority from high to low as the backlog of your current sprint. Note: The selected sprint backlog item must be strongly cohesive and loosely coupled, so that you can be free from or less disturbed by the outside world and have a clear goal.
A Jie: should the "load indicator" 60% be changed? We just created a project, which is definitely different from the project after a while. For example, when I have a new employee, his efficiency must be lower than that of the old employee.
Agile sages: Yes. You have a good understanding of the load indicator, and you can use it to make the Sprint plan very accurate. When you encounter a low "load indicator", try to find the root cause, which will make your sprint more efficient.
A Jie: Should I refine the task in the next step? Estimate?
Agile sages: not completely correct, but task refinement, there is also a very important part: For each refined task, a very clear definition of "done" (done) is required. This is very important. We must ensure that everyone's understanding is correct and consistent.
Ah Jie: Well, otherwise everyone's estimation will be very different.
Agile sages: Yes! During estimation, you can use the "Planning cards" to estimate the completion time. Do you know how to use plan cards?
A Jie: I don't know. I think I can check it out.
Agile sages: Well, you should try this thing.
A Jie: What else is worth noting?
Agile sages: When refining sprint tasks, one best practice is to control each task in 2 ~ Within 16 hours. The task is too small and involves more micro-management. If it is too rough, the estimation will be inaccurate.
A Jie: OK! In this regard, scrum is the same as other project planning methods.
Agile sages: The next step is to let everyone claim the task, not assign it! This is critical. Remember it?
A Jie: Why claim it? The assignment is more efficient and allows everyone to do what they are good at based on their expertise.
Agile sages: first of all, after each person claims a task, they actually have a commitment to the entire team to ensure that the task is completed as planned. Secondly, let everyone choose what they are willing to do so that they will be more proactive. After all, "do what they are interested in before they can really do well ". This not only satisfies the individual's development needs, but also enables quick knowledge sharing and overall improvement of team skills.
A Jie: Yes. In the past, I only promised to a project manager. After such claim, I became a commitment to everyone.
Agile sages: In addition, just like any other Conference, it is important to determine the agenda of a one-day scheduled meeting. Because the sprint scheduled meeting must be based on time-boxed and must end within the specified time, just like a sprint, there must also be a sense of urgency.
A Jie: Well, I will plan it carefully.
Agile sages: Also, the Sprint plan meeting must be completed within one full day.
A Jie: Why?
Agile sages: The day when the Sprint plan meeting starts, that is, the day when the sprint begins. If the sprint planning meeting is going to take over two days, it's not a problem. Your burndown chart will be as ugly as ours. You will see that the sprint was just the beginning. It seems that our workload is only 150, and the next day, the workload is almost 190, and there is a bulge. If you do not know the story, you may think the Sprint has a problem. In fact, it was because we had four hours in the afternoon of the previous day and three hours in the morning of the next day to refine the task and increase the task estimation.