Original address: medium.com/columbus-eg… CODING minjie prince
“Agile is dead,” people keep saying, but then they say, “We’re just kidding.” What these people are really saying is that the way you practice Agile is outdated and stupid, and that “real” Agile is not dead, but everyone is doing it wrong. Therefore, I consider theoretical Agile to be “real” Agile.
I’ve also picked up a lot of old justifications on the web lately: “But it’s water-Scrum-fall that’s the problem, not agile in the manifesto.” Then Bob Marshall bluntly said, “Shut up, the Agile Manifesto is a cliche.” He said something else that I had to agree with, and I thought about it, and here’s what I thought about it. Read: water-Scrum-fall www.infoq.cn/article/del…
Here’s a quiz for you: What’s the first sentence of the Agile manifesto? No peeking. In case you don’t remember, “We’re exploring better ways to develop software…” Stop there, notice, it said the “software”, did not say to “tilt your organization”, “for the debts of the transition”, “with this kind of bs cut its command and control”, “focus on results and work in the field of found”, “fix your budget system of the middle ages”, or any other people try to cover a more valuable things. The problem is that when people say agile belongs to the entire organization, it’s revisionist history, and it’s not honest.
It begins with the words: “We are discovering…” “It does not say:” We have gone from very… Get…” . Don’t you think we started to realize in 2001 that most large organizations are still stuck in 1987? Contrary to popular belief, the photo below is not actually from the Manifesto signed by Snowbird. Can we finally stop pretending to be agile?
A manifesto has its goals, but it doesn’t get you directly to where you want to go, so we need to learn. Our knowledge has a shelf life, sometimes not as long as we expect. We all know colleagues (usually leaders) who claim they “don’t have time to learn,” and you know they’re just overconfident in their own perceptions. So get a good reading list and follow some good blogs, that’s a start: If you haven’t read Sense & Respond, The Lean Enterprise, A Seat at the Table or Everyone Is A Change Agent, I suggest you take the time to learn them, and I suggest your leader read them too. Sense & Respond looks at how companies must develop awareness and strategies to take advantage of the opportunities of the networked age. A Seat at the Table illustrates how the traditional CIO role conflicts with agile approaches to software development and explores what IT leaders should look like in an agile environment. Everyone Is a Change Agent explains how to make Change and drive Change in an organization.
Start reading John Cutler, Melissa Perri, Bob Marshall, Allen Holub, Laura Klein, Erika Hall, Neil Killick and the rest of their posts. Do they all identify with each other (or with me)? No — but they’re smart, and they’ll make you smarter. Read and encourage others. Fast Company says the average CEO reads 60 books a year. How many books has your leader read? And what are they reading? (HBR articles, Gartner reports, and Maeve Binchy novels don’t count.) Let’s face it, if your leader is still trying to Scrum through sixth sense, your organization is stuck in the ’80s and’ 90s.
So let’s agree that agile is not a silver bullet for R&D management, teams need to keep learning. To be clear: Agile has always focused on native optimization and has brought very little benefit to the system. Agile means putting the software development team under a microscope, reading the development team in many details, which is often unfair and does nothing to improve the agility of the organization. Interestingly, Ken Schwaber wanted to undo the damage done by waterfall development, yet Agile never provided a viable alternative to the enterprise or organization as a whole. There is also a gap between practice and theory, in practice we need to be pragmatic, which also leads to the practice of Agile often in name only, which seems to be the problem of the entire agile movement itself. However, there are more important things to learn, including but not limited to DevOps, Lean UX, Lean entrepreneurship, Design Thinking, and more.
You may be wondering why Lean UX is on this list, because Lean UX focuses on the end result. If you don’t know what kind of change you want to create, you won’t know how to transform. Without a clear signal of change, you can’t be truly “agile” in the first place, since change is agile’s primary concern. Others say that agile is mainly about instant observation and adjustment, but I see most Agile teams just mechanically adding cement to their existing work, pouring it in Jira and Rally, just as they were building brick walls elsewhere.
Agile by its nature tends to hide core issues, which are systemic and lack vertical trust in both directions. Things get even worse when the Agile coach leaves, as the management and the r&d team talk chicken and duck because the butt decides the head. Teams get the feeling that management doesn’t know anything, but they focus on the excellence of the task, the merit of the job, and efficiency, and often fail to see that deadlines and time estimates are up in the air.
Well, guess who’s going to win? The two camps have two very different perspectives, but one camp has to be evaluated by the other. If development teams are like blind men touching an elephant and discussing what an elephant really looks like, management is like blind elephants trampling on people and agreeing that people are flat. The only way out is to recognize that the management system is part of the team, not the local details, but to realize that trust is the first factor. So don’t just put the r&d team under a microscope while everyone else is hiding in a dark room wondering what they’re doing.
Again, when trying agile, you have to stop treating the r&d team like a factory worker. We are not in the manufacturing of plastic tableware, we are in the create a new software, we need to stop like to open a pizza shop management, that has been using the same kind of formula to do pizza’s way is not applicable, we are in the design of the new formula is innovative work, not just that simple step by step. Ignoring the creativity of the job leads to a lot of waste: features that no one uses and code that doesn’t produce results. This exposes another deep flaw in Agile, which assumes that users can be treated like guinea pigs: “Hey, you use this useless feature now, we’ll improve it later,” and then the user never looks back, making future product improvements a waste of money.
Some would argue that Agile can also work as a way of doing creative work, but as I just said, there is a gap between theory and practice. If you really want to do some creative work for the team, think about your experience with agile teams. Will you be recognized by the team and help the team improve, or will you often be asked “can you show why you’re doing this?” As Alan Cooper puts it, when you are often asked to prove your worth, know that they are telling you that the current environment does not recognize your worth. Note that managers ask individual contributors to prove their worth — but don’t ask how much of their code actually produces positive results. In other words, they are still focused on the people rather than the work itself, and they may still be focused on the cost rather than the value of the actual output.
So if you’re trying to do something creative on an Agile team, the next time you’re asked how you can demonstrate your value, try asking this question: Do you know the cost of project delays? What dimensions do you use? What substantive results does the project want to achieve? What resources and code are translated into actual results on the project? If they can’t answer, follow up and ask if you’d be interested in learning how to build something faster and cheaper than just rote output code. How efficient is your assembly line now? How many hours a day are spent attending meetings? Would you be interested in thinking exercises and team-building activities that could lead to better decisions in less time? Because I won’t just tell you how important I am — I’ll teach you to create more value in everything.
This requires a different kind of thinking, one that is formally more strategic. As Austion Govella puts it, both agile and waterfall approaches focus too much on building and not enough on evaluating results. If your organization is not properly evaluating output, you may need to move. If they’re just toiling away every day, churning out code in batches, focusing on cost, they’re just an output factory, pretending to be making plastic cutlery instead of making it, and they won’t understand what you’re doing to benefit the team. Because real value is determined by the choices that are created in r&d, and those choices are created by the constant learning and exploration that goes into everyday work. The more options you have, the more flexibility you have, and the more ways you can create value. What exactly is the project trying to achieve? Look for 3 to 5 new ways to achieve this goal? These need to be driven by better decisions through longer term planning. When there is only one option, two options are dilemmas, but the presence of the third option represents the recognition of the pros and cons, and the team really moves forward.
And there’s a Requisite Variety to this. Have you ever heard the Law of Requisite Variety: The one component in a system that has the most choices determines the Requisite Variety? The way out of this civil war between leaders trying to control systems at the top and agile teams trying to push value closer to actual users and customers is to give people choice at every level. The way out is not to seek agile VS waterfall outcomes, but rather an intelligent top-down waterfall approach to strategy, coupled with top-down experience-driven tactics.
So people should care about the results, not just the output; Focus on the strategic layout rather than the milestones laid out. The r&d team should be truly trusted as a product team, not just as a project team. Give the r&d team the autonomy to explore the best way to achieve their goals.
In conclusion, with all the teasing, does this mean agile is on its way out? No, this is just my observation of some of the problems that arise when organizations or enterprises practice Agile today, and without the Agile movement, most of what I’ve said here today would be meaningless. So I don’t want agile to die, I just want us as practitioners of Agile to be more open to the problems.