How to better implement agile

It is well known that the agile movement does not produce a completely workable revolutionary result. If the current program works, then at least now, thousands of organizations have already reached a self-sustaining, continuous, independent agile state.

Obviously, that's not the case.

The story is always full of typical failure patterns. At first it seemed to be a good organization, and in the end it degenerated into a waterfall-flow practice. The organization hires coaches and spends millions of of dollars to improve only 25% to 30% of the standards they measure!

Large-scale software development is a very difficult task. Agile mode of thinking, relevant principles, patterns and practices can play a great role in supporting. The question is how to achieve this goal. It is clear that very few people (if anyone) know how to provide a continuous and sustained large-scale agile implementation. What the hell are we going to do? Who knows how to do it? As an advisory and mentoring community, we have not honoured our agile commitments to our customers and the wider world. This sucks.

In general, agile practices are implemented in a licensing manner. The practice of regulation does not concern people's needs, people's thoughts, and people's feelings. Rigid rules reduce people's participation, and lead to intelligent and creative employees "quit" and not participate.

In general, we use the following patterns to implement agile methods, and often after small pilot tests on a small team:

The authorities say we are "moving towards agility".

The authorities say we use special practices such as scrum, Kanban, or other agile practices, methods, or frameworks. The bad news is that it's not negotiable.

The person in power chooses a coach for experience based on the practice of the rules he or she has been engaged in. Usually, coaches who are familiar with scrum skills. The coach was imposed on subordinates, just like those prescribed agile practices.

Because of the experience of controllability, inclusiveness and low sense of belonging, employees are voluntarily no longer involved. They have realized that the new game is very vague and clearly stipulates that it must be attended. Agile implementation is not an enjoyable game because the game itself is not explicitly defined and has no chance to opt out.

The way to participate in a typical agile implementation is not through an invitation but more like an authorization or regulation. Here's a recipe for those failed agile implementations. Think back to the idea of open agile implementation, where authorization lowers user participation, but invitations and alternative participation can increase participation. Think back to another idea of technology, where user participation is the basic element of rapid and sustained agile implementation.

Developers of software programs typically have the following characteristics, especially when compared to ordinary people:

High IQ

The tendency of introverted disposition

Contains the following psychological self-image

I was hired to solve the problem.

I'm smart and creative.

I was hired for technical expertise.

Authorized agile implementations tend to be rejected by smart job-solving people. One reason is that these people really like to solve problems, including those "process problems", such as "How to achieve agility in our company." "Now, since most of them are introverted, if we don't ask what they think, the really scary things will happen: they won't tell us."

Usually, those who are in charge of the job and solve the problem have some useful ideas or ideas. But not to turn to them. Instead, a mandated mandate is issued, and we will miss the opportunity to be helped and create a significant potential for resentment. This is a double negative result. We are eager to get the best idea and we are eager to get a chance to participate.