Cultivate agile attitude

Document directory

• Growing agile developers
• Agile coaches
• Eliminate potential problems
• Conclusion
• About the author

There are already many articles on Agile Methodology. A considerable number of articles address technical issues of agile methods, such as test-driven development and continuous integration. Similarly, a considerable number of articles have discussed the application of agile methodologies, such as release plans, tracking productivity, and how to use metric data to "tune" the process ", even convince business personnel in the company that a special approach is needed. After reading these articles on agile methods, it is easy to feel that by purchasing a set of tools and following a series of seemingly simple practices, even if agile methods like eXtreme Programming and scrum are adopted. However, real-world experience shows that successful adoption of agility is much more complicated than that. It involves how to cultivate correct attitudes to build trust, encourage communication and collaboration, and ultimately make people more adaptable and efficient.

Agile methods are often described as people-centered, rather than focusing on technology, and there are good reasons to illustrate this. However, although the agile Declaration highlights the importance of "individuals and interactions are better than processes and tools", it does not clearly clarify how to deal with this important social dimension. In businesses that emphasize technology, these are too simple to generalize the strong influence of personal attitudes in the project team. If we want to know which attitude can promote (or obstruct) agile adoption, we have to ask: "Can we find out the difference among successful developers and managers ?", The more important question is, "What attitude is driving these behaviors ?"

Growing agile developers

Many developers are used to working independently and spend most of their time reading standards and completing design and coding. In the previous agile environment (pre-agile environment), some developers even wear headphones to listen to music and do not listen to "noise" from the office ". Developers who adopt eXtreme Programming discover that they have already integrated into a more social environment. In this environment, success depends on closer collaboration with peers and customers. In addition, the classic previous agile development is the design and coding that individuals "own. In an agile environment, work tasks are jointly determined by the team: No one can own a piece of code alone. Such adjustments may be especially challenging.

People who are new to agile development may be used to projects that divide themselves into subsystems for development. They are used to taking charge of the design of a subsystem independently based on the high-level specifications of the interconnection between subsystems. Developers who have just touched the ownership of collective code are easily intimidated by the amount of code they have to master. At the same time, few technical documents (or even no technical documents) and rapidly changing code baselines (including those familiar class names and method names may change in a short time) this situation may be aggravated. However, Agile Methodology (especially eXtreme Programming) requires programmers to have strong coding capabilities. By observing inexperienced and experienced agile developers, we can easily see that attitude is not only a skill issue, but also a critical issue.

Traditional team	Agile team
Subsystem ownership	Collective code ownership
One-time Design	Incremental development
Comprehensive and complete understanding of subsystems	Discovery
A large number of advance designs and "result management"	"Technical prototype", testing
Comprehensive documentation	Automated Testing
Ensure Quality by analyzing the entire design	Test-driven development to ensure quality
A comprehensive analysis is required	Explore and limit relevant information (For example, code coverage, small tasks, and priority Division)
Personal design decisions	Form and respect team consensus
Results from scale or complexity	Reduce the size or complexity as much as possible
Pre-determined, try not to change the design	There is no end to design, it is easy to change, and change is a learning opportunity.

Table 1: Comparison between traditional teams and agile teams

Table 1 lists the differences between traditional teams and agile teams at the code level. Experienced agile developers have different coding methods. They tend to be flexible coding, rather than waiting until the entire design is complete before development. In addition, they tend to regard coding as an opportunity to learn and explore. For example, when a problem occurs, they always write a small concept verification model or "Technical prototype (spike solution)" to make the problem specific, instead of building a complex model or describing various behaviors through natural language descriptions. Likewise, agile developers prefer to read Third-Party code. Sometimes, they want to make improvements as much as they can; sometimes they just want to learn a new design method. Finally, we try to make classes, methods, and potential method call chains independent of each other, so that only partial code can be solved, in this way, you don't have to spend a lot of time studying the entire subsystem or application. All these differences allow developers to better discover and handle problems in coding, rather than simply using superb coding skills to complete tasks.

