Having engaged in software development for nearly 40 years using various hardware, operating systems, and programming languages, what I personally realize when looking back now is that the times when we could advance development exactly according to the same standardized procedures were actually very brief.

The Agile Manifesto was published in 2001, but of course long before that, many software developers were experimenting with and utilizing object orientation, UML, XP (Extreme Programming), and so on, continually seeking "better development methods." Even for plan-driven projects, they probably abstracted parts with high specification change risks or prioritized implementation validation of parts with high technical risks, didn't they? Going forward, of course we should continue to appreciate and leverage the wisdom of our predecessors, and I believe we'll also keep making our own free-form improvements.

If you include not only developers but also operators, it becomes DevOps, and if you also include the business department, it becomes BizDevOps... Of course Lean says "Anything not recognized as value by the customer is waste," and it's not just CX (Customer Experience) but also DX (Developer Experience) that we want to emphasize as QoEL (Quality of Engineering Life), right? I believe that not just in agile, but fundamentally continuously seeking a better way to live as human beings is natural, and it seems that balancing around that is important.

It seems that humans sort memories during sleep and forget the unnecessary. They simulate worrisome issues repeatedly in dreams to increase the chances of survival tomorrow. We alternate between deep sleep (non-REM sleep), which rests the brain and body, and REM sleep, where the brain reprocesses memories and simulates survival-related behavior programs—in other words, a retrospective time. I feel that this has not changed since the days when people cooperated in mammoth hunting (mob work).

The Guinness record for sleep deprivation apparently is 264 hours 12 minutes (now deleted), but normally the 24-hour period from awakening to waking again is a time box (since our biological clock is somehow about 24 hours 10 minutes, we need to reset every day to maintain the rhythm). Are you doing today what you have to do today? (Things that can wait until tomorrow, do tomorrow.)

It's said that humans make 35,000 decisions a day, but there are various levels, such as life-and-death critical judgments and decisions where it hardly matters what you choose. It makes sense that Steve Jobs apparently wore the same outfit every morning so as not to spend time or effort on low-priority matters, but fundamentally humans focus on what has high priority for them, right?

Are you the type to save your favorite food until last? Or do you eat it first? But it depends on the situation, doesn't it? So in a two-hour all-you-can-eat buffet with 30 seconds remaining, do you eat the last remaining slice of shortcake topped with your "favorite strawberries" starting with the strawberries? Or do you start with the sponge cake or cream?

When you were in elementary school, didn't you go out to the schoolyard to play dodgeball even during a mere 20-minute recess? Of course, when the bell rings (time box), you return to the classroom, but in the next recess you start from where you left off, right~

Wiper speed on a highway in the rain or refreshing a FX stock chart—the faster the better for continuously seeing reality, right?

When you think about various things, you're liable to catch "looking-agile-at-everything syndrome," but...

• A list of 100 things to do before you die (your life's product backlog)
• Travel (money and duration are fixed, and you prioritize where to go, abandoning lower priorities)
• Surgery (specialists continuously treat the patient as mob work, prioritizing flow efficiency over resource efficiency)
• co-Working (mob work: composing songs as a team), Jazz sessions (mob work: improvisation, actual sounds over sheet music ♪)
• Teal organizations / Holacracy organizations
• U理論
• In-basket thinking
• Chateraise's new product development
• Revival of the venerable inn Jinya, Honda F1 know-how
• Setagaya Ward Sakuragaoka Junior High School in Tokyo (abolished school rules and regular tests)
  …and so on, I somehow feel a similar mindset.

It's been a while since the novel coronavirus settled down, but agile in remote work is now commonplace, and the use of generative AI is advancing, greatly changing the way we work (in the recently released Scrum Guide extension pack, some product developers can even be AI). A physical whiteboard in a real meeting room can hardly handle input from three to four people, but with an online board, 100 people can write simultaneously. In a real meeting room, masks make facial expressions hard to see, and in a large room, it's hard to see people far away, but in an online meeting, no mask is needed and facial expressions are clearer.

On Demand. In other words, a "single-piece flow according to priority" seems good? Though it's said that "it's better to fix the development team," it feels like sizing on-premises servers for peak times. Of course, for the contracting side, it's tough to secure or reduce personnel, but like cloud services, being able to flexibly "use what you want when you want it, in exactly the right amount" efficiently might actually be better. If you focus on continuously adding value to the product, scaling across multiple teams by having three to four teams in different parts of the world with a six- to eight-hour time difference working in shifts might also be good. Of course, domestically in Japan, you could do a three-shift system like hospitals, but... (I once did development in two shifts around 2000, but it was hard to sustain long-term).

PMI PMBOK DA (Disciplined Agile) also emphasizes with "Choose Your WoW! Way of Working!" that "choosing their way of working by themselves" is important. In DA, you can choose "XP," "Scrum," "UP," of course, and also "SAFe" and the "Spotify model," which were not in the 2001 Agile Manifesto, and it's basically an "all-inclusive" that even lets you pick traditional approaches. In Ivar Jacobson’s モダン・ソフトウェアエンジニアリング, it's designed so that by abstracting, you can leverage the strengths of various agile methodologies. Going forward, I believe trends like the "Inverse Conway’s Law," "Teal organizations/Holacracy," and Web3's DAOs (decentralized autonomous organizations) will further optimize the structure of organizations and software.

Currently Scrum has a large share of usage, but it seems to be supported by managers rather than developers. Of course, organizational selection criteria are necessary, but you don't want to stifle each team's creative improvements, do you? While meeting the expectations of the market, customers, and end users, and striving for better, more enjoyable, and rewarding development, we want to continue seeking "better methods," including the freedom to discard old conventions (collections of biases) while respecting the wisdom of our predecessors.

The Constructal Law, which states "When given freedom, flow evolves to better configurations," seems to offer a hint for agile’s ability to quickly and continuously deliver value. To survive, we must continue finding better ways. I believe that given freedom (without wasteful excessive management), we will continue to evolve in a better direction.

Earth 2.7 billion years ago was completely free, and when photosynthesizing bacteria began to increase the planet’s deadly "oxygen," the survival strategies were:

• Survive in places with almost no oxygen → like the ocean floor or inside animal intestines
• Seek ways to live with oxygen → incorporate mitochondria into the cell, which can use oxygen for energy
  On Earth 2.7 billion years ago, there were no advanced medical research facilities... It’s okay ♪ It makes me feel like no matter what happens, we’ll somehow manage.