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 RUclips comments doesn’t like edits. You probably wrote that elsewhere first
Having a job in a scrum team really shook my confidence as a developer. On the one hand I'd come from a different background and did have a lot to learn... but, it was meeting / process heavy and I felt a lack of freedom to approach problems in the way I knew how to get my head around what was going on. I agree with the problem with metrics for two reasons 1) If you are judged by the metrics you will chase the metrics, not what the metrics are supposed to measure 2) You will get stuck in local minima, optimising for the best short-term solution, and not for long-term growth - which requires keeping the technical debt down. I also generally hate the lack of ownership you have when everything is dished out in sprint tasks, there's no pride in having accomplished something, just temporary relief until the cycle starts again.
Very similar experience. After years of working hand in hand with the product owner where we grew a product from inception to a large multi client application we needed more resource. What we got was one additional developer and and army of management, endless meetings, having to explain everything, justify everything, significantly more stress and anxiety to the point where its debateable whether we are any better off than I was on my own. None of this has come from the product owner, its a corporate IT issue.
In general, Scrum doesn't prevent tech improvements and tech maintenance. For me, planning session kind of ruins the whole idea of Scrum. There should be no planning in the form suggested by Scrum. All developers need to do is improve the highest priority problem of the customer while leaving them enough time to maintain the technical solution and to improve it. The stupid concept of sprint velocity has kind of multiplied this problem - now instead of solving problems + making sure the tech is in a good shape, team are grinding through story points. What a ridiculous thing to focus on.
@@Diginegi if the developer doesn't have passion - they are not going to be a part of my team. It almost feels like a stupid idea to spend 8 hours a day doing something you're not passioned about.
@andyk2181 You're talking about misplaced pride in individual ownership and individual achievement. Rather than professional pride in being part of a team that shares ownership, trying to do their best work all the time. Kent Beck, for example, focuses not on writing Clean Code (code you can be proud of) so much as Refactoring the code to improve the structure for your next change. He feels that "Pride" smacks a little of a job well done, rather than focusing on a process of continuous change. This is rooted in Kent's focus on having (TDD) tests you can trust, to reduce your anxiety level when changing code.
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.
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.
"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!!!!
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 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 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.
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.
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…
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 🤨
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.
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.
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
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 :)
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
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.
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 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.
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.
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.
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 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.
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.
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!
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.
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.
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: ruclips.net/video/2Afk9KVEgpE/видео.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!
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 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.
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 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.
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 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.
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
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.
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 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.
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.)
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.
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
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.
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
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.
😪 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.
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.
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!
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.
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.
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 love Alan for his fight against estimates. But, his diatribe against metrics is cringeworthy. It goes against much of the important ideas from this channel. Perhaps if the organization is truly pathological, then there is no hope for metrics. But, when working with reasonable people (a precondition for all of Dave's ideas), the DORA metrics balance each other. If you decrease lead time to change and decrease change failure rate over a significant period of time, you're probably doing a better job.
I agree. I follow him on Twitter and I feel his understanding of Metrics and Lean are completely missing the point. And I feel he is unable to even consider posibility that his understanding is incorrect.
@@RFalhar You do know that I worked with Lean metrics for years, don't you? Here are a few useful quotes: "Tell me how you measure me, and I will tell you how I will behave." -Goldratt "It is wrong to suppose that if you can’t measure it, you can’t manage it - a costly myth.” (Deming [The New Economics])` “You can only measure three percent of what matters” (Deming, quoted by Peter Senge) “Managers who don’t know how to measure what they want settle for wanting what they can measure.” - Russell Ackoff Of the 97% of things that do matter, I find things like innovation, happiness, drive (to use Dan Pink's word), value, satisfaction, more important than assembly-line metrics. None are measurable.
@@AllenHolub Thanks for proving me right. Instead of inquiring on why I think what I think and keeping open mind, you have immediatelly bombarded me with "I'm right and you are wrong." assertions. Assertions for which you have provided zero evidence to back them up. Such assertions are nothing more than just your opinions. And to give you one more quote "Opinions are like assholes, everyone has one and they all stink." So until we can establish shared way of figuring out how world works, we won't be able to talk properly. And considering the most commonly accepted way of building shared understanding of our world, The Scientific Method, is heavily based around measurements, I cannot imagine you accepting this method.
Ironically, my most recent video on DORA metrics ruclips.net/video/hbeyCECbLhk/видео.html is 'performing' only slightly better than this video with Allen 😂
@@AllenHolub while I think i agree with you on metrics, I don't necessarily agree with how you put it. The problem is not in the metrics, it's in metric-based management. Every tool can be used or abused and it doesn't make it bad Btw, I think you may be able tomeasure value if you know what is the expected outcome of the product. Just there is no universal metric of value. And you can measure happiness and satisfaction - there are techniques for that (I'm not saying it's worth measuring though)
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. 💯
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.
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…
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.
@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.
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
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.
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.
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.
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
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.
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!
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.
As an individual startup developer, my concerns are different than yours doing consulting for larger, existing corporations. My life boils down to this: How can a one-person, self-funded startup, with limited resources and an under-developed professional network, pick an idea that is good enough and execute on it fast enough to build a successful company? Should they follow the Lean Startup, conduct endless customer interviews, pose endless hypotheses and coding experiments to Build-Measure-Learn from their would-be customers? I favor a different approach: Find a new product in an existing space, scratch your own itch, and then spend 100% of your time executing on the MVP. Screw all this stupid stuff with hypotheses, interviews, and experiments, and just build the dang thing. When you get the MVP done, then go show it to people. Oh, but no, no, maybe it's a bad idea. Well, if you're scratching your own itch, there's a good chance others have the same itch. If it's an existing space with existing near-competitors, then that's pretty good evidence that the problem has already long been validated. And if you're a good engineer who knows how to dissect problems and use customer empathy to design intelligent user workflows, then you don't need to waste time conducting endless customer interviews that lead nowhere. Just build it.
"How can a one-person, self-funded startup, with limited resources and an under-developed professional network, pick an idea that is good enough and execute on it fast enough to build a successful company?" Well, first step and the easiest would be to expand your network, maybe? Most likely, you aren't gonna create something that's never been thought of, or even coded, before. Focus on the quality of your product, in this case software, what value do you really wanna bring to the market? I would reconsider building FAST, to instead hit a really good balance with build speed and product maintenance/expansion. From what i read above, you just wanna build the MVP in a speed-run type fashion, this will most likely be a great learning experience but unless you build something absolutely astounding, i don't see it going much further than that without some major tweaks. Just my 2 cents though.
@@brawlgammer4424 Thanks, that's great. I agree with you. I was making the opposite argument. I'm not the one arguing for the fast MVP, it's all the people I talk to at startup meetup groups who know nothing about me or my product, they've known me for 5 minutes, and they start in on me with gotta-get-it-out-there talk, and Lean Startup, and get 10 reference customers, and all that kinda stuff. And I say, shouldn't I get the MVP done first? And they say "Nah!! Don't try to be perfect. Get it out there and get feedback." And I say that's not going to prove anything. And on and on it goes like that.
No idea what your itch or product candidate is, but I am in a similar situation regarding limited resources and under-developed network (to say the least), so I just wanted to wish you good luck!
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.
Excellent talk about Agile and Lean. Appreciate you all sharing the war stories. For junior people out there, they are spot on with regards to working for a company. If you need to get in your foot in the door, do your time but be on the lookout for companies that embrace empowerment at lower levels. You can't change the culture yourself unless you're the CEO or founder. A lot of wisdom in this interview.
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code. I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Agile scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they deinfe make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense. Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves. Fortunately, after starting a new contract job that will likely be my last job before I retire, they aren’t doing agile scrum. I actually sent a resume to them because I figured they weren’t doing that nonsense and didn’t send a resume to some other companies advertising for SW engineers because they said they were agile. Things that make me glad to be nearing retirement: Agile scrum and open office seating arrangements. Working remote at least mitigates open office seating arrangements. Fortunately, working in what will likely be my last contract job before I retire, working on a safety critical product in commercial avionics, they are not doing agile scrum.
It seems that, whenever something receives an official name and when people in suits earn big bucks on "teaching" people in what is basically common sense, it heralds the death of the intent.
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?
I'm a developer. I don't really hate management, but I don't respect them. When agile and even more so scrum became a thing, I felt like all that is being done is to stop planing. I can categorize all my projects, some 35 years worth of work in two categories: projects where somebody could represent the ultimate user (the product owner role) and all the others. The success of the project and the fun I had working in it is perfectly expressed by this one metric. Is there a guy who emotionally owns the thing? Is the product somebody's "child"? If this guy talks to developers, things go well.
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 RUclips 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.
Having a job in a scrum team really shook my confidence as a developer. On the one hand I'd come from a different background and did have a lot to learn... but, it was meeting / process heavy and I felt a lack of freedom to approach problems in the way I knew how to get my head around what was going on. I agree with the problem with metrics for two reasons 1) If you are judged by the metrics you will chase the metrics, not what the metrics are supposed to measure 2) You will get stuck in local minima, optimising for the best short-term solution, and not for long-term growth - which requires keeping the technical debt down. I also generally hate the lack of ownership you have when everything is dished out in sprint tasks, there's no pride in having accomplished something, just temporary relief until the cycle starts again.
Very similar experience. After years of working hand in hand with the product owner where we grew a product from inception to a large multi client application we needed more resource. What we got was one additional developer and and army of management, endless meetings, having to explain everything, justify everything, significantly more stress and anxiety to the point where its debateable whether we are any better off than I was on my own. None of this has come from the product owner, its a corporate IT issue.
Temporary relief puts it just right. It's disheartening, but that's most of the jobs out there. Don't look for passion at work.
In general, Scrum doesn't prevent tech improvements and tech maintenance. For me, planning session kind of ruins the whole idea of Scrum.
There should be no planning in the form suggested by Scrum. All developers need to do is improve the highest priority problem of the customer while leaving them enough time to maintain the technical solution and to improve it.
The stupid concept of sprint velocity has kind of multiplied this problem - now instead of solving problems + making sure the tech is in a good shape, team are grinding through story points. What a ridiculous thing to focus on.
@@Diginegi if the developer doesn't have passion - they are not going to be a part of my team. It almost feels like a stupid idea to spend 8 hours a day doing something you're not passioned about.
@andyk2181 You're talking about misplaced pride in individual ownership and individual achievement. Rather than professional pride in being part of a team that shares ownership, trying to do their best work all the time.
Kent Beck, for example, focuses not on writing Clean Code (code you can be proud of) so much as Refactoring the code to improve the structure for your next change. He feels that "Pride" smacks a little of a job well done, rather than focusing on a process of continuous change.
This is rooted in Kent's focus on having (TDD) tests you can trust, to reduce your anxiety level when changing code.
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?
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.
"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!!!!
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 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.
Wonderful conversation. Finding myself nodding along to all of this and feeling like some sanity is being restored! Ahhh!
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.
7:49 ❤ ❤ ❤
"agile has become a priesthood where the priests don't understand the rituals they're telling people to follow"
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.
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…
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 🤨
Allen Holub is my spirit animal.
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.
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!
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?
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 :)
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
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.
Thank you both Allen and Dave for sharing this talk with us.
Shame on me for making any comments without having first shown appreciation for the great talk.
I like this guy's attitude.
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.
You should consider uploading these to Spotify :)
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.
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.
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 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 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.
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!
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 really enjoyed that - the best interview I've seen all year. It didn't hurt that everything Allen said resonated strongly with me…
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.
Thanks Dave and Allen, this conversation has been great. Really thanks for sharing.
Glad you enjoyed it
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: ruclips.net/video/2Afk9KVEgpE/видео.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!
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 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!
Agile - doing half of scrum badly with JIRA.
This should be in the dictionary.
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 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.
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 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.
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
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
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.
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 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!
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.
Being agile will ALWAYS work. Doing the things companies are doing because they are told it will make them agile almost never work.
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.
Great content and enjoyable conversation! I enjoyed the new camera border and animations as well!
Awesome, thank you!
I just looked in my library and noticed that I still have Allen's book "Compiler Design in C"!
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.
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
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.
This content is incredibly inspirational, not just informational.
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
This is great. Just discovered Allen Holub and love his take on this topic.
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.
😪 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.
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.
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!
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.
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"
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 love Alan for his fight against estimates.
But, his diatribe against metrics is cringeworthy. It goes against much of the important ideas from this channel.
Perhaps if the organization is truly pathological, then there is no hope for metrics. But, when working with reasonable people (a precondition for all of Dave's ideas), the DORA metrics balance each other. If you decrease lead time to change and decrease change failure rate over a significant period of time, you're probably doing a better job.
I agree. I follow him on Twitter and I feel his understanding of Metrics and Lean are completely missing the point. And I feel he is unable to even consider posibility that his understanding is incorrect.
@@RFalhar You do know that I worked with Lean metrics for years, don't you? Here are a few useful quotes:
"Tell me how you measure me, and I will tell you how I will behave." -Goldratt
"It is wrong to suppose that if you can’t measure it, you can’t manage it - a costly myth.” (Deming [The New Economics])`
“You can only measure three percent of what matters” (Deming, quoted by Peter Senge)
“Managers who don’t know how to measure what they want settle for wanting what they can measure.” - Russell Ackoff
Of the 97% of things that do matter, I find things like innovation, happiness, drive (to use Dan Pink's word), value, satisfaction, more important than assembly-line metrics. None are measurable.
@@AllenHolub Thanks for proving me right. Instead of inquiring on why I think what I think and keeping open mind, you have immediatelly bombarded me with "I'm right and you are wrong." assertions. Assertions for which you have provided zero evidence to back them up. Such assertions are nothing more than just your opinions.
And to give you one more quote "Opinions are like assholes, everyone has one and they all stink."
So until we can establish shared way of figuring out how world works, we won't be able to talk properly. And considering the most commonly accepted way of building shared understanding of our world, The Scientific Method, is heavily based around measurements, I cannot imagine you accepting this method.
Ironically, my most recent video on DORA metrics ruclips.net/video/hbeyCECbLhk/видео.html is 'performing' only slightly better than this video with Allen 😂
@@AllenHolub while I think i agree with you on metrics, I don't necessarily agree with how you put it. The problem is not in the metrics, it's in metric-based management. Every tool can be used or abused and it doesn't make it bad
Btw, I think you may be able tomeasure value if you know what is the expected outcome of the product. Just there is no universal metric of value. And you can measure happiness and satisfaction - there are techniques for that (I'm not saying it's worth measuring though)
This is immensely helpful! Thank you!!
Thank you for this video 🙏 The webcam frames are cool, but very distracting, maybe just me
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. 💯
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.
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…
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.
@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.
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
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.
"factory" that is the problem, most managers are trained to run factories
Yes, trained to run not only factories, but also slave plantations.
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.
bold discussion. key takeaway is flexible not stuck with some term and same process ....
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.
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
Great discussion.
Guys you are amazing!!! A have never seen more positive and inteligent persons!!! Thank you very much!!!
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 :)
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.
7:30 - Dave cackling like a naughty boy...
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!
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.
So far good conversation, but please remove the continuous outline from the video frames... Too distracting, hahaha.
As an individual startup developer, my concerns are different than yours doing consulting for larger, existing corporations.
My life boils down to this: How can a one-person, self-funded startup, with limited resources and an under-developed professional network, pick an idea that is good enough and execute on it fast enough to build a successful company?
Should they follow the Lean Startup, conduct endless customer interviews, pose endless hypotheses and coding experiments to Build-Measure-Learn from their would-be customers?
I favor a different approach: Find a new product in an existing space, scratch your own itch, and then spend 100% of your time executing on the MVP. Screw all this stupid stuff with hypotheses, interviews, and experiments, and just build the dang thing. When you get the MVP done, then go show it to people.
Oh, but no, no, maybe it's a bad idea. Well, if you're scratching your own itch, there's a good chance others have the same itch. If it's an existing space with existing near-competitors, then that's pretty good evidence that the problem has already long been validated. And if you're a good engineer who knows how to dissect problems and use customer empathy to design intelligent user workflows, then you don't need to waste time conducting endless customer interviews that lead nowhere. Just build it.
"How can a one-person, self-funded startup, with limited resources and an under-developed professional network, pick an idea that is good enough and execute on it fast enough to build a successful company?" Well, first step and the easiest would be to expand your network, maybe?
Most likely, you aren't gonna create something that's never been thought of, or even coded, before.
Focus on the quality of your product, in this case software, what value do you really wanna bring to the market?
I would reconsider building FAST, to instead hit a really good balance with build speed and product maintenance/expansion.
From what i read above, you just wanna build the MVP in a speed-run type fashion, this will most likely be a great learning experience but unless you build something absolutely astounding, i don't see it going much further than that without some major tweaks. Just my 2 cents though.
@@brawlgammer4424 Thanks, that's great. I agree with you. I was making the opposite argument. I'm not the one arguing for the fast MVP, it's all the people I talk to at startup meetup groups who know nothing about me or my product, they've known me for 5 minutes, and they start in on me with gotta-get-it-out-there talk, and Lean Startup, and get 10 reference customers, and all that kinda stuff. And I say, shouldn't I get the MVP done first? And they say "Nah!! Don't try to be perfect. Get it out there and get feedback." And I say that's not going to prove anything. And on and on it goes like that.
No idea what your itch or product candidate is, but I am in a similar situation regarding limited resources and under-developed network (to say the least), so I just wanted to wish you good luck!
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.
Great conversation, thanks a lot for the unfiltered opinions & facts !
Can't wait for Allen's new book.
Excellent talk about Agile and Lean. Appreciate you all sharing the war stories. For junior people out there, they are spot on with regards to working for a company. If you need to get in your foot in the door, do your time but be on the lookout for companies that embrace empowerment at lower levels. You can't change the culture yourself unless you're the CEO or founder. A lot of wisdom in this interview.
If we got better at estimations as corporate managers desired then senior developers would need to change titles to senior Seer
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code.
I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Agile scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they deinfe make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense.
Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves. Fortunately, after starting a new contract job that will likely be my last job before I retire, they aren’t doing agile scrum. I actually sent a resume to them because I figured they weren’t doing that nonsense and didn’t send a resume to some other companies advertising for SW engineers because they said they were agile.
Things that make me glad to be nearing retirement: Agile scrum and open office seating arrangements. Working remote at least mitigates open office seating arrangements. Fortunately, working in what will likely be my last contract job before I retire, working on a safety critical product in commercial avionics, they are not doing agile scrum.
It seems that, whenever something receives an official name and when people in suits earn big bucks on "teaching" people in what is basically common sense, it heralds the death of the intent.
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?
Thank you, both. It's a joy to hear radical thinkers discuss where the rest of the world are victims of their own preconceptions.
I'm a developer. I don't really hate management, but I don't respect them. When agile and even more so scrum became a thing, I felt like all that is being done is to stop planing.
I can categorize all my projects, some 35 years worth of work in two categories: projects where somebody could represent the ultimate user (the product owner role) and all the others. The success of the project and the fun I had working in it is perfectly expressed by this one metric. Is there a guy who emotionally owns the thing? Is the product somebody's "child"? If this guy talks to developers, things go well.