Dear Agile, I'm tired of pretending

"Agile is dead." People say that all the time. But be sure to add: "We are just kidding." They meant that you had such wrong and stupid practices that Agile is dead to you . But the "real" Agile is not dead. It's just that everyone does it wrong. So I understood: the real Agile is, you know, Agile in theory . Even I implemented it. And you know what? I'm sick of.

Recently, I saw in articles the same old defense: “But-but-but, the problem is in the waterfall, the scrum and the wrong implementation of Agile, the non-observance of the Manifesto… blah blah blah”. Then Bob Marshall told me the truth. He said, “Shut up, Charles. The Agile Manifesto is a pitcher that we fill. ” He made a few remarks with which I had to agree. I thought. The result was this article.

Here is a test for you. How does the first line of the Agile manifest begin? Do not pry. Do not know? Everything is good. It does not matter. It says: "We are discovering more advanced software development methods ..." Stop. Notice, it says, "software development." It doesn’t say “pulling out your organization”, “repaying the debt for transformation”, “cutting it out with this command-and-control shit”, “focusing on the results and improving the discovery work”, “fixing your medieval budgeting system” or whatever more advanced added value that people have tried to invest in it. But the fact is that when people say that Agile applies to the whole organization, it is revisionism. It's not fair.
')
Notice also that it starts “We are opening ...” He does not say: “We have received from above ...” Doesn't it seem to you that since 2001 we have learned something? I mean, yes, most of the large organizations are still stuck in 1987, but come on. Contrary to popular belief, the photo below is not really from the act of signing the Manifesto. Can we finally stop pretending?



The manifesto served a specific purpose, but it will not lead you where you need it. So proceed to study. Our knowledge has an expiration date, and not as long as we think. Everyone has colleagues (usually chiefs) who claim that they "have no time to learn." You yourself know that they are too self-confident in their knowledge. So find a good list of books. Keep up the good blogs. Here's a start: if you have not read Sense & Respond , Lean Enterprise , A Seat at the Table and Everyone Is a Change Agent , I suggest that you do it immediately. And your superiors.

Start reading the posts of John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Eric Hall, Neil Killick and those they refer to. Do they all agree with each other (or with me)? No, but they are smart and they will make you smarter too. Start reading and encourage others. Fast Company says the average CEO reads 60 books a year. How many books do your supervisors read? And what do they read? (HBR articles, Gartner reports and Maeve Binchy novels do not count). Because let's face it: if your leaders are masters of Scrum, then you are firmly stuck in the 80s and 90s.



Let's move on to continuous learning and stop pretending that Agile is some kind of medicine. This needs to be said: Agile is and has always been a local optimization for a small increase in system efficiency . Only Agile unfairly endured under the microscope of the software development team. This does not increase organizational flexibility. NO. Interestingly, according to Ken Schwaber (see his “Unsafe at any speed”), Agile was an attempt to “compensate for the damage caused by the waterfall” and yet never gave organizations a holistic, viable alternative to the waterfall. Because there is a difference between theory and practice. Working on a product is more of a practice. When we complain about AINO (Agile In Name Only), we are not being honest with ourselves.

Theory versus practice, remember? We must be pragmatic. Agile in practice is almost always AINO. Looks like a problem with the movement itself, isn't it? In any case, there are more important things to learn about, including (but not limited to) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, Marshall Organizational Therapy, etc.

You ask why Lean UX tops the list? Due to the fact that, in its essence, Lean UX popularizes the concept of results orientation. Consider: if you do not know what behavior change you are trying to create, you will not understand your actions. If you do not have an unambiguous “pivoting” signaling, then you can no longer be flexible. That's what Agile is, after all, pivoting. Some may argue: “But-but-but, test and adapt!” Of course. Theory versus practice, remember? I do not see flexible commands that test and adapt. I see how the Agile teams are trying to catch up, messing with Jira and Rally and working as if they were building a brick wall on orders.



