Respond to changes in the scrum Project

The adoption of Agile Methods in software development requires many organizational changes, such as corporate culture, personal roles, and processes. As an organization, to make agile changes, you must learn to properly handle these changes.

In this article, I have referenced agile, scrum, and lean theories. So proceed with caution. At the beginning of this article, I will clarify my definition of "agility. In my opinion, agility is a general term for many emerging project management theories that focus on iterative software development. The popular ones are lean theory, crystal method, scrum, dynamic system development method, and extreme programming.

Scrum and extreme programming, especially the combination of the two, are currently the most used agile methods. Although the definition of scrum does not contain any content about engineering specifications, we cannot separate the two. If you ask me what agile means, I will define it as follows:

Agile = scrum + XP

Recently, many thought leaders have successfully introduced lean ideas into software project management. In this case, it would be too stupid if I did not mention this part in the article.

This article is based on this.

This article outlines the possible changes in different roles in Agile organizations and provides some suggestions for better transformation from waterfall models to agile methods. The roles mentioned in this article are as follows: customer/stakeholder, product management, integrated management, project management, developers and Quality Assurance personnel. I am more specific about technical roles, mainly because my personal experience is more technical.

Agile Methods focus on implementation efficiency of short-term projects. For example, unlike the waterfall model, agile methods usually develop some software functions at two to four weeks. This system ensures team motivation and customer satisfaction through frequent "Inspection and adaptation" cycles. Agility has the ability to thoroughly subvert the positions and backgrounds of individual limitations, so as to maximize efficiency, personal potential and output. This capability leads to a software development strategy, and the resulting changes are reasonable: An Economic and result-oriented software development method.

Introduction

Most people do not like changes. I don't like it anyway. However, it is certain that adopting Agile Methods in software development requires many organizational changes, such as corporate culture, personal roles, and processes. As an organization, to make agile changes, you must learn to properly handle these changes. This article describes how new agile teams will change and how they can better adapt to this new and dynamic environment. In the agile organization involved in this article, the roles that may change are as follows:

1. Customers/stakeholders

2. Product Management

3. Comprehensive Management

4. Project Management

5. Developers

6. Quality assurance personnel

It should be emphasized that the information mentioned in this article cannot be applied to every organization, because each team operates differently and uses different skill systems. The changes mentioned below reflect my experiences in managing the development project of scrummaster. Now let's talk about it in detail:

Customer/stakeholder

In traditional waterfall model projects, customers and projects are usually at a certain distance, and they will only participate at the beginning and end of the project. We (development teams) force customers to speak freely. Because we clearly tell the customer that if there is any demand change after the project starts, the change process should be followed and the corresponding loss of the change must be borne. After we complete the coding process, it may be several months after the project was started that we found "we did wrong" Only when we delivered the code ". This method is the culprit.

Therefore, in agile projects, customers must work closely with the projects from beginning to end during the development process. In fact, agile projects embrace changes and welcome feedback from customers.

1. The customer is expected to participate and provide valuable comments in all aspects of the "Inspection and adaptation" of the project. This reduces risks and provides customers and stakeholders with a selection space. Note: customers are required to be part of the team in the extreme programming project.

2. At the planning meeting, the customer should work with the product owner to define the user story and give a detailed description at the Planning Meeting.

3. The customer should work with the product owner to set a priority for the backlog.

4. Customers and stakeholders should participate in the product demonstration at the end of the sprint. Based on the relationship between the customer and the product owner, the customer can even participate in the sprint review meeting.

Product Management

If you are a product manager for a project that is changing to agile, you will also change. First, your title is changed from product manager to product manager. But this is not all. Product managers in traditional environments are responsible for front-end work. In addition to their specific market responsibilities, the product manager is typically responsible for the product requirements documentation in the early stage. On the other hand, the product owner is the customer's agent. In agile projects, the following changes may occur when the product manager switches to the product manager:

1. The product owner is an active participant in the team. The product owner is responsible for the product direction and priority in the project.

2. The product owner should attend the Sprint plan meeting. The product owner is usually the main character in the first part of the sprint planning meeting. He is responsible for defining the sprint objectives and detailing the features of each user story to be implemented in the Sprint plan.

3. The product owner is responsible for establishing and maintaining the product backlog and giving priority to it.

4. Unlike the traditional concept, the product owner must ensure that he/she can stand up when the team needs him/her. Whether the product owner needs to attend every daily standing meeting is controversial. However, the more product owners participate in the team, the more likely they are to succeed.

5. the product owner is also responsible for defining acceptance test standards to a certain extent. In this regard, it also means to be somewhat responsible for the output quality of the product-because, in essence, the acceptance test criteria will make quality an important part of the development team from the very beginning.