Use Pair programming as an example. For teams that adopt Agile Methodology (especially eXtreme Programming), Pair programming is one of the most controversial issues because it requires two developers to complete the same piece of code together. Although a developer may have outstanding design capabilities and be proficient in the Development Platform, as an efficient XP developer, he must also be able to communicate ideas, collaborate for testing, and provide possible implementation solutions, and reach consensus on an implementation strategy. Many developers don't want to perform Pair programming, not because they don't code, but because they are not familiar with Pair programming. One Developer wrote in his blog: "Pair programming will expose them to their real knowledge and skill levels ". When programming independently, others will only see the encoding result. In Pair programming, unexpected start and early errors will be seen by others. At this time, there will certainly be a sense of pressure, even for High-Level developers, it will take a while to get used. It is worth remembering that when you understand other team members and are familiar with the personality of each participant, Pair programming will become easier.

Most successful extreme programmers are interested in programming in a variety of languages and learning new design methods, especially reading existing code. These successful developers are willing to "practice" coding by trying to do some small exercises. They may compile some gadgets or participate in open-source projects to conduct experiments. Here, it is very important to emphasize "practice. Good agile developers often learn knowledge and skills by doing things, not simply reading and learning about it.

"Extreme programming is Communist ......" This is the far-fetched explanation of a developer's Pair programming. He mentioned that coding in XP has shared their experiences. He laughed at "collective code ownership ", and sneer at the fact that all developers can work in all fields to write any part of the code. After chatting with this developer for a while, I realized that his idea was actually to compete with others to keep his "Rice Bowl ". He worried about the competition between the same team and different teams. Working with others means allowing others to see how they solve the problem and what tools they use, which gives others the opportunity to learn his tricks. His dislike of Pair programming shows that the agile team needs to solve the issue of heroic development and "Rice Bowl. Pair Programming naturally makes developers open their minds to colleagues, share their domain knowledge, and are always ready to share your methods with you.

A highly confident developer may also leave this method of Pair programming alone. Sometimes this happens when a Member is working independently to increase the production rate. In addition, when one developer has poor abilities, another developer will turn "pairing" into "personal Show ". In other cases, a developer may be eager to complete the task. For some personal reasons, the developer may be eager to complete the user story as soon as possible. The most obvious reason is "Ambition ": try to become a team leader by demonstrating technical skills or gain other opportunities for promotion. Such an attitude can easily make the pair fade into a "scoring Competition". The goal of the competition is to see who can win, rather than trying to complete meaningful work.

Too few voices may also be a problem. If a developer seldom takes the initiative to care about his pairing tasks, he may be led by his partners. In this case, the developer actually gives up a lot of responsibility for design and code quality.

Agile coaches

So far, we have only discussed common practical issues in developers. However, creating and maintaining an agile development team is also the most important responsibility of coaches and other leaders. These leaders must establish a set of good examples for their team and become real coaches, rather than team members with only the title of "Coach.

One of the most effective leadership skills is to build a set of good examples. The development team will establish a set of rules, for example, all product code should be written in pairs, and all product code should be written for testing first. Only when the team members believe that these rules are very important can these rules take effect. However, it is really easy to "do it. For example, the Team Leader announced to the team members: "If the build fails, the most important task we have now is to fix it ." I will believe it as I heard it, but the following is not the case. "I first discovered this problem and I should have fixed it, but I am too busy ." His actions have greatly reduced the importance of the incident. Others may think that building may be the most important thing or not. As a team leader, it is common for others to see that he is working with a developer to fix this build. This can further demonstrate to the team members that building is a very important task.

A good coach not only knows how to teach developers skills, but also encourages developers to think and collaborate efficiently. This is somewhat similar to the scrummaster role described by Ken schwaber, that is, this role is responsible for encouraging team collaboration. This is not a good signal when the coach refuses to explain and uses his knowledge to solve the problem or leads the team with command.

