PITFwithObi reposted this
Agile is killing your productivity. And world history proves it. After 25+ years in software transformation, I’ll share a truth bomb that might hurt: You're running fast... in circles. Let me share a forgotten piece of history that changed how I think about software development: Post-WW2 Japan 🇯🇵 • Economy in ruins • Industries decimated • Zero global competitiveness Then something remarkable happened. Toyota engineers discovered a counter-intuitive truth: 𝗧𝗼 𝗺𝗼𝘃𝗲 𝗳𝗮𝘀𝘁𝗲𝗿, 𝘆𝗼𝘂 𝗻𝗲𝗲𝗱 𝘁𝗼 𝘀𝗹𝗼𝘄 𝗱𝗼𝘄𝗻. The result? The Toyota Production System revolutionized manufacturing worldwide, giving birth to: • Lean methodology • Kanban systems • Six Sigma principles If you've ever noticed - these methodologies were 𝐧𝐞𝐯𝐞𝐫 about speed. They were about 𝘦𝘭𝘪𝘮𝘪𝘯𝘢𝘵𝘪𝘯𝘨 𝘸𝘢𝘴𝘵𝘦 and 𝘤𝘰𝘯𝘵𝘪𝘯𝘶𝘰𝘶𝘴 𝘪𝘮𝘱𝘳𝘰𝘷𝘦𝘮𝘦𝘯𝘵. Fast forward to today: We've borrowed these principles for software development, creating Agile and SAFe. Only we've very obviously missed something crucial. 📊 The data is shocking: • 90% of Agile teams report faster delivery • Yet only 25% show improved quality • 99% are stuck in what I call the "Sprint-Debt Cycle" Here's what we must remember to apply from history: Running more sprints ≠ Moving forward Think about it: If you're building the wrong features faster... If you're accumulating technical debt quicker... If you're scaling inefficient processes... 𝘠𝘰𝘶'𝘳𝘦 𝘫𝘶𝘴𝘵 𝘢𝘤𝘤𝘦𝘭𝘦𝘳𝘢𝘵𝘪𝘯𝘨 𝘵𝘰𝘸𝘢𝘳𝘥 𝘧𝘢𝘪𝘭𝘶𝘳𝘦. The solution? Return to the original Japanese wisdom: 1️⃣ Slow down to analyze 2️⃣ Fix one process at a time 3️⃣ Validate improvements 4️⃣ 𝘖𝘯𝘭𝘺 𝘵𝘩𝘦𝘯 increase speed Remember: Toyota didn't become Toyota by rushing assembly lines. They became Toyota by perfecting each step of the process. So ask yourself: Are your sprints taking you somewhere, or are you just getting better at running in circles? Want to learn how to transform your Agile processes into actual progress? DM me. #Agile #softwaredevelopment #continuousimprovement #processimprovement #BetterSoftware
You got a lot wrong in this very misleading post. Agile is based on continuous improvement. It says in the first line of the Agile manifesto that we are uncovering better ways of developing by doing it and helping others do it. And it says that at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly. Also, agile isn't about rushing the delivery of features users don't want. The Agile Manifesto says that our highest priority is to satisfy the customer through early and continuous delivery of value software. And agile isn't about delivering low quality. High quality is critical to agility. The manifesto says that WORKING software is the primary measure of progress. And continuous attention to technical excellence and good design enhanced agility. It sounds like you are attacking a strawman of agile without knowing what real agile is. p.s. I understand that 90% of the time, corporate implementation of Agile has been terrible. I have a whole podcast episode about it here - The Agile brand has been destroyed by con men and clowns https://tinyurl.com/3deb8m3w
Thinking is banned—or so it seems. Nearly all political, economic, and business decisions appear to be driven primarily by PR. Truth seekers are no longer welcome. Instead, the nasty breed of so-called "good rule-followers" seems in vogue. Ever since "agile" became a noun, it has followed the same path as SAFe and dozens of other hypes, such as: - Automotive SPICE - CMMI - CMM - OOA and OOD - MBO (Management by Objectives) - OKRs - Business Reengineering - Design Thinking And so on... You know the ones. They are all intrinsically flawed. The problem is that most people believe that creativity, meaningfulness, passion rooted in a genuine desire to help others, and authentic, human-centric thinking are too straightforward to be "packaged" as the next big hype. And simplicity is backbreaking work. Do you like the social group you’re working with? No? Then just forget it.
I think you are conflating the asks of bad Project Management with the ideals of Agile. The whole reason Japan was able to retool was because we had bombed their industrial complex into the ground. At the time we were too invested in antiquated equipment and processes, so people like Deming took their ideas to Japan, which welcomed them, and eventually they surpassed us in manufacturing capability and quality. I think this is the real lesson here: Agile came about because we were still invested in Taylorism, but Taylorism didn't work for software. We have had no across-the-board forcing function like Japan, and thus most places still manage to Taylorism, and Agile still cannot work. Only places who are willing to be "bombed flat" can take advantage of it, by building business processes and cultures that follow Lean/Agile. How many colleges have even embraced these concept as the basis of their business curricula?
Your post resonates. But people really need to stop saying hyperbolic things to catch social media impressions, like “agile is killing your productivity” and “agile is dead.” That sort of hyperbole serves no one … respectfully, as you’ve made very salient points in this post. Saying “agile is killing your productivity” is like saying “nutrition and dieting is ruining your health.” No, poor nutrition and malpracticed diets are ruining your health.
There's so much wrong with this post that I wouldn't know where to start. So, I'm not going to. Clickbait. I'll leave it with the remark that agile wasn't created for speed, but to continuously get better at developing software. However, I am curious about "the data is shocking." Where does that data come from?
Companies seem to think that Agile is this worderful drug that will fix all their problems. If you don’t know what you are building, agile will help you do it faster. If you don’t restrospect, you are bound to repeat the same mistakes. If you accumulate tech debt - that’s right, you will continue accumulating tech debt. While agile encourages to create best practices, it is not supposed to fix any of that. The only thing it does is help the teams become more flexible and not plan their work 5 years ahead, and then throw away half baked product after the market inevitably changes.
It all comes down to the management approach of your company. Contemporaries, James O. McKinsey and W. Edwards Deming had different, yet successful approaches. Same for software delivery; there are different, successful methods. Companies need to pick a software delivery approach that fits with their management approach. McKinsey: Top-down strategic planning and financial management, focusing on high-level changes and organizational efficiency. This has led to significant successes by providing clear strategic direction. Deming: Quality control and continuous improvement, emphasizing eliminating waste and involving employees. His methods (instrumental in Japan's post-WW2 resurgence, as mentioned) significantly improved quality and efficiency in numerous industries. Now think about your company: which management approach does it best align with, and which software delivery processes have worked best? If your organization aligns more with McKinsey, you might need to adapt Agile practices to better fit your strategic, top-down approach. Conversely, if your company aligns with Deming, Agile methodologies might be a natural fit, emphasizing continuous improvement and incremental progress.
What you’re referring to is definitely not Agile, but fake-agile. Keep applying old ways of working and thinking, throw in some ceremonies from an agile framework and let management put pressure on people the old-fashioned way. Let’s not fall in the trap of feeding false narratives. Besides that fully support what you are saying. Time to think critically, reflect, identify patterns,… is what is done far too little these days. Speeding in the wrong direction is anything but productive.
Bad usage of agile is killing everybody's productivity. Sprints are no longer value driven, they're just a repetition of a consecutive 2 week broken down schedule. Kanban boards that dont represent the workflow and dont generate clarity for the teams, they're C-Level reports. I could go on and on... But, the thing is that your post is right about slowing down to be able to learn and develop good processes, people have completely forgotten how the've learned to tie their shoes: slowly, so that you can understand how it works (execute, see if it stays tied up, analyze and understand, repeat), if you keep rushing it, your knot will end up a little loose, and that applies to any new activity. However, you also seem to be putting the blame on the "tool", Just like blaming all hammers for someone's inability to use one.
Founder and CEO at BetterSoftware.dev | Revolutionizing Software Excellence | 25+ Years in Software Transformation & DevOps
2wFor a demo of how to use Agile and enjoy the benefits, please comment below and I'll send you the demo!