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).
This is exactly the situation in my company. Everything is fixed from the beginning (requirements / list of features, budget -> resources, deadlines for each feature), then they say "now be agile". The main problem is whatever they fixed (requirements, resources, deadlines) were not based on any real design process (since BDUF is not "agile"), so they were just pure "essentially random" estimates! What a horror!
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 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.
That’s an amazing text summary. I tend to use timestamps and small notes. But UA-cam comments doesn’t like edits. You probably wrote that elsewhere first
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 think an open room with a whiteboard is probably the biggest key here. I like working remotely, but Slack and Jira tickets are just a stupid waste of time. I think for remote work to be efficient you need constant conversation and a flow of ideas. And I never see that. I see business sending reminders to merge of X date, and devs that don't want to be bothered because they're doing their little ticket and find all the chat noise to be a distraction. I worked in a similar environment, and it was mostly a good thing, but it was still everyone doing their own thing, and that eventually drove me crazy enough to leave. Now I just want to do my little tickets, clock out, and work on a real project on my own.
I wish one day decision makers will understand this basic construct. Organizations have no idea how much waste they accept by following outdated practices. Those who understood it, emerged as market leaders and rest still focusing on local optimization.
@@centerfield6339 what's perfect hiring? A mix of people that are fast learners and people that can teach by doing. Usually there's a lot of luck involved.
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.
Wow such a testimony. IMO, the real lesson here is if they have to 'secretely' come to you rather than openly Talking about it, then Agile doesn't work either. Is not a framework open to change, not what they promised it to be, not a place for open conversations
@@Aksamsons lol are you seriously asking? Agile/Scrum is not about developers being courageous. Is to bow their heads down and "crunch" more and more and more. Don't be fooled by this "democratic flexible conversations" because they are not democratic nor flexible.
It resonates with me! Thanks to idiotic system that see knowledge engineering work as an assembly line, I close ticket after ticket, don’t give a damn about anything else. Side personal project, and the one I can monetise, brings me joy, grow and satisfaction.
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 :)
"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!!!!
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.
100% agree! ❤ I still have like 15 years till my retirement. I have enough of being treated as a kid from a crèche that need to justify every single hour of each day…
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.
I think they have realised some of their mistakes, like they have renamed "ceremonies" to "events". But it almost looks like too late for Scrum to improve their situation. I had high hopes in Scrum, but some of the elements they have, like their explanation of the planning, are plain devastating. "Team works out what can be done in sprint". What a misconception. Team shouldn't think what can be done in sprint. They should take a problem and come up with a solution to this problem as a result of the sprint. How deep the problem can be solved - this depends on the maturity of the team, their process and the technical foundation of the product.
Fully agree, it is the reason for so many software applications going nowhere and ending up going to the dustbin. Beautiful ceremonies but nothing beyond charts and some useless visibility charts. Agility is completely different from using Agile/Scrum methodology.
This usually happens when the management is non-technical people. If your manager was a software engineer for 10 or 15 years before he became a manager, you will not lose time with such silly explanations.
@@ForgottenKnight1 Some people convert.. in an effort to push careers. A lot of engineers also have a completely wrong understanding of agile.. when they become managers.. it’s more of the same too 🤨
As a scrum master, a lot of what was discussed resonates with me and how I run my teams. I ditched a lot of prescriptions and added my own. Some of the points felt like a stab to the chest but they are true statements. Scrum has almost become a cult. I also learned a great deal of new information and I'm barely half way in. Please have more discussions like this- our community needs more healthy disagreement
TL;DR: Scrum is bad, kanban is bad, metrics are bad, lean is bad, data driven is bad, estimates are bad and agile in general is broken. What is good?! 🤷 The only advice in the end - learn what makes you happy and try to find the right company (which is usually impossible to tell even few weeks in, let alone during the interviews). As much as I enjoyed "two grumpy old men" complaining about basically everything, there is unfortunately not much info value in this one IMHO. Anyway good to hear you discussing interesting stuff as always Dave! 🙂
What I took from the "everything is bad" tone is that practices are being adopted with little to no thought to the fundamentals of agility. Most organizations are introducing agility by process piling and not stripping away the root causes that are hampering adoption. In the end, find the culture that fits how you want to work and they did give some good insight into the hiring processes that would be good leading indicators to that point.
I also picked up a nugget that teams need to be free to pick their own process. If you dictate a process (Agile or Scrum from a book), you aren't letting them be agile, and they will resist it. Another nugget is that teams should have internal metrics to see how they're doing but those shouldn't bubble up to management to be held against the team. I thought his statement was interesting that he would get rid of sprints. I think it's arbitrary to time-box a task that will surely reach completion at a moment that isn't perfectly aligned with any multiple of the time box. You might reach the end of a sprint without the mini-feature done, but then on day 1 of the next sprint, it gets finished. Trying to guess what to fit into a sprint is a form of overhead. Better *maybe* to just break tasks into bits that seem small and pick one and work it to either completion or temporary abandonment. If a task turns out to be a sinkhole, you can say you'll stop for now and revisit it in the future.
@@dubiouslycrisp I see this a lot. Leadership says we are "doing agile! Here's your process! Go forth, improve output, and update the weekly status report PowerPoint so I know your doing it!". Most teams will then pile the nomenclature and framework events on top of the existing process and slowly die under the weight of it all. Good call out.
I have found that most underperformers are simply demotivated employees. Give them a good job that they enjoy and you rarely have people who underperform. I do agree with most all of what you both say though.
I've been in software development for over 20 years. I've never seen different organizations or different teams in the same organization practice "Agile" the same way. There is ALWAYS some influence based on management, corporate culture, internal team dynamic etc. I been been on projects where Agile has worked very well, and others where it's been a nightmare. Here's what makes Agile work when it does work: 1. A good scrum master that actually knows how to facilitate meetings, to elicit honest responses from team members, and is a strong advocate for the team when communicating with management . 2. Managers that know how to butt out of the development process. 3. Team members that are honest with each other, communicate well with each other and are willing to help each other out. 4. Not only have retrospectives but to take actions that come out of those meetings that actually improve teamwork or development processes. 5. Team members willing to admit "I don't know what I don't know". This is especially true at the beginning of projects. 6. Sprint grooming and planning that flushes out as much detail as about stores so that acceptance criteria, and definition of done are actually accurate or as close to accurate as possible. Corporations have drunk the Agile Kool-Aid and they are loathe to admit it doesn't work, that would mean they have to come up with something else. Management isn't going to take the risk on the unknown. The best most of us can do within those confines is make "Agile" work the best we can. Railing against Agile is fine. Coming up with something better is much more important, but also more difficult given that Agile is so entrenched in so many corporate I.T. projects.
Do you tell an artist how to paint, sculpture or compose? How do you determine if something is better and how do you meassure it? Real honesty that hurts was a problem i encountered. Most ppl in my company used Windows with a Linux VM to develop for a yocto nav system. They didnt even recognise how dumb and inefficient that was. It simply was watching the titanic sink. I was looked down at because i simply used Linux directly as dev OS and had to explain myself why i didnt had Windows + company firewalls and AntiVir al the time running + with a fixed collection of progs for the Windows users. It was so below any intelligence that it was scary. Should i have told the win admins that they are completly useless if i dont use win at all and point out how expensive there meaningless existence for the company is and get all the nice expected feedback of them. I just watch the titanic sink while looking out for a better job. And afterwards i am not able to talk about this in my applications for other jobs until i get the job and then most likely the spiral starts from beg. How can i be honest if honestly your job is a waste? Why am i forced to point you out as the actual problem from a human point of view while we all depend on an income and have to take part in the daily darwinian survival that is called capitalism.
I have to agree with Carl. Look at all the points he listed. Fact is, Agile can work, with great teams. Where Agile fails to work, is when leadership (management) doesn't own or understand Agile process. Let the team figure out the best form of Agile for themselves. This is true Continous Improvement.
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.
I second that. In Kanban, columns are also an indicator of the effort already put into the task/story. And the tasks on the right side have more priority than the others, as we focus on delivering the stories closer to the "done" stage. So, moving the task back to the previous step on the kanban board clears down the knowledge about the effort invested here and automatically deprioritizes the ticket.
In the early '70s many programmers were former English teachers who wanted a career change. Also 'computers', which was the term for people who drew contour lines on maps. One I knew who worked at a government service bureau had a drafting table next to his desk - he still had to do his old job too, while waiting for full automation of the task.
Two of the rare consultants speaking their mind about what is going wrong in the software industry… It was meant to be a great conversation… and with a lot of agility :) they meet my expectations. In my opinion, Allen describe everything in 3 words, we need intelligence!! Seems to me that their is no more critical thinking, everyone is looking for the magic recipe… and it will probably get worst with the current talent shortage. And it explains their disagreement on metrics I think. If the metrics is the results of smart decisions, that took into account the particular context of the company, we should expect on average better outcomes. If companies start focusing on those metrics and search for magic recipe to reach them, we may start seing companies with good metrics and bad outcomes. Body weight is normally a good indicator of fitness, but it is the result of fitness oriented behaviours. Focus on weight and suddenly it can become a psychological problem. Human being human, and even so management being management, don’t give them more metrics to monitor :)
From my limited experience working in an agile manner, both with Scrum ceremony and without, it seems that all the ceremony is to justify billing. When developing software for our own company and not for a client, we are just trying to create valuable features, deliver them incrementally and gather feedback in a natural, common-sense way. I always believed that we were to small to do Scrum but somehow our approach seemed better. This interview was eye-opening.
I worked on something recently and we thought it would take about 5 days to get it done. It ended up taking about two months. Fixing one problem uncovered a lot of other issues related to complicated math in the simulation that took quite a while to track down and fix. There was no way to see that problem ahead of time because nobody had any idea the problem was there. At some point it seemed the Agile process we were taught just started to break down for this. The code ran, the tests passed, but the tests also ended up being wrong for some of the same complicated math reasons. For scientific and simulation software at some point I have found you just need a few people that work together on an issue and get rid of all the worrying about sprints, tickets, scrum, predictions on when it will be done etc. stuff. There was no point in adding more people to the team to speed things up because there was really not much they could do to help. It was better to have them work on other projects. Especially when a combination of programming and graduate level math skills where needed.
I think this speaks to the fact that "stories" appear to be oriented around the idea of creating a webpage or video game with a bunch of little pieces and buttons, rather than acknowledging that you can have one end "feature" which is very complicated.
I like the conversation. On the 'soft skills' side, people bring a lot of their personal beliefs to work. If they believe the same things you do about how to work, then it's pretty straightforward. Give them the information they need to be successful, and they're off. But if they don't believe or what you're suggesting isn't something they're familiar with, telling them won't necessarily get them on board. To me, that's where the soft skills come in. You have to find ways to help them get to the same place you are in terms of why this way of work will be successful. While I fall mostly on Allen's side of the fence when it comes to life coaches, there are a lot of personal conflicts where some of those skillsets can help a team move through conflict and be more successful.
I do think that a lot of the problem here is that there is a fundamental lack of understanding both by senior management and by development teams. The simple fact is that if you’re working in an organisation whose business model is to find a customer, build them something for a fixed price and then take 30% margin then you’re going to end up with a middle layer of management searching for ways to get more value. When you’re stuck in the ‘iron triangle’ of cost, time and features, all you have to work with is process and team. In that scenario, of course people are going to be looking for new ideas, even if it does mean taking out a massive hammer in a doomed attempt to bash a square peg into a round hole! My problem with the current discourse though, is that what seems to get set up in these discussions is a massive rift between development teams and ‘management’ which is toxic and unproductive. There’s always this demand for ‘management’ to educate themselves on development processes but where are the engineering teams who are educating themselves on how their businesses actually work? Who is asking their finance directors questions that help them understand what they would need from engineering in order to adopt these ideas? Who is talking to project managers to find out how to better contract with customers so that modern development methodologies actually become an option? Who is working with sales to help them make pitches to customers that encourage them to want to work in this way? An engineering director I used to work for once said to me, “It’s much better to be inside the tent p*ssing out than outside the tent p*ssing in!”. If you want to be working for a modern, high performing, exciting team, you might be asking the business to completely tear up a business model that is profitable and feels pretty secure to your senior managers. So be prepared, ask questions with an open mind, and engage constructively.
I agree. This isn't about evil bosses, this is about finding better ways to work for everyone, and we have. There are lots of orgs where dev teams educate themselves know how the business works, at least in the context of their SW. The sensible, senior techies probably more than that. This kind of collaboration and understanding is one part of what really makes agile work and is essential to really high-performance. It is difficult because it challenges nearly everyone's thinking about how stuff works best.
I want to acknowledge the reference to the business model. This is neglected in 99% of the times when software development practices are discussed. If you have a start-up and you run a single product development, that's one thing. You have to be agile, feedback driven and stuff. On the other hand, as you mentioned, if you are a company that runs software development projects for others you are stuck with waterfall within the iron triangle. Very seldom you will have time and materials contract, a fix budget, fixed schedule, fixed spec is the most likely option. The idea of delivering a product following the "it's ready when it's ready" principal is also not an option. The sales stupidly sells "agile" to the clients which perceive it like "no planning or design is needed" or "changes are free of charge". And you also have intrinsic uncertainty of software development and that 30% margin you want to make. Development process management of such projects also sucks. Sucks like using burn down charts as a measure of progress reported to the client or running meaningless Scrum routines just for sake of it. In my opinion what software industry needs is waterfall adapted to the software industry reality. Most properly sized projects don't usually run into such massive uncertainty that can't be compensated by a reasonable contingency plan.
@@oleksei3371 It goes further than just the business model too. The sector I work in is primarily driven through tendering which forces all suppliers to work this way. It’s a shame, I think the CD way could work. I’d love to see a tender that is looking for a long term development partner who can work through a programme of delivering new or upgraded capability to the customer rather than a set of (usually totally crap) requirements. They would get so much more value from that IMO. We’ve still got a long journey ahead.
@@Microman6502 Business to Government? Yes, I worked in that too. And I have also questioned this a lot. There are two things that prevent this from changing: anti-corruption laws and qualification of the client. The specs are written upfront, then RFP is issued and proposals are collected and the lowest bidder gets the contract. This way everyone is 'clean'. If the government prefers your company over mine based on other criteria that are not so obvious, I may sue the government. In the current situation it's just the question of mathematical operation to choose the winner. There are actually exceptions, but this is usually the case when there is a preexisting product that government wishes to buy and tune to own needs. As such many governments use Microsoft products and cloud (at least what I've seen). Finally... Well, government officials make terrible product owners. They are seldom motivated or incentivised, they love to 'share and push responsibility', and you have to wait ages for any decisions. Basically, if you want to have some success in this realm - build the MVP first, and try to establish (sell) expectations (the spec) more or less equal the properties of your product, then be the only applicant for the tender 😁
I've worked as an IT consultant for the past 20 years. Seen alot of bad stuff, and while I do agree that there's a fair share of engineering teams that don't want to educate themselves on how their business actually work, it seem to stem from a place where they've tried that but have been met with a wall of uncooperativeness on the non-engineering side. Uninterested engineers, in my experience, correlates highly with incompetent management and lazy staff. The number of times I've tried to facilitate between the two only to be met by either silence, non-cooperativeness, or flat out refusal to do the proper work on the management side, is staggering. The number of "business people" who don't even know how to construct a proper business case is through the roof. The number of "business people" who can't formulate even one high level acceptance test beyond "it should work" is absolutely massive. And I think i know why: asKing non-engineers these questions often imply the non-engineers have to actually perform work. You know, actually do things. Tangible things. Correct things. Things that are in their job description. And output results that are at least somewhat certain, to the point where an engineer can act upon it. And in my experience, there's alot of people in alot of positions whose sole purpose is to do nothing and lift a salary each month. The moment they are forced to think, they want out.
Can't wait for the Book... In my 1st week at the 1st meeting in work I aligned with Dev. Teams and exactly told them let's learn together how to say No, and focus on fixing things need fixing here and now as a start! My core objective is keep devs independent, protected and engaged on there own just to make their life easier and love work, everyday we try to make things simplify how we work get things done clearly and we all involved getting our hands dirty building, fixing as we enjoy our work
Wow! Too many things to chime in on. Great talk! Count me in as a grumpy old gal who also agrees with everything. I was an English major lucky enough to start programming in the 70's when an interview consisted of the IBM programmer aptitude test. Then you had to pass all the exams during the first three months of working through the IBM self-taught assembler course. I remember asking a colleague during training about this language called assembler. I had heard of COBOL and Fortran but not assembler. Will it be useful to learn? Don't worry about that, he replied. It will definitely be useful.
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 should also mention that my way-of-working has always been what has become known as agile. It is because my approach to writing software is the same as any writing assignment: Do research: analyze the audience, topic, and context to come up with an approach. Then revise until done. Writing is revision. Going back to research as needed- this is a recursive process.
I really like the following definition of agile - "quick and well-coordinated in movement." I am a solo-hiker and there is hardly anything that is more agile than hiking. Move fast, but watch your steps, regularly make a break to check the map and adjust your route basing on the landscape. Still, make sure to stay hydrated, pick proper places to pitch a tent, sleep well, and keep feet dry whenever possible. The next hike, review your tools to be more effective based on what you learned.
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 work in one of these big places that had company-wide agile overhaul, with accenture consultants coming in to indoctrinate us in their brand of agile, which largely means a domatic approach to scrum. The whole thing has been aweful, treating experienced developers like they're little kids that all need to use the same little system of organisation where every little action has to be documented with its value and estimation constantly negotiated over with people who can't necessarily develop getting injected into the scrum master role as a quasi-manager. We were told at the start that the scrum points system wouldn't be used as any kind of performance metric. Afterall, points between people/groups can be a bit apples/oranges. Cut to a year or so later all that's been forgotten, performance review directly focuses points of work delivered. It seems like a strange thing to say but I always felt there was an aspect of creativity in this job. You're given an objective and you use your knowledge to break that down and come up with a solution. Now every thought is intruded upon and vetted. Absolutely horrific. Handed my notice in last week :)
I am sorry to hear your story, it is all too common in my experience. I agree with you that good SW dev is a highly creative process. The people that try and squeeze the creativity out simply don't understand what SW dev is. I wish you luck with whatever comes next. I don't know if this will help, but just in case it does, I made a video on how to detect signs of competence in prospective employers: ua-cam.com/video/2Afk9KVEgpE/v-deo.html
@@ContinuousDelivery Oh not to worry, I have another job lined up to go to. Part of the interview included some talk (initiated by me) around their agile/organisational processes and they sound lot more reasonable. Let's see how it goes!
A lot of hard-earned wisdom in this conversation. I do have one bone to pick: I implore the participants to re-evaluate kanban and lean manufacturing. "Rework" and/or "going back" is not prohibited or even mentioned in the eight Muda of Toyota's Philosophy, and Kanban can absolutely be effective in software engineering. In fact, I've personally seen it be highly effective within teams at AWS and Google.
I don't think that I have ever enjoyed a conversation, let alone a conversation that I was not a part off, as much last this one. At least not for a long time. I am sure that I will be rewatching this. Perhaps multiple times.
In my company we sort of reinvented XP 😆 We threw away all the "garbage" from Scrum and only kept what we thought was really useful to us and .... bingo, without actually planning for it, our development process is textbook XP. This tells you that XP is really all you need.
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.
Allen makes a point that I have always thought: “money driving the process”. Business gets in the way of advancement because they cannot trust their experts to work on their practices. A difficult struggle indeed.
Probably third time I'm watching this episode. Everytime I find something valuable. And when I try to find the 'WHY' with my very limited experience, I recognize some patterns. 17 engineers/architects/scientists devised something 21 years back. We are expecting mostly non-technical people will understand the thought processes and align with that. Very high expectation.
Technical people are people of logic and data. "Yes, it sounds logical, but..." or "Yes, the data shows that we need to do this, but..." - do these phrases of non-technical management sound familiar? :)
I fully agree with your view on math skills in programming. Besides some very specific fields, like writing physics engines, or graphics, you really don't need much. I still thing algorithms are good to learn, but not as deeply as is often taught in CS. At least at my uni, Big O for example did not get enough time, but hey, at least we learned to perform a ZIP compression on bits with paper and pencil... For "pure" math, I'd say linear algebra, some formal logic, and stats is plenty enough. Stats in fact is pretty underrated in my experience, especially for higher level reasoning about architecture, it can be really important, and not many people have even the baseline neccessary knowledge.
14:35: “Do the most important stuff first so you know you won’t fail”. That described my experience with waterfall, and then I stepped into Agile for the first time and was blindsided. It was truly awful. Could not get work done at work, but was busy as hell. Then had to do the real work at home
When I dev I work for only a few hours a week. An hour a day or so + meetings. I give excuses as to why it's taking long. I'm very good at my job so I barely work at all. The only reason I'm there at all is because they refuse to pay me otherwise. You may call me lazy but I don't think that's it. To do more than I'm doing would mean doing more than everyone else. They would look bad when compared to me. They are after all doing the same thing. They are dragging their feet hoping the project will last until the end of time. To finish the work would mean to get fired. They don't have any incentive at all to do a good job. Even if bonuses or promotions are designed to spur on the work, the truth is that there's no benefit at all to doing a good job. No one cares what improvements you have in your head. I've personally been told my ideas would fix the problem and even when I offered to do it in my spare time on my own dime I was told no. People don't want to solve anything at all. They just want to continue with what they're used to because they're afraid it'll get worse with every change. And it usually does get worse with every change. So they aren't wrong. Let's be clear. The system we have built with employers and managers and owners and leaders and rules us broken because of the things the system is made of. The rules are the problem. Employers are the problem. There's no cooperation here at all. Employers own employees. Employees are the ones doing everything but are not allowed to use their mind at all. If they did, what would we need employers for? What does a boss do? Managers are not managing anything. They sit around and pretend to care about reports. It's 100% pretend. Employers aren't any smarter than employees. Slaves don't have lower intelligence than slave drivers. We live in a world of lies and the liar is us. We are the ones doing it to ourselves and we do it by choice. We know we're doing it and we do it anyway. We know climate change, pollution, war, famine and every crime people commit against their own family are the things we do. We're doing them. Not someone else. Still we keep doing it.
😪 I love you guys. ❤ I am a philosophy major programmer and you just understand the world of development like no other I have met. One caveat: big companies exist for a reason. Their culture protects them and probably agility is not for them. David doesn't always win, especially if Goliath is in an environment that suits him. Let's keep challenging Goliath with our Agile approach but don't fall for the misconception that what Goliath is doing is bad just because you don't like it.
Hi Juan! They are so true. But know what: problem is that almost none in industry, especially on recruiting, has abilities to estimate needed skills, measure if position and applicant match and credibility to voice it so that it could steer decisions. But basically: if you know how to build highly scalable resiliant distributed system by heart you also instantly know if you have met person that can help you and what kind of role this person can successfully take as part of development team.
This dude is delivering a master class in moving goal posts in order to not concede a point. (Enjoyable talk otherwise, lots of interesting things said overall.)
These are the exact thoughts (Well, most of them) I had when I read the agile manifesto + Principles and how people are working in the so-called "Agile Environment" ... it is frustrating... Thanks for this great conversation
That's fine by me! My hope for this channel is a sharing of ideas, so that people can shape opinions and learn. So disagreement and debate is all part of that. So thank you for not agreeing with everything 😂
I can't believe how convoluted such a simple concept has become. The problem is getting people out of the quagmire #noestimates My approach is to follow the processes and have all the evidence when I inevitably get it wrong. No overtime no stressing, no fuss. I can't fight the process but I'll have to slowly over time show why it's broken. When you understand what should be done you can challenge what is being done
Great discussion with 2 wise old men! However, I would like to add, that scrum, like all other tools is only appropriate for a specific sort of teams and problems. Before you use it, learn about the nature of your problem and select the appropriate tool to fix it.
What a nice discussion! Exchange of ideas through experience. Discussion on metrics - this bothers me a lot. IMHO, we need to establish process is such way that if needed we would to have capability to invetigate metrics - it is like adding logging to production code. You don't need if everything is fine. The more you have the better, if it does not affect performance, time required for implementation or costs significantly. If do not look at productivity, then people will use outdated tools and tech, always trying to reinvent the wheel. Productivity comes from defined coding practices of a team, not from output or outcome metrics. I think productivity influenced by discussions and code reviews, from "ideas in the kitchen", sharing. Thanks for video. Was interesting.
Interesting conversation about metrics. Just because you can compute a metric doesn't mean you can compute/"backpropagate" it's gradient. This is why we have to stochastic optimization techniques. Seems silly to discount metrics due to incompetent "management".
@@Tymon0000 My goal is to eradicate polio. The metric I use to measure this is the number of polio cases. I attempt to get this metric as low as possible. If it goes up, I'm doing something wrong. If it goes down, I'm doing something right. If the number of cases is zero, I consider my job done. Does "the number of polio cases" become a bad metric when used as a target for the goal of polio eradication?
@@jimmyhirr5773 I would argue yes, because we know that metrics can be flawed, you might not capture all of the cases and so miss some, a metric of 0 does not mean you've achieved your goal.
Great discussion! Compiler Design in C was immeasurably helpful to me at my first job. They designed screens using some PC software (forget which) and asked if we could "convert" the files to AS-400 screens. I wrote the parser and another guy wrote the back end and we had the first screens running on the 2nd day. A big career boost my first week and not long after I was working on OS/2 in Boca Raton. Not Agile related, but many thanks Allen!
Charming old chaps. Some wisdom. Some noise. Highly enjoyable. Thank you. I could have listed here some very insightful quotes, but you better pick up ones fitting for yourself. 💯
Scrum's intention is to teach the team discipline, teamwork and effective processes to help them achieve their goals. Once the team matures to a point where Scrum is no longer necessary, then the team can move to the less rigid Kanban framework.
I agree with you, before changing the process, you need to master it. Rituals are there to bring the change. Everyone is against estimates, but we need projections . So I see implementing agile is first working with business management . That is good to force business to identify what brings 80% value from 20% development. Then continues deployment - I rather say deployment on demand . Not continually…
Dave-thanks for this. So many truth bombs in one convo. Happy to hear more (but first I need to listen to this 5 more times). Thanks for giving me a transcript too!
Been working with Agile for years now I am very very confused. I think it's a form of institutionalisation maybe. It's kind of a comfort blanket for me as a developer (and team lead).
I think that you are describing the Scrum anti-pattern that Allen and I were discussing. There is nothing whatsoever that is "institutional" in the agile principles outlined in the agile manifesto, but many orgs have subverted these principles and agile for many orgs has turned into a new way to operate a kind of "command and control" strategy. If your read the agile manifesto, which defined "agile" as a concept in SW terms, there is nothing of "command and control" in it. agilemanifesto.org
In my experience daily scrum meetings extremely helpful to boost team morale and get results. In real life a lot depends on leader and real leader blames himself in case of failure, not tools.
This was fun! So many topics. I wish I had taken Allen’s UCB Extension compiler class decades ago. I would probably have solved the C stack frame question by dropping into inline assembly - not portable, but it would have been easy. I wish I could have a beer and get into an argument with you guys. I used to have good discussions at Computer Literacy in San Jose and Cody’s in Berkeley so long ago. I need some more folks like that in my life now. I hate being right so much these days. I know it is an illusion!
A lot of good ideas here that may be applied wider, not necessarily to "agile". For example, the priesthood and ritual metaphor is not necessarily applied to "agile". It applies to a vast number of organizations where somebody that decides on processes, usually middle and upper management, think that applying the recipes they learned in school or on previous experiences will magically produce good outcomes. They heavily rely on an invisible hand that assures the outcomes. When that doesn't happen they will look for "technical causes", because another huge bias they have is the conceptual separation between "business" and "technical": business is always right, while the "technicians" are minions without rights or power that only need to cater for the uninteresting details.
Sounds like Mr. Holub has landed in some places where the communication between engineering and "management" was dysfunctional. It does not mean Scrum is broken. He correctly points out that our stakeholders want reasonable estimates. We want those too, how else can we prioritize effectively. We don't need something perfect, but good enough to make decent tradeoffs. When this is not possible we should explicitly call it out, and consider adding a prep story to investigate the big unknowns.
The reason scrum has in so many instance backslid into anti-scrum behavior is because American business management in general is dysfunctional. There is the widespread idea that if you're not holding a threat over a subordinate's head, you're not managing him properly. My current employer uses scrum, but if the number of story points I've completed is ever a "topic of concern" at a performance review, I'll be looking for another job.
@ContinuousDelivery Hello Dave. This is one of your very best interviews because you let Allen do almost all the talking and didn't interrupt him, even when you didn't quite agree with him. Btw/ I am only watching this 2 years after it was posted because of the (effectively anti-)clickbait title. I wrote off Allen as someone who had nothing useful to say based on the title. Recently I saw a video where Allen was co-presenting with Uncle Bob. That immediately legitimized him in my eyes and after watching it I came looking for this video.
I feel like the perfect scenario for developers would be something like scrumban. All of this can be done virtually as well so we don’t need the cameras on, person to person contact. While I agree sometimes this can be useful it’s not necessary. The problem with scrum is I think people are doing. It really wrong. There shouldn’t be that many meetings. One planning meeting, a daily 15 min meeting which is so short it shouldn’t affect anyone, a mid week check in meeting, a demo and then a retrospective. I don’t see how that’s a lot of meetings tbh.
One of the reasons that software engineers don't improve their processes is they have to spend too much time supporting inefficient processes. This also means they don't have the luxury of time to sit through chats like this. Dave's 20 minute slots are already too long for many and simply not concise enough. The densist source of information on YT are the Goto conference recordings.
You know whether someone is truly agile if you put them in a situation where they lack flexibility and motivation. And they are not comfortable. Where everything is task-driven and slow. Among people, incl Developers, who cannot conceive of agility. Who just say that “this is just how things are”. There is no motivation to change.
Is there any new term for teams that do proper agile? Something I can search for when looking for the next job? Whenever I see the word 'Agile' on a job advert it always makes me groan because I know chances are its just some buzz word HR slapped on. If see Scrum, or worse LEAN, mentioned I suddenly lose interest. My first coding role was in a company that had a seriously badly implemented attempt at scrum and since then I've actively avoided reliving Office Space in real life.
I always had that feeling, that scrum is so overly present in most teams, not because it's a good software development practice and not even because of agile; but because it's a good tool to police and mandate work regulations. Want your employees to be on time everyday? Set a daily at 9:00am. Want to check if you workers really work or watch youtube? Have them confess their "update" each day. And if they don't, you can blame them for not being agile. If they argue, you cant tell them they don't understand agile well enough. Scrum is a perfect candidate for survailance over your teammates. Of course that wasn't the original idea - granted, the original idea was about agile - but is it used by managers, to advocate agile while the real interest in more control over your employees - I think yes.
I just hobby code but it seems to me that software theory of workflow is just like in philosophy where it is said everybody ends up essentially quoting and rephrasing Socrates. In this case, Socrates is Fred Brooks. (Wikipedia): The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping
Loved this episode, my personal best so far! Both Allen and Dave are my fav'tests 😊 and I learn a lot from them! Thanks to both for this wonderful insightful discussion.
We are living in a time in the software industry that historians will eventually refer to as the “Agile Scrum Inquisition.” Seriously, I see things going on that make me think of the Spanish Inquisition with the way this nonsense is forced on everyone these days.
Amazing video. TL; DR; Agile = Amazing, yet almost always misunderstood Scrum = a cute idea turned into a monster Corporate bloatware labeled as agile != agile People > metrics Agility > ceremony
Have a lot of opinions on this chat, but this cracked me up. "You can't put a measure on value." 😆😂 Revenue, revenue is the measure of value 😂 Can you fulfill delivery to a paying customer, ideally utilizing effective process, and best practices? If you can do it with minimal to no tech debt you've done even better. The need for metrics and estimates relate to a functioning business maintaining the ability to make sales and meet customer contracting language. Question: When you have to establish contracting language with a customer who has expectations, desires, needs, go to market strategies, etc (in other words, all of them), how do you negotiate delivery without estimation and discussion of the full scope/desires of the project?
You cannot get better at Estimation.. so true, we have no knowledge of the unknown. When you get more feedback.. are you adjusting the estimate and charging more for the time and extra work?
Man, I have been saying the same about opinions for a few years. Opinions can certainly be wrong... and opinions without any reason are certainly wrong.
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).
^ this. In spades!
"high throughput waterfall" - Love this.
I can agree here. And that’s an issue, wanting something, doesn’t mean it is actually useful.
This is exactly the situation in my company. Everything is fixed from the beginning (requirements / list of features, budget -> resources, deadlines for each feature), then they say "now be agile". The main problem is whatever they fixed (requirements, resources, deadlines) were not based on any real design process (since BDUF is not "agile"), so they were just pure "essentially random" estimates! What a horror!
This!
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
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.
Yes, that sounds about right, simple isn't it? 😁🤣
Thank you for the summary!
Ty for the bullet points
That’s an amazing text summary. I tend to use timestamps and small notes. But UA-cam comments doesn’t like edits. You probably wrote that elsewhere first
@@RenoirB he did say he took some notes right at the top of his comment.
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 think an open room with a whiteboard is probably the biggest key here. I like working remotely, but Slack and Jira tickets are just a stupid waste of time. I think for remote work to be efficient you need constant conversation and a flow of ideas. And I never see that. I see business sending reminders to merge of X date, and devs that don't want to be bothered because they're doing their little ticket and find all the chat noise to be a distraction.
I worked in a similar environment, and it was mostly a good thing, but it was still everyone doing their own thing, and that eventually drove me crazy enough to leave. Now I just want to do my little tickets, clock out, and work on a real project on my own.
I wish one day decision makers will understand this basic construct. Organizations have no idea how much waste they accept by following outdated practices. Those who understood it, emerged as market leaders and rest still focusing on local optimization.
With perfect hiring, all things are simple :)
@@centerfield6339 what's perfect hiring? A mix of people that are fast learners and people that can teach by doing. Usually there's a lot of luck involved.
@@AndreiDinTheHouse ...okay?
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.
Wow such a testimony. IMO, the real lesson here is if they have to 'secretely' come to you rather than openly Talking about it, then Agile doesn't work either. Is not a framework open to change, not what they promised it to be, not a place for open conversations
My question is what is the scrum master doing and why are the devs not being corageous?
@@Aksamsons lol are you seriously asking? Agile/Scrum is not about developers being courageous. Is to bow their heads down and "crunch" more and more and more. Don't be fooled by this "democratic flexible conversations" because they are not democratic nor flexible.
It resonates with me! Thanks to idiotic system that see knowledge engineering work as an assembly line, I close ticket after ticket, don’t give a damn about anything else. Side personal project, and the one I can monetise, brings me joy, grow and satisfaction.
7:49 ❤ ❤ ❤
"agile has become a priesthood where the priests don't understand the rituals they're telling people to follow"
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 :)
"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!!!!
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.
100% agree! ❤ I still have like 15 years till my retirement. I have enough of being treated as a kid from a crèche that need to justify every single hour of each day…
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.
I agree 100%. The worst type of scrum is when people follow the rituals without understanding why. The basically do cargo cult scrum.
I think they have realised some of their mistakes, like they have renamed "ceremonies" to "events". But it almost looks like too late for Scrum to improve their situation. I had high hopes in Scrum, but some of the elements they have, like their explanation of the planning, are plain devastating.
"Team works out what can be done in sprint". What a misconception. Team shouldn't think what can be done in sprint. They should take a problem and come up with a solution to this problem as a result of the sprint. How deep the problem can be solved - this depends on the maturity of the team, their process and the technical foundation of the product.
Fully agree, it is the reason for so many software applications going nowhere and ending up going to the dustbin.
Beautiful ceremonies but nothing beyond charts and some useless visibility charts. Agility is completely different from using Agile/Scrum methodology.
It is incredible how management needs to be convinced on things that are better for the organisation. Thanks Dave and Allen .. much love and respect
This usually happens when the management is non-technical people. If your manager was a software engineer for 10 or 15 years before he became a manager, you will not lose time with such silly explanations.
@@ForgottenKnight1 Some people convert.. in an effort to push careers. A lot of engineers also have a completely wrong understanding of agile.. when they become managers.. it’s more of the same too 🤨
As a scrum master, a lot of what was discussed resonates with me and how I run my teams. I ditched a lot of prescriptions and added my own.
Some of the points felt like a stab to the chest but they are true statements. Scrum has almost become a cult.
I also learned a great deal of new information and I'm barely half way in.
Please have more discussions like this- our community needs more healthy disagreement
There is no almost.
"Your" teams?
TL;DR: Scrum is bad, kanban is bad, metrics are bad, lean is bad, data driven is bad, estimates are bad and agile in general is broken. What is good?! 🤷 The only advice in the end - learn what makes you happy and try to find the right company (which is usually impossible to tell even few weeks in, let alone during the interviews).
As much as I enjoyed "two grumpy old men" complaining about basically everything, there is unfortunately not much info value in this one IMHO. Anyway good to hear you discussing interesting stuff as always Dave! 🙂
What I took from the "everything is bad" tone is that practices are being adopted with little to no thought to the fundamentals of agility. Most organizations are introducing agility by process piling and not stripping away the root causes that are hampering adoption. In the end, find the culture that fits how you want to work and they did give some good insight into the hiring processes that would be good leading indicators to that point.
I had the same impression.
whether metrics are good or bad depends on how you use them, what you make of them. Basically that's what was said.
I also picked up a nugget that teams need to be free to pick their own process. If you dictate a process (Agile or Scrum from a book), you aren't letting them be agile, and they will resist it.
Another nugget is that teams should have internal metrics to see how they're doing but those shouldn't bubble up to management to be held against the team.
I thought his statement was interesting that he would get rid of sprints. I think it's arbitrary to time-box a task that will surely reach completion at a moment that isn't perfectly aligned with any multiple of the time box. You might reach the end of a sprint without the mini-feature done, but then on day 1 of the next sprint, it gets finished.
Trying to guess what to fit into a sprint is a form of overhead. Better *maybe* to just break tasks into bits that seem small and pick one and work it to either completion or temporary abandonment. If a task turns out to be a sinkhole, you can say you'll stop for now and revisit it in the future.
@@dubiouslycrisp I see this a lot. Leadership says we are "doing agile! Here's your process! Go forth, improve output, and update the weekly status report PowerPoint so I know your doing it!". Most teams will then pile the nomenclature and framework events on top of the existing process and slowly die under the weight of it all. Good call out.
I have found that most underperformers are simply demotivated employees. Give them a good job that they enjoy and you rarely have people who underperform.
I do agree with most all of what you both say though.
Amen to that!
I've been in software development for over 20 years. I've never seen different organizations or different teams in the same organization practice "Agile" the same way. There is ALWAYS some influence based on management, corporate culture, internal team dynamic etc. I been been on projects where Agile has worked very well, and others where it's been a nightmare.
Here's what makes Agile work when it does work:
1. A good scrum master that actually knows how to facilitate meetings, to elicit honest responses from team members, and is a strong advocate for the team when communicating with management .
2. Managers that know how to butt out of the development process.
3. Team members that are honest with each other, communicate well with each other and are willing to help each other out.
4. Not only have retrospectives but to take actions that come out of those meetings that actually improve teamwork or development processes.
5. Team members willing to admit "I don't know what I don't know". This is especially true at the beginning of projects.
6. Sprint grooming and planning that flushes out as much detail as about stores so that acceptance criteria, and definition of done are actually accurate or as close to accurate as possible.
Corporations have drunk the Agile Kool-Aid and they are loathe to admit it doesn't work, that would mean they have to come up with something else. Management isn't going to take the risk on the unknown. The best most of us can do within those confines is make "Agile" work the best we can.
Railing against Agile is fine.
Coming up with something better is much more important, but also more difficult given that Agile is so entrenched in so many corporate I.T. projects.
Do you tell an artist how to paint, sculpture or compose? How do you determine if something is better and how do you meassure it? Real honesty that hurts was a problem i encountered. Most ppl in my company used Windows with a Linux VM to develop for a yocto nav system. They didnt even recognise how dumb and inefficient that was. It simply was watching the titanic sink. I was looked down at because i simply used Linux directly as dev OS and had to explain myself why i didnt had Windows + company firewalls and AntiVir al the time running + with a fixed collection of progs for the Windows users. It was so below any intelligence that it was scary. Should i have told the win admins that they are completly useless if i dont use win at all and point out how expensive there meaningless existence for the company is and get all the nice expected feedback of them. I just watch the titanic sink while looking out for a better job. And afterwards i am not able to talk about this in my applications for other jobs until i get the job and then most likely the spiral starts from beg. How can i be honest if honestly your job is a waste? Why am i forced to point you out as the actual problem from a human point of view while we all depend on an income and have to take part in the daily darwinian survival that is called capitalism.
I have to agree with Carl. Look at all the points he listed. Fact is, Agile can work, with great teams. Where Agile fails to work, is when leadership (management) doesn't own or understand Agile process. Let the team figure out the best form of Agile for themselves. This is true Continous Improvement.
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.
Very, very true statements, and deep understanding in your comment, hereby plusoned
I second that. In Kanban, columns are also an indicator of the effort already put into the task/story. And the tasks on the right side have more priority than the others, as we focus on delivering the stories closer to the "done" stage. So, moving the task back to the previous step on the kanban board clears down the knowledge about the effort invested here and automatically deprioritizes the ticket.
Wonderful conversation. Finding myself nodding along to all of this and feeling like some sanity is being restored! Ahhh!
I did hire a philosophy major once and she was the best developer on the team hands down.
In the early '70s many programmers were former English teachers who wanted a career change. Also 'computers', which was the term for people who drew contour lines on maps. One I knew who worked at a government service bureau had a drafting table next to his desk - he still had to do his old job too, while waiting for full automation of the task.
Two of the rare consultants speaking their mind about what is going wrong in the software industry… It was meant to be a great conversation… and with a lot of agility :) they meet my expectations.
In my opinion, Allen describe everything in 3 words, we need intelligence!! Seems to me that their is no more critical thinking, everyone is looking for the magic recipe… and it will probably get worst with the current talent shortage. And it explains their disagreement on metrics I think. If the metrics is the results of smart decisions, that took into account the particular context of the company, we should expect on average better outcomes. If companies start focusing on those metrics and search for magic recipe to reach them, we may start seing companies with good metrics and bad outcomes. Body weight is normally a good indicator of fitness, but it is the result of fitness oriented behaviours. Focus on weight and suddenly it can become a psychological problem. Human being human, and even so management being management, don’t give them more metrics to monitor :)
From my limited experience working in an agile manner, both with Scrum ceremony and without, it seems that all the ceremony is to justify billing. When developing software for our own company and not for a client, we are just trying to create valuable features, deliver them incrementally and gather feedback in a natural, common-sense way. I always believed that we were to small to do Scrum but somehow our approach seemed better. This interview was eye-opening.
Allen Holub is my spirit animal.
I worked on something recently and we thought it would take about 5 days to get it done. It ended up taking about two months. Fixing one problem uncovered a lot of other issues related to complicated math in the simulation that took quite a while to track down and fix. There was no way to see that problem ahead of time because nobody had any idea the problem was there.
At some point it seemed the Agile process we were taught just started to break down for this. The code ran, the tests passed, but the tests also ended up being wrong for some of the same complicated math reasons. For scientific and simulation software at some point I have found you just need a few people that work together on an issue and get rid of all the worrying about sprints, tickets, scrum, predictions on when it will be done etc. stuff.
There was no point in adding more people to the team to speed things up because there was really not much they could do to help. It was better to have them work on other projects. Especially when a combination of programming and graduate level math skills where needed.
This isn't just true of scientific software but all software. You needed to be agile but there was too much "Agile" getting in the way.
I think this speaks to the fact that "stories" appear to be oriented around the idea of creating a webpage or video game with a bunch of little pieces and buttons, rather than acknowledging that you can have one end "feature" which is very complicated.
I like the conversation. On the 'soft skills' side, people bring a lot of their personal beliefs to work. If they believe the same things you do about how to work, then it's pretty straightforward. Give them the information they need to be successful, and they're off. But if they don't believe or what you're suggesting isn't something they're familiar with, telling them won't necessarily get them on board. To me, that's where the soft skills come in. You have to find ways to help them get to the same place you are in terms of why this way of work will be successful. While I fall mostly on Allen's side of the fence when it comes to life coaches, there are a lot of personal conflicts where some of those skillsets can help a team move through conflict and be more successful.
I do think that a lot of the problem here is that there is a fundamental lack of understanding both by senior management and by development teams.
The simple fact is that if you’re working in an organisation whose business model is to find a customer, build them something for a fixed price and then take 30% margin then you’re going to end up with a middle layer of management searching for ways to get more value. When you’re stuck in the ‘iron triangle’ of cost, time and features, all you have to work with is process and team. In that scenario, of course people are going to be looking for new ideas, even if it does mean taking out a massive hammer in a doomed attempt to bash a square peg into a round hole!
My problem with the current discourse though, is that what seems to get set up in these discussions is a massive rift between development teams and ‘management’ which is toxic and unproductive.
There’s always this demand for ‘management’ to educate themselves on development processes but where are the engineering teams who are educating themselves on how their businesses actually work? Who is asking their finance directors questions that help them understand what they would need from engineering in order to adopt these ideas? Who is talking to project managers to find out how to better contract with customers so that modern development methodologies actually become an option? Who is working with sales to help them make pitches to customers that encourage them to want to work in this way?
An engineering director I used to work for once said to me, “It’s much better to be inside the tent p*ssing out than outside the tent p*ssing in!”. If you want to be working for a modern, high performing, exciting team, you might be asking the business to completely tear up a business model that is profitable and feels pretty secure to your senior managers. So be prepared, ask questions with an open mind, and engage constructively.
I agree. This isn't about evil bosses, this is about finding better ways to work for everyone, and we have. There are lots of orgs where dev teams educate themselves know how the business works, at least in the context of their SW. The sensible, senior techies probably more than that.
This kind of collaboration and understanding is one part of what really makes agile work and is essential to really high-performance. It is difficult because it challenges nearly everyone's thinking about how stuff works best.
I want to acknowledge the reference to the business model. This is neglected in 99% of the times when software development practices are discussed.
If you have a start-up and you run a single product development, that's one thing. You have to be agile, feedback driven and stuff.
On the other hand, as you mentioned, if you are a company that runs software development projects for others you are stuck with waterfall within the iron triangle. Very seldom you will have time and materials contract, a fix budget, fixed schedule, fixed spec is the most likely option. The idea of delivering a product following the "it's ready when it's ready" principal is also not an option.
The sales stupidly sells "agile" to the clients which perceive it like "no planning or design is needed" or "changes are free of charge". And you also have intrinsic uncertainty of software development and that 30% margin you want to make.
Development process management of such projects also sucks. Sucks like using burn down charts as a measure of progress reported to the client or running meaningless Scrum routines just for sake of it.
In my opinion what software industry needs is waterfall adapted to the software industry reality. Most properly sized projects don't usually run into such massive uncertainty that can't be compensated by a reasonable contingency plan.
@@oleksei3371 It goes further than just the business model too. The sector I work in is primarily driven through tendering which forces all suppliers to work this way. It’s a shame, I think the CD way could work. I’d love to see a tender that is looking for a long term development partner who can work through a programme of delivering new or upgraded capability to the customer rather than a set of (usually totally crap) requirements. They would get so much more value from that IMO. We’ve still got a long journey ahead.
@@Microman6502 Business to Government? Yes, I worked in that too. And I have also questioned this a lot. There are two things that prevent this from changing: anti-corruption laws and qualification of the client.
The specs are written upfront, then RFP is issued and proposals are collected and the lowest bidder gets the contract. This way everyone is 'clean'. If the government prefers your company over mine based on other criteria that are not so obvious, I may sue the government. In the current situation it's just the question of mathematical operation to choose the winner.
There are actually exceptions, but this is usually the case when there is a preexisting product that government wishes to buy and tune to own needs. As such many governments use Microsoft products and cloud (at least what I've seen).
Finally... Well, government officials make terrible product owners. They are seldom motivated or incentivised, they love to 'share and push responsibility', and you have to wait ages for any decisions.
Basically, if you want to have some success in this realm - build the MVP first, and try to establish (sell) expectations (the spec) more or less equal the properties of your product, then be the only applicant for the tender 😁
I've worked as an IT consultant for the past 20 years. Seen alot of bad stuff, and while I do agree that there's a fair share of engineering teams that don't want to educate themselves on how their business actually work, it seem to stem from a place where they've tried that but have been met with a wall of uncooperativeness on the non-engineering side. Uninterested engineers, in my experience, correlates highly with incompetent management and lazy staff. The number of times I've tried to facilitate between the two only to be met by either silence, non-cooperativeness, or flat out refusal to do the proper work on the management side, is staggering. The number of "business people" who don't even know how to construct a proper business case is through the roof. The number of "business people" who can't formulate even one high level acceptance test beyond "it should work" is absolutely massive. And I think i know why: asKing non-engineers these questions often imply the non-engineers have to actually perform work. You know, actually do things. Tangible things. Correct things. Things that are in their job description. And output results that are at least somewhat certain, to the point where an engineer can act upon it. And in my experience, there's alot of people in alot of positions whose sole purpose is to do nothing and lift a salary each month. The moment they are forced to think, they want out.
I like this guy's attitude.
Can't wait for the Book... In my 1st week at the 1st meeting in work I aligned with Dev. Teams and exactly told them let's learn together how to say No, and focus on fixing things need fixing here and now as a start!
My core objective is keep devs independent, protected and engaged on there own just to make their life easier and love work, everyday we try to make things simplify how we work get things done clearly and we all involved getting our hands dirty building, fixing as we enjoy our work
Wow! Too many things to chime in on. Great talk! Count me in as a grumpy old gal who also agrees with everything. I was an English major lucky enough to start programming in the 70's when an interview consisted of the IBM programmer aptitude test. Then you had to pass all the exams during the first three months of working through the IBM self-taught assembler course. I remember asking a colleague during training about this language called assembler. I had heard of COBOL and Fortran but not assembler. Will it be useful to learn? Don't worry about that, he replied. It will definitely be useful.
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.
Thank you for this! It was a delight to watch two of my favourite Software Engineering Educators collab on such an interesting topic!
Glad you enjoyed it!
I should also mention that my way-of-working has always been what has become known as agile. It is because my approach to writing software is the same as any writing assignment: Do research: analyze the audience, topic, and context to come up with an approach. Then revise until done. Writing is revision. Going back to research as needed- this is a recursive process.
I really like the following definition of agile - "quick and well-coordinated in movement."
I am a solo-hiker and there is hardly anything that is more agile than hiking. Move fast, but watch your steps, regularly make a break to check the map and adjust your route basing on the landscape. Still, make sure to stay hydrated, pick proper places to pitch a tent, sleep well, and keep feet dry whenever possible. The next hike, review your tools to be more effective based on what you learned.
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 work in one of these big places that had company-wide agile overhaul, with accenture consultants coming in to indoctrinate us in their brand of agile, which largely means a domatic approach to scrum. The whole thing has been aweful, treating experienced developers like they're little kids that all need to use the same little system of organisation where every little action has to be documented with its value and estimation constantly negotiated over with people who can't necessarily develop getting injected into the scrum master role as a quasi-manager. We were told at the start that the scrum points system wouldn't be used as any kind of performance metric. Afterall, points between people/groups can be a bit apples/oranges. Cut to a year or so later all that's been forgotten, performance review directly focuses points of work delivered. It seems like a strange thing to say but I always felt there was an aspect of creativity in this job. You're given an objective and you use your knowledge to break that down and come up with a solution. Now every thought is intruded upon and vetted. Absolutely horrific. Handed my notice in last week :)
I am sorry to hear your story, it is all too common in my experience. I agree with you that good SW dev is a highly creative process. The people that try and squeeze the creativity out simply don't understand what SW dev is. I wish you luck with whatever comes next.
I don't know if this will help, but just in case it does, I made a video on how to detect signs of competence in prospective employers: ua-cam.com/video/2Afk9KVEgpE/v-deo.html
@@ContinuousDelivery Oh not to worry, I have another job lined up to go to. Part of the interview included some talk (initiated by me) around their agile/organisational processes and they sound lot more reasonable. Let's see how it goes!
You should consider uploading these to Spotify :)
Strongly agree with everything you said about how companies are following agile! I thought I was going crazy. Good to know imagine not the only one
A lot of hard-earned wisdom in this conversation. I do have one bone to pick: I implore the participants to re-evaluate kanban and lean manufacturing. "Rework" and/or "going back" is not prohibited or even mentioned in the eight Muda of Toyota's Philosophy, and Kanban can absolutely be effective in software engineering. In fact, I've personally seen it be highly effective within teams at AWS and Google.
I don't think that I have ever enjoyed a conversation, let alone a conversation that I was not a part off, as much last this one. At least not for a long time. I am sure that I will be rewatching this. Perhaps multiple times.
Glad you enjoyed it!
In my company we sort of reinvented XP 😆 We threw away all the "garbage" from Scrum and only kept what we thought was really useful to us and .... bingo, without actually planning for it, our development process is textbook XP. This tells you that XP is really all you need.
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.
This video is such a breath of fresh air! Thank you for recording this conversation.
Allen makes a point that I have always thought: “money driving the process”. Business gets in the way of advancement because they cannot trust their experts to work on their practices. A difficult struggle indeed.
Probably third time I'm watching this episode. Everytime I find something valuable. And when I try to find the 'WHY' with my very limited experience, I recognize some patterns. 17 engineers/architects/scientists devised something 21 years back. We are expecting mostly non-technical people will understand the thought processes and align with that. Very high expectation.
Technical people are people of logic and data. "Yes, it sounds logical, but..." or "Yes, the data shows that we need to do this, but..." - do these phrases of non-technical management sound familiar? :)
I fully agree with your view on math skills in programming. Besides some very specific fields, like writing physics engines, or graphics, you really don't need much.
I still thing algorithms are good to learn, but not as deeply as is often taught in CS. At least at my uni, Big O for example did not get enough time, but hey, at least we learned to perform a ZIP compression on bits with paper and pencil...
For "pure" math, I'd say linear algebra, some formal logic, and stats is plenty enough. Stats in fact is pretty underrated in my experience, especially for higher level reasoning about architecture, it can be really important, and not many people have even the baseline neccessary knowledge.
Thanks Dave and Allen, this conversation has been great. Really thanks for sharing.
Glad you enjoyed it
14:35: “Do the most important stuff first so you know you won’t fail”. That described my experience with waterfall, and then I stepped into Agile for the first time and was blindsided. It was truly awful. Could not get work done at work, but was busy as hell. Then had to do the real work at home
When I dev I work for only a few hours a week. An hour a day or so + meetings. I give excuses as to why it's taking long. I'm very good at my job so I barely work at all. The only reason I'm there at all is because they refuse to pay me otherwise. You may call me lazy but I don't think that's it. To do more than I'm doing would mean doing more than everyone else. They would look bad when compared to me. They are after all doing the same thing. They are dragging their feet hoping the project will last until the end of time. To finish the work would mean to get fired. They don't have any incentive at all to do a good job. Even if bonuses or promotions are designed to spur on the work, the truth is that there's no benefit at all to doing a good job. No one cares what improvements you have in your head. I've personally been told my ideas would fix the problem and even when I offered to do it in my spare time on my own dime I was told no. People don't want to solve anything at all. They just want to continue with what they're used to because they're afraid it'll get worse with every change. And it usually does get worse with every change. So they aren't wrong. Let's be clear. The system we have built with employers and managers and owners and leaders and rules us broken because of the things the system is made of. The rules are the problem. Employers are the problem. There's no cooperation here at all. Employers own employees. Employees are the ones doing everything but are not allowed to use their mind at all. If they did, what would we need employers for? What does a boss do? Managers are not managing anything. They sit around and pretend to care about reports. It's 100% pretend. Employers aren't any smarter than employees. Slaves don't have lower intelligence than slave drivers. We live in a world of lies and the liar is us. We are the ones doing it to ourselves and we do it by choice. We know we're doing it and we do it anyway. We know climate change, pollution, war, famine and every crime people commit against their own family are the things we do. We're doing them. Not someone else. Still we keep doing it.
Being agile will ALWAYS work. Doing the things companies are doing because they are told it will make them agile almost never work.
😪 I love you guys. ❤ I am a philosophy major programmer and you just understand the world of development like no other I have met.
One caveat: big companies exist for a reason. Their culture protects them and probably agility is not for them. David doesn't always win, especially if Goliath is in an environment that suits him.
Let's keep challenging Goliath with our Agile approach but don't fall for the misconception that what Goliath is doing is bad just because you don't like it.
I love this! The views on hiring are so thought provoking.
Hi Juan! They are so true. But know what: problem is that almost none in industry, especially on recruiting, has abilities to estimate needed skills, measure if position and applicant match and credibility to voice it so that it could steer decisions. But basically: if you know how to build highly scalable resiliant distributed system by heart you also instantly know if you have met person that can help you and what kind of role this person can successfully take as part of development team.
This dude is delivering a master class in moving goal posts in order to not concede a point. (Enjoyable talk otherwise, lots of interesting things said overall.)
This is exactly how he's recommending we approach software as well. Just keep moving those goal posts.
In reality, goalposts are perpetually in motion.
These are the exact thoughts (Well, most of them) I had when I read the agile manifesto + Principles and how people are working in the so-called "Agile Environment" ... it is frustrating... Thanks for this great conversation
This is great. Just discovered Allen Holub and love his take on this topic.
I don’t agree with a little more than half of this but I still very much appreciated the content. Thank you for uploading.
That's fine by me! My hope for this channel is a sharing of ideas, so that people can shape opinions and learn. So disagreement and debate is all part of that. So thank you for not agreeing with everything 😂
I can't believe how convoluted such a simple concept has become. The problem is getting people out of the quagmire
#noestimates
My approach is to follow the processes and have all the evidence when I inevitably get it wrong. No overtime no stressing, no fuss. I can't fight the process but I'll have to slowly over time show why it's broken. When you understand what should be done you can challenge what is being done
Great discussion with 2 wise old men!
However, I would like to add, that scrum, like all other tools is only appropriate for a specific sort of teams and problems. Before you use it, learn about the nature of your problem and select the appropriate tool to fix it.
I really enjoyed that - the best interview I've seen all year. It didn't hurt that everything Allen said resonated strongly with me…
Great content and enjoyable conversation! I enjoyed the new camera border and animations as well!
Awesome, thank you!
What a nice discussion! Exchange of ideas through experience. Discussion on metrics - this bothers me a lot. IMHO, we need to establish process is such way that if needed we would to have capability to invetigate metrics - it is like adding logging to production code. You don't need if everything is fine. The more you have the better, if it does not affect performance, time required for implementation or costs significantly.
If do not look at productivity, then people will use outdated tools and tech, always trying to reinvent the wheel. Productivity comes from defined coding practices of a team, not from output or outcome metrics. I think productivity influenced by discussions and code reviews, from "ideas in the kitchen", sharing.
Thanks for video. Was interesting.
Interesting conversation about metrics. Just because you can compute a metric doesn't mean you can compute/"backpropagate" it's gradient. This is why we have to stochastic optimization techniques. Seems silly to discount metrics due to incompetent "management".
When a metric becomes a target it ceases to be a good metric. Do you agree?
There is a well-known phenomenon called "surrogation". Psychologists have been writing about it for years.
@@Tymon0000 My goal is to eradicate polio. The metric I use to measure this is the number of polio cases. I attempt to get this metric as low as possible. If it goes up, I'm doing something wrong. If it goes down, I'm doing something right. If the number of cases is zero, I consider my job done.
Does "the number of polio cases" become a bad metric when used as a target for the goal of polio eradication?
@@jimmyhirr5773 I would argue yes, because we know that metrics can be flawed, you might not capture all of the cases and so miss some, a metric of 0 does not mean you've achieved your goal.
Great discussion! Compiler Design in C was immeasurably helpful to me at my first job. They designed screens using some PC software (forget which) and asked if we could "convert" the files to AS-400 screens. I wrote the parser and another guy wrote the back end and we had the first screens running on the 2nd day. A big career boost my first week and not long after I was working on OS/2 in Boca Raton. Not Agile related, but many thanks Allen!
I just looked in my library and noticed that I still have Allen's book "Compiler Design in C"!
Charming old chaps. Some wisdom. Some noise. Highly enjoyable. Thank you. I could have listed here some very insightful quotes, but you better pick up ones fitting for yourself. 💯
Scrum's intention is to teach the team discipline, teamwork and effective processes to help them achieve their goals. Once the team matures to a point where Scrum is no longer necessary, then the team can move to the less rigid Kanban framework.
I agree with you, before changing the process, you need to master it. Rituals are there to bring the change. Everyone is against estimates, but we need projections . So I see implementing agile is first working with business management . That is good to force business to identify what brings 80% value from 20% development. Then continues deployment - I rather say deployment on demand . Not continually…
bold discussion. key takeaway is flexible not stuck with some term and same process ....
Dave-thanks for this. So many truth bombs in one convo. Happy to hear more (but first I need to listen to this 5 more times). Thanks for giving me a transcript too!
Been working with Agile for years now I am very very confused. I think it's a form of institutionalisation maybe. It's kind of a comfort blanket for me as a developer (and team lead).
I think that you are describing the Scrum anti-pattern that Allen and I were discussing. There is nothing whatsoever that is "institutional" in the agile principles outlined in the agile manifesto, but many orgs have subverted these principles and agile for many orgs has turned into a new way to operate a kind of "command and control" strategy. If your read the agile manifesto, which defined "agile" as a concept in SW terms, there is nothing of "command and control" in it. agilemanifesto.org
This content is incredibly inspirational, not just informational.
I just want to thank you for this enjoyable video, I was just having a great time watching you two talking about this great stuff.
Our pleasure!
Thank you for this video 🙏 The webcam frames are cool, but very distracting, maybe just me
In my experience daily scrum meetings extremely helpful to boost team morale and get results. In real life a lot depends on leader and real leader blames himself in case of failure, not tools.
This was fun! So many topics. I wish I had taken Allen’s UCB Extension compiler class decades ago. I would probably have solved the C stack frame question by dropping into inline assembly - not portable, but it would have been easy.
I wish I could have a beer and get into an argument with you guys. I used to have good discussions at Computer Literacy in San Jose and Cody’s in Berkeley so long ago. I need some more folks like that in my life now. I hate being right so much these days. I know it is an illusion!
Great conversation, thanks a lot for the unfiltered opinions & facts !
This is immensely helpful! Thank you!!
A lot of good ideas here that may be applied wider, not necessarily to "agile".
For example, the priesthood and ritual metaphor is not necessarily applied to "agile". It applies to a vast number of organizations where somebody that decides on processes, usually middle and upper management, think that applying the recipes they learned in school or on previous experiences will magically produce good outcomes. They heavily rely on an invisible hand that assures the outcomes. When that doesn't happen they will look for "technical causes", because another huge bias they have is the conceptual separation between "business" and "technical": business is always right, while the "technicians" are minions without rights or power that only need to cater for the uninteresting details.
Thank you, both. It's a joy to hear radical thinkers discuss where the rest of the world are victims of their own preconceptions.
Agile - doing half of scrum badly with JIRA.
This should be in the dictionary.
Sounds like Mr. Holub has landed in some places where the communication between engineering and "management" was dysfunctional. It does not mean Scrum is broken. He correctly points out that our stakeholders want reasonable estimates. We want those too, how else can we prioritize effectively. We don't need something perfect, but good enough to make decent tradeoffs. When this is not possible we should explicitly call it out, and consider adding a prep story to investigate the big unknowns.
The reason scrum has in so many instance backslid into anti-scrum behavior is because American business management in general is dysfunctional. There is the widespread idea that if you're not holding a threat over a subordinate's head, you're not managing him properly. My current employer uses scrum, but if the number of story points I've completed is ever a "topic of concern" at a performance review, I'll be looking for another job.
@ContinuousDelivery Hello Dave. This is one of your very best interviews because you let Allen do almost all the talking and didn't interrupt him, even when you didn't quite agree with him.
Btw/ I am only watching this 2 years after it was posted because of the (effectively anti-)clickbait title. I wrote off Allen as someone who had nothing useful to say based on the title. Recently I saw a video where Allen was co-presenting with Uncle Bob. That immediately legitimized him in my eyes and after watching it I came looking for this video.
I feel like the perfect scenario for developers would be something like scrumban. All of this can be done virtually as well so we don’t need the cameras on, person to person contact. While I agree sometimes this can be useful it’s not necessary.
The problem with scrum is I think people are doing. It really wrong. There shouldn’t be that many meetings. One planning meeting, a daily 15 min meeting which is so short it shouldn’t affect anyone, a mid week check in meeting, a demo and then a retrospective. I don’t see how that’s a lot of meetings tbh.
One of the reasons that software engineers don't improve their processes is they have to spend too much time supporting inefficient processes. This also means they don't have the luxury of time to sit through chats like this. Dave's 20 minute slots are already too long for many and simply not concise enough. The densist source of information on YT are the Goto conference recordings.
Really insightful conversation!
Great discussion.
You know whether someone is truly agile if you put them in a situation where they lack flexibility and motivation. And they are not comfortable. Where everything is task-driven and slow. Among people, incl Developers, who cannot conceive of agility. Who just say that “this is just how things are”. There is no motivation to change.
Oooh love this Dave, can you have Chris Matts, Luca Minudel, Dan Mezick on for future sessions?
If anyone could one-up Alan, it would be Chris :)
Is there any new term for teams that do proper agile? Something I can search for when looking for the next job?
Whenever I see the word 'Agile' on a job advert it always makes me groan because I know chances are its just some buzz word HR slapped on.
If see Scrum, or worse LEAN, mentioned I suddenly lose interest. My first coding role was in a company that had a seriously badly implemented attempt at scrum and since then I've actively avoided reliving Office Space in real life.
Very good insights, grateful to both of you!
I always had that feeling, that scrum is so overly present in most teams, not because it's a good software development practice and not even because of agile; but because it's a good tool to police and mandate work regulations. Want your employees to be on time everyday? Set a daily at 9:00am. Want to check if you workers really work or watch youtube? Have them confess their "update" each day. And if they don't, you can blame them for not being agile. If they argue, you cant tell them they don't understand agile well enough. Scrum is a perfect candidate for survailance over your teammates. Of course that wasn't the original idea - granted, the original idea was about agile - but is it used by managers, to advocate agile while the real interest in more control over your employees - I think yes.
Sadly yes, I have certainly seen it used that way.
I just hobby code but it seems to me that software theory of workflow is just like in philosophy where it is said everybody ends up essentially quoting and rephrasing Socrates. In this case, Socrates is Fred Brooks. (Wikipedia): The Mythical Man-Month: Essays on Software Engineering is a book on software engineering and project management by Fred Brooks first published in 1975, with subsequent editions in 1982 and 1995. Its central theme is that adding manpower to a software project that is behind schedule delays it even longer. This idea is known as Brooks's law, and is presented along with the second-system effect and advocacy of prototyping
Loved this episode, my personal best so far! Both Allen and Dave are my fav'tests 😊 and I learn a lot from them! Thanks to both for this wonderful insightful discussion.
We are living in a time in the software industry that historians will eventually refer to as the “Agile Scrum Inquisition.” Seriously, I see things going on that make me think of the Spanish Inquisition with the way this nonsense is forced on everyone these days.
"Nobody expects the Spanish Inquisition"
Amazing video.
TL; DR;
Agile = Amazing, yet almost always misunderstood
Scrum = a cute idea turned into a monster
Corporate bloatware labeled as agile != agile
People > metrics
Agility > ceremony
Have a lot of opinions on this chat, but this cracked me up.
"You can't put a measure on value." 😆😂
Revenue, revenue is the measure of value 😂 Can you fulfill delivery to a paying customer, ideally utilizing effective process, and best practices? If you can do it with minimal to no tech debt you've done even better.
The need for metrics and estimates relate to a functioning business maintaining the ability to make sales and meet customer contracting language.
Question:
When you have to establish contracting language with a customer who has expectations, desires, needs, go to market strategies, etc (in other words, all of them), how do you negotiate delivery without estimation and discussion of the full scope/desires of the project?
Can't wait for Allen's new book.
"factory" that is the problem, most managers are trained to run factories
Yes, trained to run not only factories, but also slave plantations.
If we got better at estimations as corporate managers desired then senior developers would need to change titles to senior Seer
You cannot get better at Estimation.. so true, we have no knowledge of the unknown. When you get more feedback.. are you adjusting the estimate and charging more for the time and extra work?
Man, I have been saying the same about opinions for a few years. Opinions can certainly be wrong... and opinions without any reason are certainly wrong.
Excellent talk. Thank you for sharing.