Agile & Scrum Don't Work | Allen Holub In The Engineering Room Ep. 9

Most companies don't want 'agile', they want high throughput waterfall; they already have the scope, date and resources decided. They just think agile will somehow magically increase productivity (and blame the devs when it doesn't).

I took some notes: Agile != scrum XP (extreme programming) is where the value is, with or without scrum Scrum has become tickets, estimates, meetings Nobody can get better at estimates, something always comes up Agile means be ready for what comes up, embrace the change Agile does not mean rigid predictability Corporations crave rigid predictability Accountability and commitments are “the language of violence” because they imply punishment “Do as you are told and if you don’t then you’ll be punished” Agile is about self-organizing teams, not a top-down command telling you what to do Show something in 2 weeks, go from there. That’s agile. Deliver small, incremental changes. Continuous improvement. That’s agile Big systems take on a life of their own, even a CEO can’t change it Agile is not about a full overhaul of the system You don’t need an Agile Coach to restructure your whole organization Ripping apart a whole system for full change is too risky and expensive Having silo’d teams with single purposes that are cut off from eachother is not agiles Trying to change that all at once won’t work The “disagree and you’re fired” attitude is too common – can’t do anything on your own Nobody thinks this is winning, unless they’re a sociopath Give individuals the power If you’re not happy, you’re not doing it right Does the team feel like a team? Are the teams worried about deadlines? About being punished? Work life balance is also part of agile The idea of “metrics” and “productivity” can be toxic if misapplied Developer productivity metrics are all indirect metrics Deployment velocity for example – deploying every hour isn’t necessarily good, and deploying once every two weeks isn’t necessarily bad. Rushing to deploy garbage Going slower and delivering more value There is not a metric for value Work experimentally Good change, continuous improvement, kaizen Scrum and Kanban are complementary. Saying you can’t use scrum with kanban is wrong “No sprints, no projects, no estimates”, new book idea Develop software as fast as possible that delivers real value How do you change an org? Are middle managers really necessary? Do teams need a “near” leader? Leadership should say “Here’s the problem, go solve it”, and support the team in that Nobody is entitled to their opinion unless it’s grounded in fact All opinions are open for debate How to do Agile? Ask what the problems are Distill the problems down to the most important one Solve that problem Repeat Usually the problem is that there is not enough value delivered fast enough How to fix that? Build a value stream map, find bottlenecks, try small incremental experiments Have some way of knowing if your experiment is a success Not all metrics are numbers Decisions need to be made close to where the work happens Teams need to make up their own processes and be educated on options Not told what to do The notion of agile is a self organizing team self organizing CI is get good software faster CD is a newer tool to help with CI Read the agile manifesto – it’s 5 principals and 12 practices, it’s not a long read The implications are big, though https://holub.com/heuristics/ can give another view How do you get self organizing teams? Ask, what is a small change we can make today to see results? Avoid too much emphasis on numbers Everyone has an opinion, check the opinions with others Talk to people. Start with one person, then three people, stop somewhere before 50 Let’s make less capable people more capable. There isn’t a worker shortage It’s crazy that organizations don’t want to let people learn on company time Direct access to production being limited implies a lack of trust Myth of the slacker People need training and mentorship, not performance reviews People generally want to do a good job Managers go to punishment too quickly too often Whiteboard intelligence tests are no good How about you work for us for a while and we’ll pay you? Knowing code, knowing math, these are not the most important skills Knowing how to problem solve, how to look stuff up, that’s important Knowing how to talk to people, how to organize yourself, that’s important Do you think algorithms are fun? Inspect and adapt Read agile manifesto Learn how to understand what is important and what is not Read Dan Pink’s “Drive” Find a company that matches your motivation and work there. Find what makes you happy and do that.

Anyone remember how the original agile manifesto came about? It was software engineers at a ski resort figuring out how to take back control of a process drowning in bureaucracy. We now have this product called "Agile" with a capital 'A' far removed from the original intent, we've come full circle but with added marketability.

7:49 ❤ ❤ ❤ "agile has become a priesthood where the priests don't understand the rituals they're telling people to follow"