Therefore, as the product owner, we are waiting for you to participate more every day. Let's have a big fight.

Integrated Management

Since agile teams should be self-managed, what is the responsibility of comprehensive management? I hope the following content will be helpful.

1. Managers should be able to assume the role of a evangelist for the team, especially if managers have experience-but it is difficult to say exactly what experience they have. That's why Toyota wants its chief technician to be the product manager. Such support can help the team avoid mistakes and save a lot of time.

2. Managers should bear the brunt in the face of difficulties. For example, they should help scrummaster solve the "big" obstacles that need to be addressed by the management, such as approving project operation funds to ensure that the team can move forward.

3. The new team needs the support and approval from the senior leadership to bring the agile process on the road. The team can easily slide back to their old track, so managers must support the team so that they can stick to the agile path.

4. Managers should also be "coaches" who help team members with career planning, performance evaluation, training or organizational training.

5. Managers should pay attention to the company's long-term strategic initiatives (such as how to deal with competitive threats, promote sales, and reduce spending ).

6. Based on strategic initiatives, managers should work closely with the product owner to determine the "big article system", identify the priority, and plan the product for the long term.

Project Management

In essence, scrum does not have the traditional "Project Management" role. What does this mean for employees? In most cases, the Project Manager will naturally turn into a scrummaster. However, believe it or not, good scrummaster is always developed or tested. Believe me, scrummaster is not very similar to a project manager. Therefore, it is important for the scrummaster candidate to attend some training courses. Although scrummaster authentication is not required, it is still very beneficial. So what do you expect from this role change?

1. As a scrummaster, you must first acknowledge the fact that the team is the master of the progress, so you no longer need to update the Gantt chart of the Microsoft Project, a long-standing tradition. Instead, you have to move back to the second level, but at first you may have to stare at the team and ask them to update their estimates every day.

2. As a scrummaster, you must ensure that the entire team follows the scrum process well and that everyone understands what scrum is and how it should be done.

3. The team will expect you to scan the obstacles as quickly as possible or help them clear the obstacles.

4. You have to reiterate the goal of the sprint at each meeting to ensure that the team is fully committed to the end.

5. you will organize daily standing meetings (a daily meeting where everyone needs to answer the three questions about what you did yesterday, what you are going to do today, and whether there are obstacles ), make sure that the meeting is held at the same time and place.

6. You have to ensure that the essence of scrum, especially inspection and adaptation, can be executed very seriously so that Scrum can be used as benign as originally designed. This allows the team to learn and improve in each sprint.

Now let's take a look at the changes in the lives of developers and testers in Agile (scrum) projects. To be honest, I think with those two specifications, both developers and testers will benefit from the agile transformation and make their lives better.

 

Developers

Developers love to do things in the right way. They will oppose shortcuts. They hate being forced to write code that is actually useless. Just like in daily life, agile transformation can be completely completed after some repetition. So even if there is only one tenth of bad code there, you should pay attention to it. The biggest change for developers in the agile (scrum + eXtreme Programming) transformation process is engineering specifications, or strictness, which has been elevated to the highest level. So what do you get?

1. You no longer need to estimate tasks independently. This proved to be the most difficult activity, and should be done by the team through playing program poker. The result is that you can get better estimates and have broader insights into them. In addition, you no longer need to take full responsibility for poor estimates.

2. You must learn Pair programming. If you are implementing XP practices (strongly recommended), you will often do this. This requires developers to make a big change in their mindset, because this is the first time you have been forced to publish your code for peer review. That is to say, you may be judged at any step in the process. It was hard at first, but the benefits were huge. As a result, you will become a better programmer, I promise! Your code will be of higher quality and easier to maintain.

3. You will no longer write the code over there, waiting for the tester to find a bug for you. Agility is built on the premise of sufficient output and maintains the motivation of the development team. quality must be built from the very beginning. So you are going to learn how to write unit tests. You will learn about test-driven development. As an engineer, your skills will be tested to produce as good as possible, high-quality code. The return is very high. Believe me.

4. You should participate in the complete point-to-point interaction. This will let you see the other side of the matter, because you are also a participant in the first user story seminar. Therefore, you will learn first-hand issues from customers and product owners because they have detailed the user story at the sprint program meeting. You should also be a member of the review meeting at the end of each sprint, So that you participate from start to end. You can propose good places and bad places to improve your performance in the next sprint.

5. You no longer need to work overtime. In fact, if you fully execute scrum, you don't need to work overtime at all. By tracking velocity, you can set the maximum value that the team can produce, so that you can manage how much work can be arranged at any given time point. Too many jobs are arranged at a time, resulting in delivery being lower than expected. Our agilebuddy Team (agilebuddy is an agile project management software jointly created by me. It can help the development team to make agile changes and manage their software development projects) launch products every two weeks, never failed. We achieve this by optimizing enough workload. We can learn a lot from lean thinking and the Toyota Production System.