Agile actually tends to mask the underlying problem — it’s a systemic, bidirectional lack of vertical trust. Agile coaches leave, worsening the situation: they leave behind them managers who speak pig Latin, and development teams who have switched to Esperanto. The teams believe that management is broken, and management believes that the focus should continue to be on volume, timing and efficiency, ignoring the timing is arbitrary, and estimating time is a form of waste . (Do you know that story points were actually invented to hide the time and help solve the problem itself? There were also unpleasant consequences here, didn't it? Theory and practice).

Guess who will win? Two camps with two radically different perspectives, where does one camp get marks from another? If teams are like blind people who feel an elephant and do not agree with what it is, then the guide looks like blind elephants attacking people and agreeing that they are all flat. The solution is to recognize that the system is a team. Finish it with local optimizations and realize that trust is problem number one. Stop unjustly putting developers under the microscope, allowing others to hide in a black box. (Why are we not interested in how strategic development teams work? Or how are Legacy architects constrained in the system?)

And while we are doing this, we should stop treating the development teams as if they were working in a factory. We do not stamp plastic ware. We create software. We need to stop behaving as if we are filling a pizzeria . Here are the other rules. We do not use the same proven recipe. We develop recipes . If you still do not understand, this is a job of discovery, and not just delivery. Neglecting discovery leads to massive losses: unused functions and other work that does not achieve results. This reveals another deep Agile flaw. He suggests that users can be perceived as guinea pigs: "Hey, just use this crappy product, then we will improve it." Except that the crappy product usually remains the same, right? Future improvements are becoming unnecessary "costs."

But-but-but, Agile is really focused on research! True? Let's be honest. Theory versus practice, remember? If you make a living by designing or researching, then answer this question. How do you usually feel about working with flexible teams? Are you initially viewed as valuable and asked to help “test and adapt”? Or are you asked to "prove your worth"? As Alan Cooper said, when you are asked to "prove your worth," you are clearly made to understand that you are in a system that does not value you. Note that they are asking an individual participant to prove their value — they do not ask how much of their code actually shifts the indicators in the right direction. In other words, they still focus on people, not on the work itself . They are probably still focused on costa, not on value, ignoring areas where much of the value actually leaks.

If you are working with flexible teams, the next time you are asked to "show your value", try this. Start asking them questions. Do they know what the cost of the delay is? What exercises do they use to evaluate this parameter? What specific results are they trying to achieve? What proportion of their product actually reaches its performance? They do not know? If there are faster and cheaper ways to learn what to develop, other than just releasing code, are they interested in learning? What is their flow efficiency? How bad is it? How much time do they spend in meetings? If there are design games and simplified actions that will lead to better solutions in much less time, are they interested in learning? Because I will not just show you my value - I will teach you to create more value in everything you do .

This is another way of thinking. This is meta. It is strategically. As Austin Gowell notes, both Agile and the Falls are focused on exploration. Design is a test . If they are not interested, you can leave. If they just lower their heads and release a product, focusing on costs, they will never even know enough to understand that you usually get more of what you focus on (um, bones). This is a function factory. Mutual responsibility. They pretend to create plastic dishes. You have more important things to do. Because real value is provided by the options that are generated by research . The more options you create and the more flexible your approach, the more possible ways and the better the result. What are they trying to achieve? Did they explore three to five ways to achieve this goal? This will lead to better decision making in the future. One option is not a choice. Two is a dilemma. Three - now you have achieved something.

Ever heard of the Law of the required diversity? The component with the most options controls the system . Apply it to the Agile vs. the Falls blunt power struggle. You had executives who tried to keep control of the system from above, and flexible teams that try to bring value closer to the source (real users and customers). Exiting meaningless civil war - to teach people to generate options at all levels . The way forward is not “Agile vs. the Falls”. This is smart top-down strategic work (waterfall) with empirically-oriented bottom-up tactics. Design and opening help in both cases.

So ... what is the solution? This is a reasonable focus on clear results, not on issuing, with planned results instead of planned marks, not with design, but with reliable product teams authorized to test assumptions and find the shortest path to value.

Now for training (adapted on the basis of the diagram of John Cutler).



So ... does Agile leave? Of course not. This is just a stupid blog post. I have no power. And even if it were, Agile would still not disappear. Agile made many of these concepts possible . In addition, contrary to popular belief, flexible practices were not invented by the Agile movement. They appeared a decade earlier.

So no, I don't want Agile to leave.

I just want us to be more honest.