Dear Agile, I'm sick of pretending

"Agile is dead." People say that all the time. But they necessarily add: "We are just joking." They kind of 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 realized: the real Agile is, you know, Agile in theory . Even I implemented it. And you know what? I'm sick of.

Recently, I saw the same old defense in my articles: “But-but-but, the problem is 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 the jug we fill. ” He made some comments that I had to agree with. I thought about it. The result was this article.

Here is a test for you. How does the first line of an Agile manifest begin? No peeking. 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 your organization,” “paying off debt for transformation,” “cutting it out with this command and control shit,” “focusing on results and improving opening work,” “fixing your medieval budgeting system,” or whatever more advanced added value that people tried to invest in it. But the fact is that when people say that Agile refers to the whole organization, it is revisionism. It's not fair.

Notice also that it begins “We discover... "He does not say:" We have received from above ... "Do not you think that since 2001 we have learned something? I mean, yes, most large organizations are still stuck in 1987, but okay, you. Contrary to popular belief, the photo below is not really from the act of signing the manifesto. Can we finally stop pretending?



The manifest served a specific purpose, but it will not lead you to where you need to. So start your studies. Our knowledge has an expiration date, and not as long as we think. Everyone has colleagues (usually bosses) 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 with good blogs. Here's a start: if you haven’t read Sense & Respond , Lean Enterprise , A Seat at the Table and Everyone Is a Change Agent , I suggest you do it immediately. And to your superiors.

Start reading posts by John Cutler, Melissa Perry, Bob Marshall, Allen Holub, Laura Klein, Erica 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 also make you smarter. Start reading and encourage others. Fast Company says the average CEO reads 60 books a year. How many books do your leaders read? And what do they read? (HBR articles, Gartner reports, and Maeve Binchi novels do not count). Because let's face it: if your leaders are Scrum masters, 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 cure. This must be said: Agile is and always has been a local optimization for a slight increase in system efficiency . Only Agile unfairly placed under the microscope a team of software developers. 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,” yet it 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 honest with ourselves.

Theory versus practice, remember? We must be pragmatic. Agile in practice is almost always AINO. It seems like a problem with the movement itself, right? In any case, there are more important things that need to know, including (but not limited to) Lean UX, Lean Enterprise, Beyond Budget, Theory of Constraints, Throughput Accounting, Design Thinking, DevOps, organizational Marshall therapy and so on. D.

You ask why Lean UX tops the list? Due to the fact that in essenceLean UX promotes the concept of result orientation. Think: if you do not know what kind of behavior change you are trying to create, then you will not understand your actions. If you do not have a clear pivoting signal, then you can no longer be flexible. That's what Agile is, after all, is pivoting. Some may object: “No-no-no, check and adapt!” Of course. Theory versus practice, remember? I do not see flexible teams that test and adapt. I see Agile teams trying to catch up, messing around with Jira and Rally and working as if they were building a brick wall on orders.



Agile actually tends to mask the main problem - this is a systemic, bi-directional lack of vertical trust. The Agile Coachis leave, worsening the situation: they leave behind pig-speaking managers and a development team who switched to Esperanto. Teams believe that management is broken, and management believes that the main focus should still be on volume, timing and efficiency, ignoring that timelines are arbitrary and time estimates are a form of waste . (Do you know what story points actually invented in order to hide time and help solve the problem itself? There were unpleasant consequences here, too, right? Theory and practice).

Guess who will win? Two camps with two radically different perspectives, where does one camp get ratings from the other? If teams are like blind people who feel an elephant and disagree with what it is, then leadership is like blind elephants attacking people and agreeing that they are all flat. The solution is to recognize that the system is a team. Finish already with local optimizations and realize that trust is the number 1 problem. Stop unfairly placing developers under the microscope, allowing others to hide in a black box. (Why aren't we interested in how strategic development teams work? Or how are legacy architects system constraints?)

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 dishes. We create software. You need to stop acting like we are serving a pizzeria . Here are the other rules. We do not use the same proven recipe. We develop recipes. If you haven’t understood yet, this is opening work, not just delivery. Neglect of discovery leads to massive losses: unused functions and other work that does not achieve results. This reveals another deep flaw of Agile. He suggests that users can be thought of as guinea pigs: “Hey, just use this shitty product, then we will improve it.” Except the shitty product usually stays that way, doesn't it? Future improvements become unnecessary “costs."

But-but-but, Agile is really focused on research! True? We will 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 value and asked to help “test and adapt”? Or are you being asked to "prove your worth"? As Alan Cooper said, when you are asked to "prove your worth", you are made clear that you are in a system that does not value you. Please note that they are asking an individual participant to prove their worth - they are not asking how much of their code actually biases the indicators in the right direction. In other words, they still focus on people, not the work itself.. They are probably still focused on bones, not value, ignoring areas where a significant part of the value actually flows away.

If you work with flexible teams, the next time you are asked to “show your value,” try this. Start asking themquestions. Do they know what the price of 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 find out what to develop, other than just releasing the 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 designer 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 that you do .

This is a different way of thinking. This is meta. This is strategic. As Austin Gowella notes, both Agile and the waterfall are focused on development . Design is a test . If they are not interested, you can leave. If they simply lower their heads to release a product, focusing on costs, they will never even know enough to understand that you usually get more than what you focus on (um, bones). This is a feature factory. Mutual responsibility. They pretend to create plastic dishes. You have more important things to do. Because real value is provided by options that are generated through research.. The more options you create and the more flexible your approach, the more possible paths and better results. What are they trying to achieve? Have they explored three to five ways to achieve this? This will lead to better decision making for the future. One option is not a choice. Two is a dilemma. Three - now you have achieved something.

Ever heard of the Law of Diversity Necessary? The component with the most options controls the system . Apply it to the stupid power struggle of Agile vs. Waterfall. You had executives who tried to maintain control of the system from above, and flexible teams that tried to bring value closer to the source (real users and customers). The way out of a meaningless civil war is to teach people how to generate options at all levels.. The way forward is not Agile Against a Waterfall. This is smart top-down strategic work (waterfall) with empirically oriented bottom-up tactics. Design and discovery help in both cases.

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

Now for training (adapted based on John Cutler chart).



So ... does that mean Agile is leaving? Of course not. This is just a dumb blog post. I have no power. And even if it were, Agile would still not disappear. The Agile movement has made many of these concepts possible.. In addition, contrary to popular belief, agile practices were not invented by the Agile movement. They appeared decades earlier.

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

I just want us to be more honest.