I think it is best to ask a person to serve as a "Coach" to help the team, instead of being a fixed member of the team. If a coach is a fixed member of a team, there may be conflicts of interest: Sometimes he wants to help the team members to improve the team's ability and efficiency. Sometimes he wants to objectively evaluate the team, make some comparisons between team members. As Kent Beck mentioned in his book "Extreme Programming explained", a coach should have a goal, that is, to help the team grow and eventually reach the goal of no longer needing a coach. A good coach needs a certain degree of self-confidence and emotional control, as well as technical skills and experience.

Eliminate potential problems

There are several potential factors that negatively affect the team attitude. Some team members are worried that their team leaders only make changes to further achieve their personal goals, rather than to make the team better. Another reason why some Members are unwilling to face changes is that they are reluctant to express themselves. Another particularly troublesome question is: who doesn't like being praised and can criticize others? However, what we really need is to accept criticism and study modestly.

In the software industry, many innovations can be rewarded by individuals. Writing and speaking at meetings will obviously improve your personal image. Technical leaders, coaches, or people in the same role are in a position where changes can be introduced. We should be aware that, while we encourage innovation, changes may also be disruptive or put more pressure on teams that are already working efficiently. Therefore, it is much better to review and find a solution with the team than to announce an improvement strategy by the leaders.

"It is much better to motivate the entire team to embrace changes than to use the power to execute some changes that are beneficial to themselves and their businesses ". It is very important for leaders to recognize this point. As a developer complained, "doing so can only make us more sad. They only want to use meetings to make them look more powerful ." He believes that in his team, only to make one or two authoritative people appear more professional, he will impose some kind of innovation on the team, or even ignore the daily tasks that will make Software Delivery more difficult to complete. So another key point is to realize that everyone needs stability and security, and too many changes will shake it very quickly.

However, sometimes it is obvious that people have become deeply opposed to the undiscovered changes. No matter how many people's worries have been cleverly mentioned, there will still be more and more worries emerging, which is a frequent occurrence. It is very likely that those who raise personal concerns have some personal or motivation problems that need to be improved. This is a good thing, but it is not always comfortable to say so. For example, many people may raise technical and business objections to extreme programming. Few people will admit what really bothers them. For example, you cannot hear: "Using XP means a fixed working time, so I cannot pick up my daughter at school ."

When a team member finds that they may want to use a new technical platform to build products, the same thing will happen. Some developers strongly oppose this because "we need to consider more technical issues, such as scalability, learning and maintenance costs, and tool quality ". A few months later, we will find that the real reason is that many developers do not want to spend time researching the mentioned new platforms, because they feel that learning new technology platforms will prove that their individual learning abilities are not good. From a professional perspective, although career development, employment ability, and work-life balance are both normal problems, it is still difficult for individuals to eliminate such concerns.

The last potential factor in developing agile teams is the need for modest morality. In agile teams, modesty has many advantages. One is that it reduces the possibility of "Point Scoring" competition against productivity. This is exactly the same mentality as "doing the simplest thing" in xp. As Steve McConnell pointed out in code complete, it encourages developers to write code with higher readability. When you want to criticize others, especially when they are trying to Adopt agile methods, you should learn how to maintain a modest attitude. Although others have shortcomings, this is important when you see a shortcoming and ask yourself "Have I ever made the same mistake. You may not be able to correct others' shortcomings, but you can certainly learn from them.

Conclusion

Developing an efficient attitude and working style in an agile team is a complex and critical activity. Many people trying to implement agile projects focus on their businesses. Although the business is very important, remember that all stakeholders of the project are people. They also have their personal needs and concerns. A successful self-organized project team requires every participant to be able to promote improvements in all aspects in good faith. Agility is not "governed", but agile can be developed if the Initiative team members are given the freedom to organize themselves.

About the author

Dafydd is a software developer who focuses on Agile Methods and object-oriented development. He hopes to discuss it with everyone. Put the feedback on www.dafydd.net/feedback.php.

View Original English text:Cultivating agile attitudes