What is "Agile" in Agile Development?

Image Source: Cybermedian

It has been almost a year since I first learned "Agile." In the beginning, I made a PPT and shared it with the team, but my understanding was rather shallow.

After a year of practice and cognitive learning, my understanding of it has changed from a conceptual understanding to one that can be integrated with teamwork.

I. Interpretation of Agile

Agile is the ability to create a product or service that captures value regularly and embraces change in a turbulent environment of uncertainty.

We need to pay attention to some of these keywords, such as capability, regularly, value, and uncertainty, and now let's interpret them one by one.

Firstly, agile is a capability, not a methodology or a way of working; it is a masterable capability.

Secondly, agile is not a methodology or a way of working, and it's a masterable capability. Agile permeates the product or service and exists with the life cycle, not at a certain time.

Thirdly, agile is regular, not a one-time thing. We all go through iterations of product or service optimization because the market and user needs are changing. So, instead of creating the perfect product or service, the team should keep improving through version iterations.

Fourthly, about value, Agile focuses on customer (that is, the ultimate stakeholder) satisfaction, which also corresponds to one of the values of Agile (customer collaboration over contract negotiation).

Finally, regarding uncertainty, turbulence, and change, Agile stabilizes plans flexibly while adapting to change for urgent tasks inserted from outside. While the specific content of the latter tasks is unpredictable, for team agile, there is a need to set aside space for such situations that can be responded to.

II. Values of Agile

In this part, we will introduce the 4 values of Agile in detail, which can also be understood as 4 criteria to guide the team to be Agile.

1. Individuals and interactions rather than processes and tools

Emphasis is on the good collaborative office tools are not as good as the instant communication between team members, whether they are now using Slack or other products for collaborative office scenarios or directly using FB, Ins, and other products that collect daily life communication, or using OA and other process products.

Tools and processes can improve efficiency to a certain extent. Still, these processes and tools are a "guaranteed" utility in the event of some major things or more urgent things, or face-to-face communication costs less than the use of tools for communication, more individual interaction, and the formation of such habits, is a better choice.

2. Software for work rather than detailed documentation

In daily work, we will see the product manager's requirements document, design colleagues' documents, development colleagues' technical solution documents, etc. An important role of these documents is to communicate information as far as possible to reduce inefficient communication costs. The output of these documents, we all have the corresponding work software, such as product managers commonly using Axure. For documentation, work software is more meaningful than detailed documentation.

Early requirements documents are actually in the form of word documents, but now with the development of the industry, some work software gradually into the field of vision. These tools are similar to the steam technology of the industrial age, solving the same problem, but can significantly improve efficiency. In terms of cost and benefit, the final result is a higher input-output ratio and, thus, more recognized and trusted by users.

3. Customer cooperation rather than contract negotiation

Making money, or achieving economic returns, is the goal of every enterprise, and it can even be said to be the primary goal of most enterprises. However, from the perspective of sustainable development of enterprises, to achieve sustainable economic returns, we should not only focus on contract negotiation, i.e., we should not only focus on the economic returns brought by certain cooperation, but also focus on the customers with whom we cooperate, and how we can achieve long-term cooperation with them.

SaaS products, for example, are focused on customer renewals, not first-time purchases. If you only focus on single cooperation but not long-term cooperation and do not provide a quality product or after-sales service. Not only can we not get continuous cooperation from customers, but also the reputation of the company will be damaged as a result, which will have an immeasurable negative impact on the whole industry.

4. Respond to changes instead of following plans

Every time before the start of an iteration, the product manager will develop a product iteration plan with the technical and testing leaders. But in the process of a project iteration, there are often some "unexpected circumstances," such as the boss having a demand, the market business, and the same time to mention the urgent "can make money" demand. This phenomenon has become an objective fact.

But since it happens, the product manager must find a way to solve it. How to solve it? In fact, in agile development thinking, each iteration will leave a "buffer period", that is, after the creation of the sprint, not following the time requirements, the workforce will be scheduled full, generally will set aside 20% of the workforce to respond to some changes in demand.

The last point is that responding to changes over following the plan does not mean not doing the initial product plan. The initial product plan is still very important and needs to be followed. This will ensure that the project is in order.

III. Be Careful Of "Fake Agile"

The above paragraphs describe the interpretation of the definition of Agile and the values of Agile. But it's not easy to implement Agile in your team or to "transition" your team to an Agile approach. Agile cannot be acquired just by understanding the above introduction. There are many reasons for "fake agile," which differ in different teams.

1. Ignorance of engagement

Agile is for the whole team, not one or a few roles, so every team member should become agile to ensure that the team's perception of agile is at the same level of perception.

For example, some colleagues in product support roles think that agile is only for product managers and developers, and has nothing to do with them, so they maintain their user guides at work and don't pay attention to agile participation, which will eventually lead to the lack of agile capability of the team.

2. No desire to change

Daily sprint station will be very important for the team's agile, and team members even synchronize the project progress and difficulties encountered. It may not be easy for teams that already have old work habits to accept this approach quickly.

3. Worry about not being perfect

Salary performance is a great concern in the workplace, but some managers are used to managing team performance by imposing oppression and fear. This approach can reduce the team's trust, and mutual trust is very important for agile. Such managers will fear the challenges that agile brings and challenge their authority.

4. Focus only on form

Any theory has practical value only if it is put into practice and brings benefits. For teams that already have a mature work model, "inserting" agile into the original workflow to make it appear that the team is working with an agile process rather than allowing agile to deliver its value will have little effect on the value of the team.

5. Not focusing on customer feedback

One of the most important points in the continuous iteration of products or services is constantly receiving feedback from users, not all without thinking. Instead, make analysis and trade-offs based on your judgment and user feedback so that you can continuously optimize products or services through user feedback. Even if an overly arrogant team makes a product, no users will pay for it.

The above introduces several possibilities that can lead to a team's "Fake Agile", and other reasons can also lead to "Fake Agile", which should be analyzed for specific team situations.