10 Ways to "Kill" Agile

Agile has come out of the stigma of "only suitable for small teams and small projects" and has become a "famous discipline". Everyone wants to be more Agile, no one says that he is not Agile. But does Agile really deliver value? Today we will talk about how to "kill" Agile from another view.

Source: Freepik

Agile only happens in development teams

Agile only happens in development teams. The business team still writes the requirements and threw them to the development team with an order that they must meet a certain Deadline. The development team is not directly responsible for the business goals in this case. There is very little communication between such two teams, let alone negotiate. They just follow the orders of the business team. As for whether the demand thrown by the business team is reasonable, and whether there is a better solution under the same business goal, it is not a matter for the development team to consider.

In fact, most of such software have become products designed by "Product Owner" who does not understand development technology. The developers are only responsible for filling in the code to make the machine work. The development team is disconnected from the business and cannot build a model that is more suitable for the business. The final product becomes a freak, lacking reasonable abstraction and design. In the end, it became more and more rigid.

No or little automated testing

The role of automated testing, especially TDD (Test Driven Development), is substantially undervalued by the IT industry. Automated testing is the cornerstone of maintainable and high-quality software, and is even more important than production code. At present, there is a huge lack of automated testing in our industry, and most teams do not have the ability to automate testing, or have the ability but refuse it on the excuse of time constraints.

We lack the courage to continuously refactor bad code without the protection of automated testing because no one can predict whether changing a few lines of code will bring new bugs. We own more and more technical debt without continuous refactoring, which reduces our responsiveness to the business. Our manual regression testing speed becomes unbearable without automated testing, we either give up some of the external quality and just test the "changed" part (which may be hard), or lengthen the regression testing time. Too long regression test time will make us tend to test in batches to reduce the number of tests. But our agility is reduced in such a way, and the continuous delivery turned into batch delivery, Agile turned into Waterfall.

The key to automating testing is developer testing, not hiring more testers to write scripts. That's why the tests written by testers run slowly and feedback to programmers is slow. What we need to improve code quality is rapid feedback on the program. The earlier automated tests are written and the faster they run, the more conducive it is for programmers to get feedback in a timely manner. The earliest way to write automated tests is TDD: write before the production code. The fastest way to run automated tests is unit testing.

Source: Freepik

Not pay attention to code quality

People often say: We are running out of time now, just finish it and don't care about quality. Many people think that quality can be sacrificed, but it is not. You write low-quality code because you can only write like that, and you can't improve it with more time. The only way to improve code quality is to improve your skills. And most people (don't look at others, it's you and also include me) can't write high-quality code at one time. That's why we need constantly refactoring, and we must have fast enough automated testing in order to support constantly refactoring.

In addition, low-quality code does not bring out high performance. Unless your program is as simple as a few lines of code, as code complexity increases, low-quality code will hold you back sooner or later. Many people in our industry call other people's bad code "shit mountain", but in fact, most people are contributors to this shit mountain.

Software is called "soft" because we expect it to be easy to change. For them less likely to change, we called "hard" ware. For low-quality code, it becomes increasingly difficult for us to change it. A small change may lead to thousands of bugs, and it is quite labor-intensive to find the places that need to be changed, not to mention the need for a lot of manual regression testing after the change. Can we still be Agile with this quality of software?

Not pay attention to quality requirements

As the saying goes "Garbage in Garbage out". Software requirements are the input of software. Good software cannot be produced without good requirements. In our industry, good product owners are more scarce than good programmers. After all, no matter how bad a programmer writes, it still has a basic principle: it can run. For most product managers, there is no standard to measure their garbage.

Some product owners are devoted to design solutions and ignore user value, resulting in a bunch of white elephant functions (costly but useless). Some product owners have incomplete requirements analysis and incomplete consideration of scenarios, resulting in endless bugs. Some product owners don’t prioritize the requirements which leads to teams wasting a lot of time on low-value items. Some product managers can only tell big stories and can't split requirements into small enough pieces, which results in large delivery batches and reduced agility.