6. If you are a supporter of the process, you do not have to worry about "Death marching" or "busy fighting ". On the contrary, at the end of each sprint, you will be very proud of what you have done and do not want to use other methods. This requires all stakeholders to recognize this new process from the very beginning (this also refers to a prerequisite for successful agile projects ).

7. At the end of each sprint, you have the opportunity to show what you have done-icing on the cake. This is the time for sharing, not hiding. This is different from the waterfall model project. In the waterfall project, you never know where or when a bug may occur.

8. You will fight for each milestone as a whole. No longer me. On the contrary, you will find every opportunity to help team members as needed.

Tester

I spent most of my career working in the waterfall model environment, so I am no longer familiar with this "death march. This will inevitably lead to reduced QA testing time.

Fortunately, like developers, this situation has also changed through Agile Methods for testers. How is it implemented?

1. participate in each sprint from the very beginning. You may wonder what value a tester can provide early in the project. However, since you have to attend the Sprint plan meeting, you have the opportunity to directly hear the user story plan. In fact, you will be involved in the process of developing a detailed user story. For example, you can help determine the acceptance test criteria of the user story. This further helps developers better understand what they need to do to pass the test. As a result, the quality and accuracy of the released Code (for example, the Code and the degree of conformity that the end user needs) are significantly improved.

2. You will participate in the poker program to help estimate the size of the user story. Participating in the estimation process means that the company can better and more comprehensively estimate the complexity of the user story. This makes the estimation more accurate, the plan is better, the pressure is reduced, and the team morale is higher ,? Work will be more enjoyable.

3. You will participate in the unit test creation process. This is a good way for testers to enhance their skills. Testers can also bring a lot of value to the project through their analysis and mentality of "how to destroy it.

4. You should automate functional testing as much as possible. In this way, you will contribute to the overall efficiency and productivity of the team. As mentioned in lean theory, the team should pay more attention to quality building and minimizing waste, because compared with other factors, this is more conducive to improving the production cycle (from concept to practice ). Therefore, you write automated tests to contribute to the overall quality of the code library, thus shortening the overall cycle.

5. In the team, you will become a respected member, rather than a second-class citizen who only has the "Stop assembly line" (Toyota product system) permission. For example, any detected defects should be promptly resolved, even in the early stages of the project. The agile concept solves traditional project management problems by establishing a cohesive team and treating each functional field as development. In fact, there are only developers in the scrum Project (that is, if you are a tester in the scrum project, you are another developer who gets the delivery results on the sprint backlog ).

6. Because developers start to write unit tests, you will no longer receive a lot of ugly code. So now you can focus on more important aspects, such as testing boundaries and boundary conditions, as well as automating your unit tests.

7. Scrum, eXtreme Programming, and lean practices all expect that all code to be delivered will be completed at the end of the sprint (that is, through unit testing, functional testing, and integration testing ). Then you will have time to complete each sprint, because all the work (including testing) is described in the Sprint plan-not just to mention, for example, the last three weeks of the project were used for testing.

As the Agile Methodology is deeply rooted in the hearts of the people, testing is undoubtedly becoming more mature, and testers in the industry have gained more respect than they used. Testing is now an essential part of developing excellent software because it ensures that the software is developed based on the expected functions. Based on some concepts such as TDD and BDD, the testing work has been transformed from a traditional backend process to a front-end process. In this way, quality has been established from the very beginning. I am confident that this is the number one reason for improved software quality, improved customer satisfaction, and more proactive development teams.

Conclusion

Agile improvements to the development environment allow you to maximize your team's potential and turn it into an incredible and efficient software development cycle. It also takes into account the personal efficiency and productivity factors in the software development process, and weakens the company-level constraints to better support functional teams. Turning to an agile organization and adopting the scrum method requires that all departments of the software development team work together and are willing to make changes. Initially, the change with scrum implementation seemed painful. The technical details of the change are easily disturbing, and the focus of the change is lost: the transformation of software development methods will eventually become more effective. Yes, I have summarized some guidelines to help you through this process. Based on the changes discussed above and the understanding of the mentality behind this move, this transformation will become an intuitive step for High-yield software development companies, rather than crossing the river by feeling the stones, discover the journey of the dangerous field. So no matter whether you are in close contact with agile for the first time, are gradually accepting or have adopted it, I hope this article will show you how to better handle a series of changes in the scrum project.

Author profile:

Jack milunsky, co-founder of brightspark, chief operating officer and scrum master. Agilebuddy is an agile project management software that helps development teams make agile changes and manage their software development projects.

Reprinted: http://tech.it168.com/a2009/0921/733/000000733750_2.shtml