This article is the English blog play turn translation of the first, the follow-up will be intermittent for this kind of quality English blog play turn translation activities, pure play, personal play, please continue to pay attention to, a lot of support.
If you are not familiar with Scrum, I recommend reading my article On How to Look at the Scrum Framework to get some basic background before reading this article, otherwise you will be confused. The link to bolg is as follows:
Five Questions Scrum Master Should Be Able to Answer
The Scrum guide tells us what to do to practice Agile but not why. Moreover, the Scrum guide does not tell us what not to do when practicing Agile. As Agile coaches, we are often asked challenging questions by Scrum teams and project stakeholders. If we simply follow the Scrum guidelines and give a general explanation, we may not be able to satisfy the concerns of the questioner and may lack independent, deep thinking. In this article, five common and challenging issues in Scrum practice are selected for in-depth analysis, in the hope of attracting more depth and breadth of creative insights.
1. Why do we all go to sprint meetings?
That’s a good question. That’s a good question. In traditional waterfall project management, the project manager consults key project stakeholders and the backbone of the development team, and then develops the project plan on his own. So the question is, why do we need 10 people to do what one person did before? Isn’t that a waste of personnel? We use the Scrum guidelines to limit sprint sessions to a maximum of 8 hours a month. Assuming a team of eight development engineers, the additional investment in sprint planning is 64 people per month that could have been used to do the actual coding and testing.
My previous Scrum team initially felt that sprint planning was a waste of time that was more valuable than writing code. Therefore, in each sprint planning meeting, the product owner and I would go through our product list items as quickly as possible to minimize the time of planning meeting. A few weeks later, during our sprint review, the development team told me that they wanted to spend more time understanding user stories and requirements details before writing code. I immediately made some improvements to the sprint plan, restoring the proper length of the plan meeting, discussing with the product owner how to present each user story more clearly and in detail, and encouraging the development team to ask questions so that we can better discuss and clarify the points of the user story. Practice has shown that taking sprint planning seriously will not only not waste coding time, but will actually increase sprint speed.
The improvement approach adopted by my previous team was supported by theory. The Scrum guidelines clearly state that sprint planning sessions can be used by Scrum teams to clarify and refine backlog product list items to increase understanding of user stories and confidence in completing tasks.
We asked all Scrum team members to participate in the sprint meeting. A further consideration is that the Sprint meeting helps the Scrum team understand why they are implementing the user story and what the value and meaning of the user story is. Instead of being passively told what needs to be achieved, sprint planning helps Scrum teams engage in requirements discussions, design solutions, and understand the history and context of user stories, which greatly motivates the team and increases its autonomy and initiative. At each sprint meeting, our first priority is to determine the sprint goal. In his 2014 book Scscrum -The Art of Doing Twice The Work in Half The Time, Jeff Sutherland points out that great SCRUM teams seek to achieve common goals, and once they do, Will spontaneously adhere to the basic criterion of team goals over individual goals. He also points out that small, seemingly small teams can become magical when they reach a common goal. This is a qualitative leap. Efficiency will improve, quality will improve, collaboration will flow more smoothly, and job satisfaction will be higher. More often than not, the coding was outsourced or assigned to a few developers who had no idea what they were developing or why, and wrote code with too much confusion. The output of such a team can be expected to be a far cry from the output of a great Scrum team. The sprint goal set by our Sprint planner is to answer the why question and is a great motivator for the Scrum team.
2. Why do we organize sprint reviews?
Similar to the sprints, many developers think that a 3-hour sprints review is pointless and better used for coding and testing.
After world War II, Kaizen, the Japanese idea of continuous improvement, was widely used in manufacturing industry and achieved good practical results. This theory advocates small, continuous, and incremental improvements to an enterprise’s current existing processes to improve the quality and productivity of product delivery, rather than designing new processes and specifications.
Kaizen ideas have had a profound impact on agile principles and practices. There is a line in the Agile manifesto that says,” Teams regularly reflect on how they can improve their performance and adjust their behavior accordingly.”
The three pillars of Scrum are transparency, review, and adaptation. Therefore, Scrum teams should be open and honest about what they are doing. Constantly discuss and reflect on how to improve, what can be done better, and take specific steps to optimize processes and practices. By doing so, you are actually practicing sprint review.
In my traditional project manager role, I was diligent in organizing the project team to review the lessons learned at the end of each project. We are very careful to collect and summarize about 50 improvement measures. We are sure that these steps will help us avoid detours in new projects, but unfortunately, the lessons learned will never see the light of day once they are archived in a designated database. To be honest, when I’m in charge of a new project, I never go to the project database to look at the lessons learned from previous projects. It’s something I’ve never even thought of, let alone done.
Sprint retrospectives are similar in nature to lessons learned, except that sprint retrospectives run throughout the project cycle, at the end of each sprint, and are more effective than lessons learned reviews. Improvements from the sprint review will be added to the next sprint list to take concrete actions to improve the product build process.
The Scrum teams I was on were not very motivated to organize sprint retrospects, but as they found their voices heard and their pain points addressed, their attitudes and perceptions changed. Sometimes when I forget to schedule a review, they start reminding me.
3. Why do we have to deliver a potential releasable increment at the end of each sprint?
Have you ever seen a situation where, as we move into the next sprint, we just continue to complete the unfinished tasks of the last sprint, and sometimes they’re so much unfinished that we don’t have the time or energy to complete a new user story? This phenomenon is not uncommon in agile teams, and not only does it violate the spirit of the Scrum guidelines, it can lead to many other problems.
- Speed is the amount of work done per sprint. If nothing is done in a sprint, the rate is zero, which will definitely have a negative impact on the next sprint.
- The Scrum guide states that each sprint has a good goal and is a separate little project.
- This sense of purpose motivates the team to deliver valuable product enhancements before an upcoming deadline.
- Towards the launch date, the team was more motivated and energetic. If there is no value to be delivered at the end of the sprint, morale will suffer, and project risk will increase, leading to the traditional waterfall development model.
Delivering a potentially releasable product increment at the end of each sprint serves several purposes. As mentioned earlier, it motivates the team and gives you a sense of accomplishment. As the parties involved experience tangible delivery value each time, they become more and more confident in the project and the team. A learning and growing experience for the Scrum team. If the delivered product increment is not in line with the actual needs of the stakeholders, the team can fix and improve it early in the project. Avoidance and reduction of understanding bias will help stakeholders to define and clarify subsequent requirements more reasonably.
4. Why is a product owner different from a business analyst?
This is also a good question. Both product owners and business analysts need to master a number of key skills. Have a strong understanding of the functionality of the product, understand the value the product delivers to users, be responsible for the collection, collation, and instantiation of requirements, and identify requirements dependencies and contradictions. However, there is a difference between the two. The business analyst is more of a listener, while the product owner is more of a decision maker. The Scrum guidelines state that “in order for product owners to succeed, their decisions must be respected by the entire organization.”
In my experience, very few organizations give the product owner sufficient authority to make decisions. The product owner’s role on a Scrum team is, for the most part, similar to that of a business analyst. This can lead to a lot of problems, such as details of requirements being asked in Refinement meetings and planning meetings. Product owners may not be able to make decisions because they aren’t authorized to do so, and they need to talk to interested parties afterward to get answers. Because the product owner is not authorized, an issue that can lead to a decision within minutes can take days to reach a final conclusion.
The product owner role is critical to the successful implementation of Scrum. Any organization that is transitioning to agile needs to take it seriously and carefully.
5. Why can’t we plan the scope of requirements for each sprint in advance?
At first glance, it is possible to plan sprints ahead of time and indeed many so-called Agile teams do so. The idea of meeting a fixed scope of requirements by a delivery date is highly alarming, as such planning can have an impact and even lead to changes in the management team, end users, senior management, and other associated projects. There is nothing in the Scrum guidelines that prohibits such fixed schedule and scope planning, but there is nothing that says it can be done. The Scrum guidelines simply define that sprint planning is the first event in a sprint. This planning event is for an upcoming sprint rather than a further sprint.
Defining the scope of requirements for future sprints in advance can cause problems. These early planning conclusions are taken as commitments by the Scrum team, which in turn slowly act as deadlines and generate a series of delivery milestones. So what we call agile iterative development becomes essentially traditional waterfall development.
Second, one of the great benefits of agile projects is their ability to respond quickly to changes in business models, markets, and technologies. This rapid response applies to the scope of the project as well. As the Agile Software Development manifesto says, “Requirements change is welcome, even late in the development phase.” With agile projects, we are more concerned with a product that can be accepted to meet current needs, rather than a product that will be needed a year ago or a year from now.
So what happens if we plan and commit to the sprint? Once requirements change, we must go through a formal requirements change process to assess the impact and cost of the change. We’re definitely doing waterfall development again instead of agile.
Without a doubt, a true Agile sprint should be one development sprint at a time. Anything else that is superfluous undermines the team’s agility and takes us back to the waterfall approach.
I am always grateful to the team members and the parties involved. For challenging me and asking difficult questions for me to answer. I believe that these are the questions that provide us with constant impetus to think deeply about agile frameworks and to explore better practices and practices.