Setting employees based on things

Source: Freepik

A typical example of determining employees based on things is the project system. Employees all belong to a certain technical team, such as Android group, iOS group, background group and so on. Personnel change frequently in a project team will lead to the high grinding cost. However, many practices in Agile are based on teams such as team velocity, retrospective improvement, and staff turnover. For teams with frequent changes, many practices are difficult to sustain. Even if some achievements are made, the project will be end soon, the team will be disbanded, and knowledge will be lost.

The advantage of setting employees based on things is that it saves labor costs, so outsourcing teams tend to use them to maximize corporate profits. But for IT companies, generally speaking, the response to the business is the first priority to be considered.

Agile practices basically revolve around teams and around people. Setting people based on things as the goal violates the principle of agility, and will inevitably lead to inflexibility in the end.

Not pay attention to improving employee's abilities

Many IT companies do not pay attention to training employees. Many people will say that I have worked hard to train employees and they are poached by other competitors suddenly. If this happens, companies should reflect: Why can't I keep excellent talents? Am I only deserve inferior manpower? In fact, just like programmers complain that they cannot write high-quality code because of time lacking, the essence of companies complaining that the talents they train will be poached is that they do not know how to train talents.

On the surface, employees are the greatest wealth, but enterprises regard them as screws that can be replaced at any time. Software development is a design process that faces uncertainty and variability and is not like moving bricks. Developers are not producers but designers. The replacement cost is relatively high for the designer.

The 996 principle in our industry leaves employees with no time to study. Retiring at the age of 35 is actually squeezing the instinct of employees for the next 10 years. Everyone works by instinct and lacks good practice. In fact, it is repeated at a low level. Agile is nothing but a castle in the air without the improvement of employee ability.

Agile is just a tool

Some companies simply define Agile Transformation as the use of platforms. Using Kanban and holding stand-up meetings is Agile, using CI/CD tools is DevOps, bought an automated testing platform is automated testing. Agile Manifesto #1: "Individuals and interactions over processes and tools". Processes and tools help us get things done faster and better, but individuals and interactions are more important. Claiming to be Agile just by buying a bunch of tools is doing nothing.

Source: Freepik

Personnel reuse

IT employees are hard to find. This is an industry problem. Of course, this problem is also made by the industry itself (not focusing on training). In this case, many companies engage in a matrix structure. The horizontal is the product or project, and the vertical is the functional team. Many people are shared across different products and projects.

The result is that employees' work appears to be over-saturated. However, because the employee is reused in multiple products, he must have multiple to-do lists, and the priorities of each to-do list are not consistent. As a result, he has to constantly switch between multiple matters, leading to a loss of his efficiency. And because he has multiple matters to deal with, it will actually cause other people to wait for him. Therefore, personnel reuse is actually the exchange of reduced business response for personnel cost efficiency.

Module reuse

When a company grows to a certain extent and has multiple product lines and business lines, it will naturally find that some businesses seem to be similar. Instinctively out of cost considerations, the company would like to extract this part and hand it over to a dedicated team for maintenance, so that the business associated with such module/service just needs to call them. This sounds very good, multiple business/product lines do not need to consider the use of a certain module/service, just call it. But in fact, the modules/services extracted in this way are often unstable and cannot meet the needs of other businesses in the future.

Therefore, in the future development process, many products/business lines need to modify this shared module to meet their own needs. Since the maintenance of shared modules has been handed over to independent teams, there will be handovers between teams, and the cost of such handovers is much higher, which reduces the responsiveness of the product/business line.

Strict division of functions within the team

The team is divided into several functions: Android development, iOS development, testing, back-end development, database, operation and maintenance, architecture design, BA, and security. The result is that there are multiple handovers in the process from requirements to delivery. As we all know handover will lead to waiting and waiting is a kind of waste.

Therefore, handovers should be reduced to maintain team agility. In addition, the strict division of functions will lead to a serious imbalance in the workload, which cannot complement each other. Others can only watch when a certain link accumulates, and even continue to produce to make the accumulation more serious.