“Today’s overtime work to do this demand, the boss is very urgent.” –A project manager of a certain factory at a certain time

“Agile,” once synonymous with flexible speed, has evolved over the past 20 years into a seemingly esoteric term that programmers in IT often talk about. Agile Development is the project management framework of choice for many development teams because of its simplicity, flexibility, and more importantly, it literally implies “fast.” Think of digital farmers working overtime for free in order to catch up with their schedule.

When your development team suffers from project delays, product quality degradation, low morale, and deteriorating customer relationships, your friends may recommend using agile development: “Hey, bro. I’ve heard that Agility has been quite popular lately, so you can try it. However, when you’ve been running agile in your team for a while, you’re likely to find that it’s not going to be easy: there’s still a lot of bugs after the product launch, endless overtime, and a steady stream of highest priority demands. In a daily meeting with your boss, the boss asks you, “I heard that you are using agile to improve delivery efficiency, great!” So can I see the important features that were mentioned to you earlier next week? ”

“Agile is fast delivery” is the biggest misconception among many agile practitioners. In fact, “agility does not necessarily mean fast”; Instead, it introduces more extra work, which can lead to slower delivery of functionality. Yes, you read that right. Strictly speaking, agile reduces the speed of delivery. For example, extreme programming (XP, one of the agile frameworks) requires unit tests to be written for each function, which introduces 1-2 times more extra code.

So, why do some people say that agile is a project management artifact for software development? It can neither improve development efficiency nor reduce the workload, so what is it really used for? This is the soul torture that many agile practitioners encounter the most. If you can’t give a satisfactory answer in time, the development team will eventually abandon Agile and return to the way they were originally accustomed to working.

As a project manager who has managed large, complex projects, you may find it uncommon for projects to fail. According to TeamStage surveys, in mid-2022, the project failure rate will be as high as 70%, the overrun project will account for 55%, and 75% of project managers will have no confidence in the success of their project. “Winning or losing is a common thing”, but long-term project failures can lead to serious waste of resources, brain drain, and even corporate bankruptcy.

If you have taken the PMP Professional Project Management Certificate or studied project management, you should be familiar with the diagram above. Each item is governed by the following 4 factors (dimensions):

If a software project needs to be delivered in March, with a budget of $100k, and requires support for 1k users at the same time, its constraint dimension is already fixed. It seems like everything is on track. However, once the client asked to add an important new requirement, the scope of the project expanded, and the development team “had to seek compromises in other dimensions”.

If you were the project manager for the project, what would you decide?

Are these Internet black words familiar? As a programmer, you may not know the full picture of the project. But in fact, the main reason is “the deformation of the project constraint factor”, which creates a series of problems and ultimately leads to the failure of the project.

Based on the above analysis, we know that many projects have “motion deformation” due to changes in constraints, which leads to a series of problems and ultimately leads to project failure. The traditional waterfall model guarantees that the time dimension is constant (guaranteed by a cool Gantt chart), but other factors vary in form, so the symptoms that often occur are: overspending (cost), defective products (quality), and constant demand (range).

From a practical point of view, however, successful software projects are built on quality, which means that the delivered product must be usable, easy to use, and valuable, which is one of the core of the agile framework. The agile framework requires three dimensions of “fixed quality, time, and cost”, leaving only the dimension of “scope” to be variable. For example, in the Agile framework Scrum, the User Story in a sprint can be flexibly changed according to the situation before the sprint begins, to ensure that the value delivered in a single sprint is maximized; Extreme programming allows teams to replace user stories of the same complexity at any time depending on the situation. The same Agile team is usually a fixed quality assurance (requiring regression testing), fixed development members (typically less than 12), and a fixed lead time (a bi-weekly sprint), but the difference is the functionality delivered to the user online. The result is “consistent, high-quality, continuous delivery that meets customer expectations, and agile teams that are constantly self-improving.”

I don’t expect this hundred-word article to make an IT practitioner who doesn’t know agile instantly understand the benefits of agile development, and it’s not an overnight opportunity to roll out agile to the entire development team or even the entire organization. But what I can be sure of is that right-practiced agile can effectively reduce the problem of vicious overtime and low-quality delivery in the organization, which is what most IT practitioners want to solve.

If you drive a lot (literally), with a little attention you should easily discover the basic movements used to drive: looking at the road, pedaling, turning the steering wheel. Repeat these three simple actions over and over again depending on the road conditions, allowing you to go to any destination on the road in any city. If you do not pay attention to the road conditions, or blindly drive the fast car, it is likely to lead to the destruction of the car and the death.

The same is true of Agile, which is nothing more than a development process that gathers feedback, constantly adjusts, and runs in small steps. This feedback loop-focused process allows the entire team to “enhance antifragility” in an ever-changing competitive market, helping the team to survive and even thrive in the long term. It’s a process that focuses on humanity, innovation, and a culture of freedom.

However, Agile may not be suitable for ambitious entrepreneurs, because some entrepreneurs drive a scooter with a supercar shell, and they need a strong cow horse to pedal day and night to make it look like a supercar, otherwise they will be squeezed down the mountain by the real sports car behind them. It’s very difficult to get them to admit that they’re just driving a scooter. As everyone knows, “only by slowing down or even stopping will they have time to build a real sports car.”

If you are interested in the author’s article, you can add the author WeChat tikazyq1 and indicate “the way of the code”, the author will pull you into the “way of the code” exchange group.

The English version of this article was published simultaneously on dev.io[1], technology sharing without borders, welcome the guidance of the big guys.

dev.io: https://dev.to/tikazyq/talking-agile-are-you-sure-your-team-is-practicing-agile-properly-1l5