"Imagining they have certainty when they don't" and when things don't work out they either "drop into blame or drop into craziness" ---- ABSOLUTE TRUTH RIGHT HERE!!!!

Having a job in a scrum team really shook my confidence as a developer. On the one hand I'd come from a different background and did have a lot to learn... but, it was meeting / process heavy and I felt a lack of freedom to approach problems in the way I knew how to get my head around what was going on. I agree with the problem with metrics for two reasons 1) If you are judged by the metrics you will chase the metrics, not what the metrics are supposed to measure 2) You will get stuck in local minima, optimising for the best short-term solution, and not for long-term growth - which requires keeping the technical debt down. I also generally hate the lack of ownership you have when everything is dished out in sprint tasks, there's no pride in having accomplished something, just temporary relief until the cycle starts again.

The most productive, and successful, team I've been on was a group of 10-12 software engineers all in the same room following XP. Paired at computers around the room, a big whiteboard, postcards with stories on them for everyone to see and choose from, just a little direction from the more senior in the group, and the customer representative sitting in the room participating. No pull requests, everyone committing to main, with the only rule being you had to have the token to commit. The token was a large, plastic, toy trident. Significant parts of that software are still running businesses 21 years later. When management buys in and allows real XP (and with the right people), great software flows and developers enjoy their jobs.

I love this conversation. As a developer, I've been put in a position where other devs have come to me privately and said, "Maybe you can be the one to convince management to do something better." That does not work. Because if developers have to talk to me privately about that, that means management is not open and willing to make necessary changes. They might say they are but will always be willing to waste hours of your time using logical loopholes to convince you to agree with them. So, begrudgingly I've learned to do what every other developer does. Keep my head down, complete tickets, and use personal side projects to fulfill career goals. The current "interpretation" of agile is the result of tyrants who aren't willing to allow devs to do their jobs. And I think that's also why it's not going anywhere anytime soon.

I love how true-speaker this guy is. "I use Agile word because I'm consultant, and otherwise no one would hire me" is the simplest true showing main issue with Agile... Especially out of IT :)

Wonderful conversation. Finding myself nodding along to all of this and feeling like some sanity is being restored! Ahhh!

I agree 100%. The worst type of scrum is when people follow the rituals without understanding why. The basically do cargo cult scrum.

I don't agree you can't do kanban in software. I lead a team in 2010ish in which it was very successful. You don't "go back", you fix forward. If you're doing small enough changes it won't matter too much, the fix should be fairly trivial (most of the time). If it's not, you've got something wrong, either the architecture, the size of change, the complexity of the solution, or something else. Time to stop the line and have a rethink entirely, in that case. I can't remember a single time where we had to roll back rather than fix forward.

If I was in college right now and majoring in computer science I would take extra math like liner algebra and electrical engineering courses to get jobs in more math intensive industries like inertial navigation systems because they tend to be more scrum proof. Agile scrum makes me glad to be nearing retirement. Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.

Thank you both Allen and Dave for sharing this talk with us. Shame on me for making any comments without having first shown appreciation for the great talk.

I like this guy's attitude.

Allen Holub is my spirit animal.

Thanks guys for this great talk. I totally agreed as you sayd "we need to talk to people". That's so important. Understanding what drives people to do things is key in my opinion. As i was listening to your talk i wrote down some dumb errors i made today and I'm going to fix it tomorrow. The error was, that I am as a mentor of my colleague have done the main part of thniking about a problem but she needs to do this thinking to evolve this kind of abilities. Thanks again for this inspiring talk.

Problem is, training and mentorship 1) don't have much to do with commodity programming delivered by the staffing agency industry, and 2) the clients of those agencies make sure the resources stay 100% utilized without allowing capacity for training and mentorship. It's a recipe for institutionalized mediocrity.

I really enjoyed that — the best interview I've seen all year. It didn't hurt that everything Allen said resonated strongly with me…

Thank you for this! It was a delight to watch two of my favourite Software Engineering Educators collab on such an interesting topic!