Agile development-4 agile series: how to promote agility (on) (without me, no one, no sentient beings)

This is the fourth article in the agile development series. (One, two, three, four, five, six, seven, eight, nine)

There are several innovative aspects in Agile development, or although some of the previous methods may have been involved, they have never been promoted to a "fundamental approach" like agile development.

One is "embracing Customer Value and Embracing Change", and the other is the integration of development and testing represented by TDD/Pair programming/automated testing, one is self-organizing team practices such as "team collaboration/Pair programming/Joint Estimation/code ownership", and the other is that collaboration is more important than process, and communication is better than document.

Dilemmas of traditional development

Before agile development, although there is no written statement, the relationship between customers and developers is a game, and both sides should be cautious. For example, the requirement must be signed and confirmed before development can be implemented. The plan should be finalized and supervised in advance, and the change should follow a strict change process ......

Developers and testers are also basically two categories of people. There is a classic assessment method that makes these two categories difficult: "Each time a tester finds a bug, the developer deducts N yuan, testers get N yuan. "The opposite, zero-sum assessment method makes it impossible for the two teams to sit together and discuss how to improve performance together.

Traditional assessment is often used to assess individuals. As a result, there are often situations of busy and idle lives, the voice of the keyboard is heard, old and dead, one person leaves the company, and the whole team is ruined; agile development advocates the entire team to work together, solve problems together with collective wisdom, and improve productivity.

Agile competition

I do not think this kind of breakthrough in Agile development is the result of profound reflection on the entire management. On the contrary, it is the natural result of ignoring all useless systems and "making profits" wholeheartedly.

The demand development and change process is nothing more than to get a return by delivering value to the customer; development or testing is nothing more than to improve product quality; assessment is nothing more than to increase productivity.

Complicated documents delay the customer's signatures, or spend valuable time and energy on evaluating and resisting the customer's changes, and do not return. The game between developers and testers, it is nothing more than letting developers develop bugs that cannot be tested by testers for customers to discover. Personal assessments lead to a decline in the total productivity of the actual team.

The agile development team found that if we can break through the boundaries of developers, the inventor of agile development, testers, development/testing teams, and even enterprises/customers, the benefits of everyone are taken into account, and the results cannot be considered.

This shows why agile development thinks collaboration is better than process and communication is better than document.

The major purpose of the process and documentation is to complete the handover and clarify the responsibilities during cross-person/cross-department work.

Collaboration and communication discard the "redundant intermediate product" of handover and responsibility, so that the responsibility is always at the same time shared by everyone..

No me, no one, no sentient beings

The so-called "no" means you cannot persistently think that your own interests and performance must be taken into account independently and can be upgraded on your own.

The so-called "nobody" means that the interests of others cannot be opposed to themselves, but they must be unified and improved.

The so-called "no sentient beings" means that you cannot persistently consider the interests of small teams and constantly expand the concept of a team. Whoever considers it will respond positively, the benefits of everyone may increase together.

The basis of the three is to achieve no-Me first, so hereIt is called "No-me" to describe the boundaries between yourself, other team members, teams, and even customers and take their common interests as the starting point..

This kind of "NONE" is not formal. For example, some agile developers say that they are responsible for customer value, but not for the interests of testers and product managers, that is, they only learn the form of "NONE.

Return and do not attach to return

Neither I nor I care about my own interests is a matter of code. Instead, I say that if I can comprehensively consider all the interests, my own interests can be fundamentally guaranteed.

However, if you attach to your own reward when considering all the benefits, it is another kind of self-execution (that is, attach to me ).

In the next article, we will also talk about the dialectical relationship between return and not focusing on return, especially those situations where "the company cannot get a return.

 

Click to download the free agile development textbook: Martian agile development manual